Is there any way to have multiple IIS virtual directories (applications) share a single copy of third-party component DLLs?

Is there any way to have multiple IIS virtual directories (applications) share a single copy of third-party component DLLs?

We have a collection of 15-20 related ASP.NET applications (sub-directories of wwwroot, defined as virtual directories or applications in IIS) all running in the same web site (based at the root, or wwwroot). The environment is .NET 4.0.

Typically, when we use a third-party component, we add it to the individual application, which typically adds some entries in web.config, and copy the component DLL file(s) to the bin folder in that application for deployment. If the same components are used in multiple applications in the web site, the component DLLs need to be copied into the bin folder in each application (virtual directory). This is fine when there are only a few DLLs.

We have recently purchased and are starting to use a vendor's collection of ASP.NET components (grids, charts, etc). If we use almost the full suite of components in each application, this will require copying 100MB or more of DLL files into each application. Even if we only use a reasonable subset of the components, it is still likely to be 30-50MB in each application.

I have been trying to find a way to have each application use a single shared copy of the component DLLs perhaps installed in the root directory.

The ideal way, I assume, would be to have the components开发者_运维问答 installed in the GAC (Global Assembly Cache) on each server, but that's not allowed in our production server environment.

I looked at the "probing private Path" option, but that only allows for assemblies to be loaded from a sub-folder of the application.

I looked at the "codeBase" option, and this seems to almost make it possible, but not quite.

I copied one of the component DLLs to C:\Inetpub\wwwroot\bin and then added a section to web.config in a child application, similar to:

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="COMPONENT-NAME" version="1.2.3.4" culture="neutral" publicKeyToken="NNNN"/>
    <codeBase version="1.2.3.4" href="http://SERVERNAME/bin/COMPONENT-NAME.dll"/>
  </dependentAssembly>
</assemblyBinding>
</runtime>

Where the name, version, publicKeyToken, and file name were specific to the component that I was trying to use.

I also had the appropriate "add assembly" section under in the child application's web.config file.

Attempting to run the child application using the component didn't work because the "bin" folder is prohibitied by IIS from being visible (served) as a URL.

I moved the DLL to C:\Inetpub\wwwroot\components and changed the href attribute for codeBase to match. Then I got this error: HTTP download of assemblies has been disabled for this appdomain. (Exception from HRESULT: 0x80131048) Some searching seemed to indicate this restriction was built in to ASP.NET and could not reasonably be changed.

Then I tried changing the href in the codeBase tag to an absolute file path, similar to:

<codeBase version="1.2.3.4" href="file://C:\Inetpub\wwwroot\components\COMPONENT-NAME.dll"/>

This succeeded, and allowed the child application to run and load a page using the component.

However, I don't like to use this approach since it depends on an absolute physical file path in the operating system. This file path is not the same in development, staging, test, and production servers. I can probably manage that by publishing different web.config files to each environment, but that increases the work and risk of errors for deployments. In addition, since our group doesn't own or control the production servers, there is no guarantee that the physical file path of our web site will always remain the same.

Is there any practical way to share a single copy of component DLLs across all the chld applications in a web site, or do I just need to continue copying DLLs to the bin folder in each application?

---

I recommend the Global Assembly Cache on the web server, then any application on the sever can use it.

I would question whomever as to why you can't use the GAC in your production environment. I would think the amount of maint. and probable mistakes that will be made copying files everywhere, out weigh whatever reason the GAC is dis-allowed.