views:

88

answers:

2

I'm maintaining the build process for our application which consist of an ASP.Net application, two different Win32 services and other sysadmin related applications.

I want to end up with the following configuration to be used both when debugging & deploying.

libraires/    -- Contains shared assemblies used by all other apps.
web/          -- ASP.Net site
service1/     -- Win32 service 1 (seen under the service control manager)
service2/     -- Win32 service 2 
adminstuff/   -- Sysadmin / support stuff used for troubleshooting

The problem is assembly probing privatePath in the app.config does not support relative directories outside the application root. Ie: can't use ../libraries. Very frustating...

If I strong name our assemblies, I could use codeBase config element which seems to support absolute path but you need to specify each assembly individually.

I also tried hooking into AppDomain.AssemblyResolve event, but I'm getting FileNotFoundException from the .Net Fusion before I can even register the event handler in Main().

I don't like the idea of registering the assemblies in the GAC. Too much hassle when deploying / upgrading application.

Is there another to do this without having the specify the path of each requiered assembly ?

A: 

I've used the AppDomain.AssemblyResolve approach in the past and it worked quite well. I would suggest trying to figure out what Assembly is causing the FileNotFound exception as see if you can reorganize application initialization such that it doesn't load when it does.

dkackman
+1  A: 

Your approach invokes the worst kind of DLL Hell. Updating a "library" assembly can break all untested apps with no way to get them to repaired by letting them use the old version of the assembly. That's why the CLR doesn't support this scenario.

You've listed all the usual workarounds. Except one: give each app its own copy.

Hans Passant