Re: Loading DLLs App.config from alternate location
- From: "Richard Grimes [MVP]" <richardg@xxxxxxxx>
- Date: Mon, 6 Feb 2006 17:24:43 -0000
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
.
- Prev by Date: Re: IL program does not execute
- Next by Date: Re: msvcm80 version
- Previous by thread: x64 mscorwks 2.0 symbols?
- Next by thread: Re: msvcm80 version
- Index(es):
Relevant Pages
|