76

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.

EMP
  • 59,148
  • 53
  • 164
  • 220

7 Answers7

50

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:

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>
Corbin March
  • 25,526
  • 6
  • 73
  • 100
  • 3
    Can you avoid using this binding redirect by recompiling the app to use the new version of the dll, or is some config change always necessary? – Dan May 21 '10 at 14:25
  • Setting the revision part of your version number to `*` does not make it auto-increment. The MSDN documentation on [AssemblyVersionAttribute](http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx) indicates that it should be random, but in practice Visual Studio uses the number of seconds since midnight divided by 2. – sourcenouveau May 03 '11 at 13:52
  • So, what you're saying is each assembly will be re-versioned on each build even if it has no changes, just so we can break dependency on GAC? What's the assembly binding redirect for? The only thing i can think of is that it could be used on prod so that if your project references 5.0.8.3453 instead of 5.0.8.1 in GAC just because you were re-versioning it on dev w/o making changes, it will be redirected to 5.0.8.1. Is that right? Clunky, but I don't see another way around this. – Sergey Akopov Jul 07 '11 at 18:43
  • 1
    I am confused. This article says its possible http://www.aip.im/2013/04/how-to-force-iis-asp-net-to-use-assembly-from-the-bin-folder-instead-of-gac/ – Niloofar Jan 16 '17 at 07:40
33

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.

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 1
    I don't know who downvoted this, but I experience the same thing what @JaredPar says and it drives me crazy. It is loaded from the GAC. I have two assemblies with the same full name, and I want to load my slightly modified one. PITA. – Csaba Toth May 21 '13 at 23:35
  • have you tried this? http://www.aip.im/2013/04/how-to-force-iis-asp-net-to-use-assembly-from-the-bin-folder-instead-of-gac/ – Niloofar Jan 16 '17 at 07:40
  • 1
    You could modify the dll using something like DNSPY so it has a different signature and version. A bit hackish but it will work. – rollsch Jan 14 '19 at 05:50
  • @rolls how can I change the assembly version using dnspy? I tried to change the version but after compiling, it just uses the initial version. Btw: I check the version by doing right click, properties then details tab. – Ozkan Jan 30 '19 at 17:00
  • Did you use save module? Check all the options in there as well. It is definitely possible to do as I've done it before successfully. – rollsch Jan 31 '19 at 22:51
11

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.

Ying
  • 1,142
  • 2
  • 15
  • 19
3

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

Robert Wagner
  • 17,515
  • 9
  • 56
  • 72
  • 4
    Nice idea, but no, it doesn't work - LoadFile() loads the right assembly, but the when the referenced assembly is used it still gets loaded from the GAC. :( – EMP Nov 06 '08 at 06:20
  • 2
    There is no managed way to load a local copy of a GAC'd assembly – JaredPar Nov 06 '08 at 06:51
  • Use dnspy to modify the dll's signature and version, then you could force loading your custom hacked dll. – rollsch Jan 14 '19 at 05:51
2

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.

Community
  • 1
  • 1
dasons
  • 493
  • 5
  • 12
1

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.

Charles Owen
  • 2,403
  • 1
  • 14
  • 25
0

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

gharel
  • 413
  • 4
  • 13