My application uses a third party SDK which is installed on every machine that has my application, I do not want to add these SDK DLLs in my application deployment because it takes a lot of space. Registering the DLLs in the GAC is not an option for other reasons. Anyway is there a way to tell my application that the required DLLs are available on a specific path?
-
Have you taken a look at this? http://support.microsoft.com/kb/837908 The config option looks somewhat appealing. – Gray Jul 12 '13 at 17:20
-
1The notion of DLLs taking "a lot of space" in an era of multi-terabyte disks is a strange one. Of course they still take the same amount of space in another directory. – Hans Passant Jul 12 '13 at 17:32
-
@HansPassant the application is deployed using ClickOnce, a 45 MB DLLs is a problem in my case. Not a real problem I know but ClickOnce keeps a copy of all deployment versions and this 45 MB will be with every version.. kinda bothering me.. – Jul 12 '13 at 17:34
-
Plus, this SDK is for fingerprint identification, it is installed in every machine I am dealing with by default, why do I have to deploy them again with the application.. that's the main point @HansPassant – Jul 12 '13 at 17:37
2 Answers
We have used the probing path in asp.net applications to do something similar in the past:
http://msdn.microsoft.com/en-us/library/823z9h8w.aspx
Has a side affect in asp.net where the assemblies in these locations will not be loaded automatically when the application runs, only when they cannot be found in bin.

- 356
- 1
- 5
-
Didn't you think of adding a call to any of these assemblies in a static constructor? – Jul 12 '13 at 17:31
-
It was for optional functionality with a 3rd party component, the .net sdk had a dependency on the COM sdk being installed, and threw a wobbler if not present, so we needed to not load the assembly unless we knew we could. Different scenario granted, but should work here. – David Bennington Jul 12 '13 at 17:37
-
+1. Btw., that side effect does not sound any different from how assemblies are normally loaded. (The program's binary directory is only one from several locations that are searched for assemblies; however in certain scenarios, it may be the first one searched.) See also [this SO answer](http://stackoverflow.com/a/50058/240733) and the MSDN page linked to from there for details about the assembly loading process. – stakx - no longer contributing Jul 24 '13 at 11:56
Yes, shared files (if for some reason you do not want to put them in GAC) can be deployed, for example, in the Common Programs folder.
According to the way your application works you may need to load them explictly with Assembly.LoadFrom() using the path you get from Environment.GetSpecialFolder() for Environment.SpecialFolders.CommonPrograms or attaching and event handler for AppDomain.AssemblyResolve event.
Let's see a raw and simple example:
// Put this in your initialization code
public static void Main()
{
AppDomain.CurrentDomain.AssemblyResolve += new ResolveAssembly(MyResolveEventHandler);
}
private static Assembly ResolveAssembly(object sender, ResolveEventArgs e)
{
// Clean, check, double check and verify path name to be sure it's a valid
// assembly name and it's not a relative path itself, you may even check e.RequestingAssembly
string path = ...;
return Assembly.LoadFrom(path);
}
If you have the directory and you want to load them all at startup (just in case...):
private static LoadThemAll(folderPath)
{
foreach (var path in Directory.GetFiles(folderPath, "*.dll"))
Assembly.LoadFrom(path);
}
Do not forget to add proper error handling (for non managed DLLs, wrong versions and everything else may happen, especially because that assemblies will be loaded in your AppDomain and everyone may put a malicious one in that folder).
Of course all of these can be applied to any (accessible) folder, which one is the best...well it depends on what you're trying to load and how it's deployed (you can even search in Registry to dynamically find where support files are located).
Finally in case assemblies you referenced are strong signed and they reside on a known, fixed, immutable location you can use <codebase>
in your .config file.

- 65,416
- 20
- 137
- 208