Loading DLLs App.config from alternate location

Northorn

unread,

Feb 1, 2006, 4:27:28 PM2/1/06

to

My company has the following policy for application directory structure:

/apps
/bin - executables
/dll - DLLs
/config - config files

The only way I've found to get the DLLs to load from outside the application
directory is by adding the following to the machine.config file:

and setting the DEVPATH environment variable to point to the path of the DLLs.

This isn't a desirable option because of the extra configuration required.
Is there any other way to do this?

Also, I haven't been able to find a way to load an application config file
from any place other then the directory where the application was executed.
Is there any way to change the default location of the application config
file?

Thank you

john conwell

unread,

Feb 4, 2006, 8:14:40 AM2/4/06

to

There are only two ways to too the clr where to find the config file.

1. Host the clr yourself. this sucks because you have to write a C++ COM
exe to load the CLR/

2. use the AppDomainSetup.ConfigurationFile property. this also sucks
becuase the property is read only once the main appdomain is running. The
only way to do this is to spawn off a new appdomain, from the main appdomain,
and set the config file path. them have your application run on the second
domain.

sounds easier to just tell your policy making people that there is a
technological constraing the demands the config file is in the same dir as
the exe.

Richard Grimes [MVP]

unread,

Feb 6, 2006, 12:24:43 PM2/6/06

to

Northorn wrote:

DLLs do not have config files, confile files are for *applications*

> My company has the following policy for application directory
> structure:
>
> /apps
> /bin - executables
> /dll - DLLs
> /config - config files
>
> The only way I've found to get the DLLs to load from outside the
> application directory is by adding the following to the
> machine.config file:

> and setting the DEVPATH environment variable to point to the path of
> the DLLs.

NO! Do not do this. It is deprecated in v2.0. Even in 1.1 it is buggy.

> This isn't a desirable option because of the extra configuration
> required.
> Is there any other way to do this?

Well, the company policy is wrong: tell your boss that. .NET requires
that private assemblies without a strong name are under the application
folder (bin, in your scheme). They can be in a subfolder (eg bin/dll)
which can be set through the config file. Libraries with a strong name
can be located anywhere on the machine (or anywhere on the internet),
but you can only do this for a specific version of the library, and this
makes things messy.

> Also, I haven't been able to find a way to load an application config
> file from any place other then the directory where the application
> was executed. Is there any way to change the default location of the
> application config file?

The default location is the application folder, and as John's mentioned,
you can change this by creating a .NET host or creating a new
application domain, but it's not an ideal situation.

The bottom line is this: it is far easier to work the way that .NET
works rather than to fight against it. Read through my Fusion tutorial
for more details on assembly loading.

Richard
--
Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security Tutorial:
http://www.grimes.demon.co.uk/workshops/securityWS.htm