New Post: Prevent All Dependencies From Loading

As I was writing my original post, I realized the situation is a bit more complex and confusing than I described.

We have a series of tools that can be run as either a standalone tool or integrated into a larger framework. Each tool is distributed as a Windows executable that (also) implements an out-of-process COM server that interacts with the framework application (the COM client in this case). Because the framework application interacts with COM servers, it has no knowledge of AppDomains, etc. Multiple instances of the same tool can be used within the framework and when this happens all instances are created in the same AppDomain, which does cause issues with static objects, etc.

Each tool can be started in one of two ways, either by running the tool directly (we call this standalone mode) or by being created in the framework (we call this plugin mode). When the tool is started in standalone mode, it runs a normal CM bootstrapper with minimal customization. When the tool is started in plugin mode, it runs a slightly more customized bootstrapper that inherits from the base bootstrapper, but sets the useApplication parameter to false.

The COM server interface (let's call this IFramework) has essentially four methods:

1. A construct(IHost host, ...) method that instances the tool and passes three objects to facilitate communication with the framework. In this method, I instantiate the customized bootstrapper and call the start() method on the bootstrapper.
2. A show() method to show a user interface if necessary. In this method, I use IoC to get my customized WindowManager and then use it to display the view associated with the root viewmodel. In almost all cases, at some point this method requires use of the three objects passed in the construct() method.
3. A end() method to perform cleanup and whatnot.
4. (Actually a couple of) event() methods to faciliate responding to events from the framework. These methods rely on the objects passed by the the construct() method.
   

My current problem is that since there is a class that implements the IFramework interface, the ViewLocator is trying to load the IFramework.Interop.dll file that contains the IFramework interface. Because our tool can run many versions of the host framework, each of which has it's own version of the IFramework.Interop.dll file, and the dll is not needed when the tool is run in standalone mode, we don't ship our tool with a copy of the dll. When our tool is run in standalone mode, the ViewLocator then crashes when it unable to locate/load the dll as expected.

In the larger context, it is likely the static methods in CM will cause additional headaches... In the past we have looked at creating a separate AppDomain in the construct() method, but we were never able to identify a clever way to respond to the event methods and share the interaction objects across the AppDomain boundary. Any thoughts here?

Thanks!