Is there a way for multiple IIS virtual directories (applications) to share the same copy of a third-party component DLL?
We have a collection of 15-20 related ASP.NET applications (wwwroot subdirectories defined as virtual directories or applications in IIS) that run on the same website (based on root or wwwroot). .NET 4.0 environment.
Usually, when we use a third-party component, we add it to a separate application, which usually adds some entries to web.config and copies the component DLLs to the bin folder in this application for deployment, if the same components are used in several web applications -site, DLL components must be copied to the bin folder in each application (virtual directory). This is normal when there are only a few DLLs.
We recently acquired and started using a collection of ASP.NET components (grids, diagrams, etc.). If we use an almost complete set of components in each application, this will require copying 100 MB or more .dll files to each application. Even if we use only a reasonable subset of the components, it will still be 30-50 MB in each application.
I am trying to find a way for each application to use one common copy of DLL components, possibly installed in the root directory.
The ideal way, I suppose, would be to have the components installed in the GAC (global assembly cache) on each server, but not allowed in our production server environment.
I looked at the option "probing private Path", but this allows you to load assemblies from a subfolder of the application.
I looked at the "codeBase" option, and it seems almost possible, but not quite.
I copied one of the component DLLs to C: \ Inetpub \ wwwroot \ bin and then added the section to web.config in the child application, similarly:
<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>
If the name, version, publicKeyToken and file name were specific to the component that I was trying to use.
I also had the corresponding “add assembly” section in the child.config file of the child application.
Trying to start a child application using the component did not work because the bin folder was denied by IIS from the visible (served) 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 assembly loading is disabled for this application. (Exception from HRESULT: 0x80131048) Some searches seemed to indicate that this restriction was built into ASP.NET and could not be reasonably changed.
Then I tried to change 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 start and load the page using the component.
However, I do not like to use this approach, since it depends on the absolute physical path to the file in the operating system. This file path is not the same on development, middleware, testing and production servers. I may be able to do this by publishing different web.config files for each environment, but this increases the work and the risk of errors for deployments. In addition, since our group does not own or control production servers, there is no guarantee that the path of the physical file of our website will always remain the same.
Is there any practical way to share a single copy of component DLLs in all chld applications on a website, or do I just need to continue copying the DLL files to the bin folder in each application?