How to get ASP.NET to find DLLs in different paths

[Oenone]

I'm sure there's an obvious way to do this, but I'm missing it so far.

I have an ASP.NET application that relies on several DLLs to work. Currently
in order to get my site working I have to put them all in the bin/ folder
within my web site's directory.

As I have numerous web sites, I want to be able to place all of these DLLs
just once into a single location elsewhere on the disk (e.g., "D:\DLLs"). I
don't want to put them into the GAC.

How can I configure my ASP.NET web sites so that they pick up the required
DLLs from the D:\DLLs directory? I have tried adding this to the web.config
file and it didn't make any difference:


<?xml version="1.0" encoding="utf-8" ?>
<configuration>

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="D:\DLLs" />
</assemblyBinding>
</runtime>

[...rest of web.config file...]
</configuration>


With this in place and the bin/ folder removed, the code fails:

Dim myObject As MyDLL.MyClass

Compiler Error Message: BC30002: Type 'MyDLL.MyClass' is not defined.

How can I get this working?

Many thanks,

 

[Guest]

Make a virtual directory to your dlls
--
Staff Consultant II
Enterprise Web Services
Cardinal Solutions Group

Future Business Model
Loan Origination Services
National City Mortgage

 

[Oenone]

Make a virtual directory to your dlls

Thanks for the suggestion. I assume you mean to do this in the IIS
management window?

I created a virtual directory inside my web site's own directory, calling
the new directory 'bin' and pointing it to the physical location on disk
where my DLLs are located. This still didn't make any difference -- it still
reported that the referenced class was not defined.

Do I need to do anything else to make this work?

Thanks,

 

[Scott Allen]

Michael:

A vdir would only work if the assembly loader knew about virtual
directories, but it doesn't.

 

[Scott Allen]

Hi Oenone:

A privatePath has to be private - in a subfolder of the application.

I think you are looking for all the pain of being in the GAC (for
instance, your apps won't shadow copy the assemblies - you'll have to
shut all the web apps down to upgrade) without any of the benefits
(for instance, versioning). It's the road to the old "dll-hell".

 

[Oenone]

A privatePath has to be private - in a subfolder of the application.

Ah, so that explains why that didn't work then!

I think you are looking for all the pain of being in the GAC (for
instance, your apps won't shadow copy the assemblies - you'll have to
shut all the web apps down to upgrade) without any of the benefits
(for instance, versioning). It's the road to the old "dll-hell".

Hmm... I'm really genuinely surprised that there is no option to pick up
DLLs from a location outside the web app directory. I thought my planned
work for today would be trivial but it turned out to be a bit of a
nightmare.

So what are the recommended courses of action to resolve this? It seems to
me that these are my options:

A. Copy all the required DLLs to each web application's private bin/
directory.

B. Copy all the required DLLs to the GAC.

The disadvantages of these to me are:

A. The apps use about 20 different DLLs, and we have in excess of 30
different applications on our web servers (which are mirrored across
multiple machines just to make it evern more interesting). Putting private
copies of DLLs into bin/ directories will result in about 600 DLLs per
server! That's an awful lot to manage, especially when we need to upgrade
one of those DLLs across all of the applications.

B. The GAC might be better, but we use an automated application that checks
all DLLs on our server are present in the correct locations on disk, and are
the correct versions (these are all matched up to corresponding DLLs in a
SourceSafe database). I don't think I'd be able to use this application if
we deploy to the GAC.

A couple of other questions if you'd be so kind:

Shadowing is a feature that I'm particularly interested in being able to
use. Does shadowing not work if we deploy to the GAC? Or would copying an
updated DLL (with a new version number) simply cause the two versions of the
DLL to both be present in the GAC at the same time?

I'm also slightly concerned about putting DLLs inside a folder that is
potentially accessible via a web site. Does IIS/ASP.NET have any security
features that stops people from downloading my DLLs by accessing them
straight from the bin/ directory?

Many many thanks for your help!

 

[Scott Allen]

Hello, Oenone:

Hmm... I'm really genuinely surprised that there is no option to pick up
DLLs from a location outside the web app directory. I thought my planned
work for today would be trivial but it turned out to be a bit of a
nightmare.

There is a <codebase> hint you can use in <assemblyBinding> also - but
you'll need strong named assemblies. For the codebase href use
"file:///". There is also an AssemblyResolve event on an AppDomain
object, see:
http://blogs.msdn.com/junfeng/archive/2004/11/16/258081.aspx.
Jenfeng's blog has a lot of good notes on the assembly loader.

So what are the recommended courses of action to resolve this? It seems to
me that these are my options:

A. Copy all the required DLLs to each web application's private bin/
directory.

B. Copy all the required DLLs to the GAC.

The disadvantages of these to me are:

A. The apps use about 20 different DLLs, and we have in excess of 30
different applications on our web servers (which are mirrored across
multiple machines just to make it evern more interesting). Putting private
copies of DLLs into bin/ directories will result in about 600 DLLs per
server! That's an awful lot to manage, especially when we need to upgrade
one of those DLLs across all of the applications.

True, that is a lot of files to manage. Could you write an
installation script that looks for the dll in subfolders of a well
known root location?

I think you face some tough tradeoffs and it's hard to make a
recommendation without knowing your build, test, deployment process
and a bit about the applications. Personally, I'm more at ease with a
private deployment to the bin simply because each application can be
an island unto itself - it doesn't need to upgrade when another app
upgrades and remains self contained. That's what works in my
environment.

B. The GAC might be better, but we use an automated application that checks
all DLLs on our server are present in the correct locations on disk, and are
the correct versions (these are all matched up to corresponding DLLs in a
SourceSafe database). I don't think I'd be able to use this application if
we deploy to the GAC.

The GAC does indeed come with it's own set of headaches...including an
undocumented API.

A couple of other questions if you'd be so kind:

Shadowing is a feature that I'm particularly interested in being able to
use. Does shadowing not work if we deploy to the GAC? Or would copying an
updated DLL (with a new version number) simply cause the two versions of the
DLL to both be present in the GAC at the same time?

Shadow copying does not work for strong named assemblies, so it won't
work for GAC'ed assemblies. In addition, the ASP.NET runtime
configures itself to only shadow copy from the bin subdirectory.

You can have side by side versions of an assembly in the GAC at the
same time - that is one of the GAC's selling points.

I'm also slightly concerned about putting DLLs inside a folder that is
potentially accessible via a web site. Does IIS/ASP.NET have any security
features that stops people from downloading my DLLs by accessing them
straight from the bin/ directory?

Yes - on IIS 6.0 the ASP.NET ISAPI filter blocks the request and
returns a 404 for any content in /bin (even an .html file).

I hope I provided some information you can use.

 

[Oenone]

Scott Allen wrote:
[...]

I hope I provided some information you can use.

You certainly have Scott, I'll be sitting down on Monday to work out which
is the best of the options available.

Many thanks for your help,