The future of loading Assemblies into an AppDomain

As you may or may not know, the method AppDomain.AppendPrivatePath has been marked as obsolete in the 2.0 framework.  The message is this: "AppDomain.AppendPrivatePath has been deprecated. Please investigate the use of AppDomainSetup.PrivateBinPath instead.".  This is the method used my most applications the use a module or plugin style framework to load their assemblies.  The problem now is that it’s replacement of sorts is to use AppDomainSetup.  AppDomainSetup can only be used when setting up an AppDomain and before any assemblies are loaded.  Thus if you need to dynamically load assemblies from an a directory other then the one containing the executable, you are in trouble.

Some options are using the Assembly.LoadFrom instead of AppDomain.Load or Assembly.Load.  This has a whole new set of issues that you have to be aware of as well. 

What are others doing to migrate old or create new plugin type applications? 

Here is a quote from a bug report on MSDN,

Opened by drieseng on 2004-08-30 at 11:22:24
   
In .NET 2.0, the AppDomain.AppendPrivateMethod is marked obsolete (with message "AppDomain.AppendPrivatePath has been deprecated. Please
investigate the use of AppDomainSetup.PrivateBinPath instead."). However, AppdomainSetup.PrivateBinPath is not valid alternative, as you cannot use the PrivateBinPath property of the AppDomainSetup to modify the privatebinpath for a domain that's already created. Modifying the PrivateBinPath property does not have any effect on an existing domain.

I've attached the source code of a small test application that modifies the privatebinpath of a newly created domain using the AppDomainSetup.PrivateBinPath (as recommended by the obsolete message of AppDomain.AppendPrivatePath). The sample app will demonstrate that you can use AppDomainSetup.PrivateBinPath to set the privatebinpath for a domain that you're going to create, but you cannot use AppDomainSetup.PrivateBinPath to modify the privatebinpath of an existing domain.

Resolved as By Design by Microsoft on 2004-08-30 at 13:50:15
   
Yes, this is intentional. The point of deprecating it is so that an appdomain's binding context can't be modified after assemblies have been loaded. Providing an alternative which allows that would defeat the purpose.
This is required for domain neutral assembly binding. Apps using this method should use AppDomainSetup.PrivateBinPath instead, at appdomain creation time. It was never intended that AppendPrivatePath() be used to append paths after assemblies have already been loaded. If that is desired, a new appdomain is recommended.

Recent Posts

Tag Cloud

3 Comments

  • I agree with loading new appdomains instead, plugin architecture should be creating a new appdomain per plugin assembly, thereby helping to isolate the main app's appdomain from the plugin's crashing and a few other nice features.

  • I agree that in the general case of plug-ins you would want a new app domain to isolate them, but what about if you have a very configurable application that consists of modules that you wrote, but you want to have them loaded like plug-ins (meaning picked up at runtime). In this case, why impose the overhead of isolating them and having to marshal data across AppDomain boundaries?

  • AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve); I believe this is what everyone is looking for. Just handle the event and return an Assembly Instance and Voila.

Comments have been disabled for this content.