Click here to Skip to main content
Click here to Skip to main content

In GAC we Trust

, 29 Nov 2012
Rate this:
Please Sign up or sign in to vote.
I am writing a plugin-hosting WPF application. For variety of reasons I have to put plugin-ins into their own app domains. To name just a few: - plugin unload is required - each plugin has its own config file - plugins may be located anywhere on the disk I am having serious troubles due to [...]

I am writing a plugin-hosting WPF application. For variety of reasons I have to put plugin-ins into their own app domains. To name just a few:

- plugin unload is required
- each plugin has its own config file
- plugins may be located anywhere on the disk

I am having serious troubles due to the last requirement. It’s one of those cases when one bad thing leads to another and you are starting to think that this was done on purpose, just to get at you.

First, you cannot normally load an assembly into an app domain unless it is under that domain’s ApplicationBase. Yes, there is a number of LoadFrom-like methods that take arbitrary path, but they load your assembly into this or another special context where it is basically useless.

This means that if my application running from c:\foo\myhost\host.exe creates an app domain based in c:\bar\plugins\SomePlugin, no type from host.exe can be loaded into this new app domain. This means no callbacks, no initialization code, nothing. Complete separation. This causes issues if the plugin must expose non-marshallable types such as WPF Control.

The only thing the two app domains can have in common is GAC. But you need to be an admin to write to the GAC!

Also, it turns out, adding things to the GAC is not easy. According to Microsoft, redistributing GacUtil is a no-no. The recommended method is to write an MSI installer, but it brings the whole lot of issues. Your application now needs to appear in “Programs and Features”, all kinds of reference counting quirks come into effect (“a previous version of this product is already installed!”), and to top it off, setup projects (.vdproj) cannot be built by MSBuild, so one needs to intall a full fledged Visual Studio on the continuous integration server. At this point I bailed on MSI.

Another method is to use this call: new System.EnterpriseServices.Internal.Publish().GacInstall(path). This one has two troubles:

- it does not return any errors except for an Event log message that comes from “COM+ SOAP Services” and just states that installing path into GAC failed.

- there actually two GACs now. One for .NET 2.0 and one for .NET 4. If your assembly is a .NET 4 assembly, the above code must be run under .NET 4 runtime. Otherwise GAC instlalation will fail.

Figuring out under which runtime your code runs may not be an easy task, especially if it is invoked from a service via complex system of build and installation scripts.

So yes, after spending almost two days fighting all that I won, but I am still not certain why all that should be that hard. If only it were allowed to load arbitrary assemblies into an app domain, all this complexity would go away. Another, less attractive, but still better solution would be to have a local assembly cache that does not require admin rights. Alas, it is what it is. No one promised us free lunch.

License

This article, along with any associated source code and files, is licensed under The Apache License, Version 2.0

About the Author

Ivan Krivyakov
Technical Lead Thomson Reuters
United States United States
Ivan is a hands-on software architect/technical lead working for Thomson Reuters in the New York City area. At present I am mostly building complex multi-threaded WPF application for the financial sector, but I am also interested in cloud computing, web development, mobile development, etc.
 
Please visit my web site: www.ikriv.com.

Comments and Discussions

 
GeneralAnnoying indeed PinmemberRiz Thon3-Dec-12 13:58 
SuggestionCheck the CLR Hosting API Pinmembermillka29-Nov-12 13:37 
GeneralRe: Check the CLR Hosting API PinmemberIvan Krivyakov1-Dec-12 12:16 
GeneralRe: Check the CLR Hosting API PinmemberRiz Thon3-Dec-12 13:40 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140709.1 | Last Updated 29 Nov 2012
Article Copyright 2012 by Ivan Krivyakov
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid