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

Make sure the GAC Assembly and local Assembly 8 have different version numbers (not a bad 7 idea to let your build number, at least, auto-increment 6 by wild-carding your AssemblyVersion in 5 AssemblyInfo: [assembly: AssemblyVersion("1.0.0.*")] ). Then, redirect 4 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 3 your case, you won't need the "appliesTo" attribute 2 of the assemblyBinding config. You just 1 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 5 answer is you can't. If you attempt to 4 load an assembly that has the same full 3 assembly name (name, version, key) as a 2 GAC'd assembly the CLR will pick the GAC'd 1 assembly every single time.

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

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

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

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

Rob

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

This worked for me.

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

Managed Driver 7 will reference these assemblies by using 6 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 5 resolve this problem is to unregister the 4 GAC assembly OR simply put a different version 3 of Oracle.ManagedDataAccess in your bin 2 and web.config than what's in GAC, if you 1 can't uninstall it.

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