How to get around DLL probing problem.

Loading an assembly from a different directory than the caller process will fail if the loaded assembly has dependencies that are not met from the caller process's directory. The reason is that CLR only looks at the caller's folder to prob for all dependencies.

This is a helper class which can be used as a workaround to this problem by loading the assembly in a separate app domain.


internal class AssemblyLoaderHelper : IDisposable
{
private Foo _foo = null;
private AppDomain domain = null;
public Foo LoadedFoo
{
get
{
return _foo;
}
}
public void Initialize()
{
try
{
string className = "MyService.foo";
string assemblyName = "MyService.foo.dll";
AppDomainSetup domainInfo = new AppDomainSetup();
domainInfo.ApplicationBase = @"C:\MyFooAssemblyFolder\";
Evidence adevidence = AppDomain.CurrentDomain.Evidence;
domain = AppDomain.CreateDomain("MyFooDomain", adevidence, domainInfo);
_foo = (Foo)domain.CreateInstanceAndUnwrap(assemblyName, className);
// CreateInstanceAndUnwrap does not necessary throw an expcetion'
if (_foo == null)
throw new Exception("Unable to load assembly.");
// now you can call _foo's methods here
}
catch (Exception ex)
{
// Log exception here
}
}
public void Dispose()
{
if (domain != null)
AppDomain.Unload(domain);
}
}

Unmanaged C++ client for WCF service. | blinnov's blog

I always wanted to know how I can talk to a WCF service from unmanaged client; Let's say there are no .Net 3.x installed on the target system.One way is using the good old gSoap.
Unmanaged C++ client for WCF service. | blinnov's blog