I have some c++ code that is a snap-in for a MMC based application. This snap in uses a .net 2.0 dll via a COM wrapper (AssemblyA). AssemblyA lives in the same directory as the app that launches the MMC session. AssemblyA uses some other .net dlls (OtherAssemblies) which, for reasons beyond my control cannot live in the same directory as AssemblyA. It also allows some components to be dynamically loaded (from AssemblyB), and it searches for these in a third directory. The dynamic components from AssemblyB reference AssemblyA as they extend a base class in there.
My problem is that when the I attempt to load the dynamic component it is unable to resolve the dependency to AssemblyA, and my AssemblyResolve
handler gets fired (which I was using to resolve OtherAssemblies
). When I query Assembly.GetExecutingAssembly ()
in the AssemblyResolve
handler, the assembly is the assembly I'm trying to resolve.
This behaviour seems a little strange to me as I would have expected the .NET runtime to look for dependencies in the loaded assemblies first, then local to the Assembly I'm loading, then in the app directory. The first and third of these should contain the assembly I'm trying to load.
I have modified my AssemblyResolve method so that it searches for the dependencies in other locations so it works, like the current app directory, but I don't really want to do this if I can help it.
Is this behaviour expected? Is it due to it being an MMC app or due to the fact that it is launched from COM called from C++? Am I being a dunce?