How can I force .NET to use a local copy of an assembly that's in the GAC

I have a .NET assembly that (for reasons outside my control) must be in the GAC. However, the same assembly is used by another program, which has a its own copy of an older version of the same assembly. It must use its own copy and not whatever is in the GAC. Proper versioning is probably more hassle than it's worth in this case, for reasons I won't go into. My questions is: is there anyway to tell .NET: just use THIS DLL, right here in this directory - ignore whatever you find in the GAC or anywhere else.

Make sure the GAC Assembly and local Assembly have different version numbers (not a bad idea to let your build number, at least, auto-increment by wild-carding your AssemblyVersion in AssemblyInfo: [assembly: AssemblyVersion("1.0.0.*")] ). Then, redirect your assembly binding using your app's config:

• http://msdn.microsoft.com/en-us/library/2fc472t2(VS.80).aspx
• http://msdn.microsoft.com/en-us/library/433ysdt1(VS.80).aspx.

In your case, you won't need the "appliesTo" attribute of the assemblyBinding config. You just need something like:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="YourAssembly" publicKeyToken="AAAAAAAAAAAA" culture="neutral"/>
            <bindingRedirect oldVersion="0.0.0.0-5.2.1.0" newVersion="5.0.8.1"/>
        </dependentAssembly>
    </assemblyBinding>
</runtime>

If they have the same version number the answer is you can't. If you attempt to load an assembly that has the same full assembly name (name, version, key) as a GAC'd assembly the CLR will pick the GAC'd assembly every single time.

You can set the DEVPATH to force load an assembly, see link text

This doesn't answer your question since it only meant for development use and even then not really recommended as it doesn't mirror production usage. However I thought I'll share it anyway since it's good to know.

Have you tried Assembly.LoadFromFile()? This is a manual thing to do, but should load your assembly into memory before it is needed. .NET will then use the one in memory instead of hunting for it.

Another way would be if the local assembly was unsigned, you could differentiate it that way.

Rob

I had a similar issue. I changed the publicKeyToken of the target dll by using ildasm and ilasm to generate a new dll. I then updated it in the project reference to point to the new dll. The steps I took are here.

This worked for me.

One reason the binding redirect doesn't work is because the Oracle.ManagedDataAccess provider has a different search order for dlls than the unmanaged provider. The unmanaged provider starts in the application directory, then looks in the dllpath in the registry, then the dll path in machine.config, then dll path in web.config. According to the Oracle documentation, the search order for managed provider works like this:

> Managed Driver will reference these assemblies by using the following search order:

1. Global Assembly Cache
2. The web application's bin directory or Windows application's EXE directory
3. The x86 or x64 subdirectory based on whether the application runs in 32-bit or 64-bit .NET Framework. If the application is built using AnyCPU, then ODP.NET will use the correct DLL bitness as long as the assembly is available. Oracle recommends using this method of finding dependent assemblies if your application is AnyCPU.

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/odpnt/installODPmd.html#GUID-0E834EC7-21DF-4913-B712-2B0A07FD58FD

So the way to resolve this problem is to unregister the GAC assembly OR simply put a different version of Oracle.ManagedDataAccess in your bin and web.config than what's in GAC, if you can't uninstall it.

I change the name of the assembly in the GAC, put an "_" as the first character.