Loading unreferenced assemblies

Aug 4, 2009 at 12:24 PM

Hi all,

I'd like to hear other peoples' solution to the issue of creating mappings to unreferenced assemblies. Actually, when I configure Unity from code, I have no problem, because code like this:


container.RegisterType<IRepositoryFactory, NHibernateRepositoryFactory>();


...automatically causes the assemblies in which these types are defined to be loaded.

Whereas, the same registration from configuration obviously does not force these assemblies to be loaded, and because there is no other reference to these assemblies, configuring Unity from xml configuration fails with the error:

"Could not load file or assembly [assembly name]"


Does anyone know of a workaround for this? I'm guessing signing the assemblies is an option, but I believe it still would not work, because the referenced assemblies need to pull other assemblies in order to work.


Aug 5, 2009 at 2:17 AM

That fact that the assembly type definition in the configuration file is unreferenced is a furfy.

As previously mentioned Unity uses the default CLR loading mechanism to load assemblies and types.  The CLR engine needs to be able to locate the assembly and it has a defined set of lookup locations ( ie Same path and owning process, bin folder, GAC, etc )

And just because you register the mapping in code doesn't mean that it won't fail at runtime.  Delete the referenced assembly from the folder after you compile/deploy and you will get the same problem, Managed .NET does not link or embed the referenced assembly into the resultant DLL or EXE.

"...automatically cause the assemblies in which these types are defined to be loaded."

Yes in VS or by the compiler, if the referenced assembly is not available at runtime, you will get the same failure when the appdomain loads all referenced assemblies.

You have a couple of choices to resolve this issue

1.  Sign all unreferenced assemblies ( and their dependencies ) and place them in the GAC.  The CLR will always look in here.
2.  Make sure all runtime dependencies are deployed along with your application ( ie in BIN folder for ASP.NET, same folder for others ) using your deployment system/scripts
3.  Add additional folders to the AppDomain's assemblies resolution paths to correspond where these runtime dependencies are deployed to

If you still have problems, turn on the Fusion logs so that you can see where the CLR has looked for your assemblies


Aug 5, 2009 at 11:57 AM

Thank you for your concise answer. That is what I expected to hear, I was just wondering if there was something I might not be thinking of that could more easily deal with the issue.

Thanks again,


Aug 5, 2009 at 4:41 PM

This blog is loosely related to your requirements and may be of interest to you: