Home/ Questions/Q 587235
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:11:29+00:00

I have some c++ code that is a snap-in for a MMC based application.

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It is both. The fact that you’re running MMC makes it hard for .NET to resolve assemblies, it isn’t going to find any in c:\windows\system32. You can’t reasonably solve this with a .config file for MMC, it is going to muck with any future plug-ins.

    COM doesn’t help either, the directory in which you placed the COM DLL does not in any way affect the probing path. You already found one way to solve this, AssemblyResolve. Or you could put everything in the GAC.

    Or you could avoid using COM and write MMC plug-ins directly with the Microsoft.ManagementConsole namespace.

    • 0