views:

286

answers:

1

We are being presented with a unique, painful situation. Traditionally we have been using the GAC and Policy Files to control DLL versions for our .NET applications. However, we have a very unique situation and are running into major problems with this, as some of our applications do NOT respect the policy files. Most specifically the .NET 2.0 applications that reference .NET 1.1 dll's that have a Policy File.

We have a blended mix of items that run dynamically (loaded via reflection) in a windows application as well as a large number of web applications. We are looking to move to more of a "Centralized DLL Store" rather than worrying about GAC versioning. But we can't seem to find a way to tell our application to "Look here for any DLL's".

Looking at some of the assembly information nodes (http://msdn.microsoft.com/en-us/library/twy1dw1e.aspx) we can get part way there, but we must define each and Every DLL that should be looked up, this is not possible as we have about 200 different applications that would require regular web.config updates as we update versions of the shared DLLs.

Does anyone have a good idea on how we can move the DLL references? CopyLocal isn't an option as we have times where we NEED applications to use the new versions of the shared DLLs. The GAC, at least right now, isn't really an option either.

+1  A: 

You can use CodeBase hints in your app.config,

<?xml version="1.0"?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="MyDll" />
        <codeBase version="1.0.1000.20000" href="file:///c:\SharedDlls" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Your DLL needs a stong name if you want to use this inside the Machine.Config file (should not be an issue for you if you came from the GAC world and it is required for Microsoft certifications).

Here is a link on an MSDN blog that gives some deeper advice.

JasonRShaver
THis is the way we were thinking, but since the codebase version is a single version number, we would have to update every config file on every version increase (over 200 config files dispersed across the network)
Mitchel Sellers