0

How can I load an assembly using its full display name from a location outside the application's bin path?

Usually one can load an assembly from a custom location with

Assembly.LoadFrom(path);

This works, but it seems that for loading a strong-named assembly I need to specify its full display name such as in

Assembly myDll =
Assembly.Load("myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9b35aa32c18d4fb1");

But the problem here is that this only references assemblies that are in my probing path of my application.

So what if I have an assembly dir1/asm.dll and one assembly dir2/asm.dll and both have a strong name.

How can I load them during runtime?

marc wellman
  • 5,808
  • 5
  • 32
  • 59
  • sorry my answer was before the SN requirement, this post may help http://stackoverflow.com/questions/3103858/load-strongly-name-assembly-from-specific-path – dbones Jan 31 '16 at 02:05

2 Answers2

1

During Runtime, you can specify additional directories to probe when loading an assembly via the following methods:

    AppDomain.CurrentDomain.ClearPrivatePath();
    AppDomain.CurrentDomain.AppendPrivatePath();

When the subdirectory names are already known during installation, you can also specify these additional directories in the app.config file in the privatePath attribute of the <probing> element.

Make also sure the file name is correct. When you have 

AppDomain.CurrentDomain.AppendPrivatePath("Subdir");

Assembly myDll = Assembly.Load("myDll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9b35aa32c18d4fb1");

then .net will look for a file named "mydll.dll" in the directory "Subdir" beneath the directory of the executable.

Mr Lister
  • 45,515
  • 15
  • 108
  • 150
NineBerry
  • 26,306
  • 3
  • 62
  • 93
  • It's not working. I added the `AppedPrivatePath` call to point to my directory but my call to `Assembly.Load(...)` will still not find anything and gives me a FileNotFoundException! – marc wellman Jan 31 '16 at 02:20
  • How did you specify the path? Do not use a full path but the path relative to your application directory (where the *.exe resides) – NineBerry Jan 31 '16 at 02:23
  • 1
    I finally found the problem: If you call `AppendPrivatePath` multiple times after each other such as in e.g. `AppendPrivatePath(dir1); AppendPrivatePath(dir2); AppendPrivatePath(dir3);` it will also look for the assembly in this exact order. This means that if you have two assemblies with the same name and a different identity (such as a different version) it will take the first assembly that matches the assembly name by looking through the directories `dir1`, then `dir2` and then `dir3`. ... – marc wellman Feb 01 '16 at 08:13
  • 1
    ... If you want to load an assembly that is included in `dir2` and you have an assembly with the same name in `dir1` the plan will not succeed. The solution is to use `AppendPrivatePath`, as you suggested and to call `ClearPrivatePath` just before it, so that you always have only one path set. – marc wellman Feb 01 '16 at 08:13
0

you can load any assembly from its location via loadfile (example here)

if you want to take multiple versions of an assembly consider handling the AppDomain.CurrentDomain.AssemblyResolve (example here)

the examples are from a small open source project, which will load dlls from a seperate a "packages" folder (allowing for packages to have their own copy of a dependency, using the isolated loader)

dbones
  • 4,415
  • 3
  • 36
  • 52