Is there any way to force my asp.net application to load the assembly from local bin directory since there is another older version of the assembly with the same name in the gac?
I can’t delete the gac version since other applications are using it and I am facing some difficulties when adding the newer version to the gac.
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
I found it
To force your application to read from local bin directory you have to remove signing from your assembly and then the application will load the assembly from bin.
Thanks Wyatt Barnett and murad.
Change the version number, strong name the assembly and reference the strongly named higher version you deploy with your solution.
The oldVersion configuration that is suggested by Muse VSExtensions works! You can use the strong name for the local assembly:
Please look this page:
Basically in web.config add something like:
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="DllName" publicKeyToken="0123456789abc" culture="neutral" /> <!-- Assembly versions can be redirected in app, publisher policy, or machine configuration files. --> <bindingRedirect oldVersion="220.127.116.11-18.104.22.168" newVersion="22.214.171.124" /> </dependentAssembly> </assemblyBinding> </runtime>
That way if i have an assembly in the gac that can be from version 126.96.36.199 to version 188.8.131.52 all the calls would be redirected to the newVersion (184.108.40.206)
In the assemblies section I added the assembly:
<add assembly="DllName, Version=220.127.116.11, Culture=neutral, PublicKeyToken=0123456789abc" />
And that’s it.
As an alternative to the proposed solution, during development you can bind to whatever assembly you want overriding the GAC completely by setting the
DEVPATH environment variable and enabling Development Mode in the
machine.config. I think this is by far the easiest way to achieve what you want, but should not be used in production.
This solves the issue where version of your assembly and the one in the GAC are the same, if versions are different, you should use the
bindingRedirect approach mentioned here by several users.
First, add the following to
<configuration> <runtime> <developmentMode developerInstallation="true"/> </runtime> </configuration>
Then, set the
DEVPATHenvironment variable to the location of your non-signed assemblies. This will force Fusion’s DEVOVERRIDE mode to kick in and search the
DEVPATH(and its subdirectories) prior to probing the GAC.
An FAQ of
DEVOVERRIDE on MSDN will answer most questions on the effects of using this.
Fusion (.NET’s assembly loader) will search by name and version only, it will treat strongly named assemblies equal to other assemblies, won’t search the GAC before searching
DEVPATH, and simply returns the first match found. You should use the Fusion Log Viewer (fuslogvw) to see that you properly enabled it, as explained in this blog post on
New to using FusLogVw? Scott Hanselman wrote an excellent intro. The interface of the Viewer is rather archaïc and takes a little getting used to.
Note that the Fusion Log Viewer (or Assembly Binding Log Viewer, what’s in a name) will confusingly say that you used the
DEVOVERRIDE environment variable. It should look something like this:
LOG: Found assembly in DEVOVERRIDE path D:testassembliesTest.DLL
NOTE: if you want Visual Studio to load the assemblies from the
DEVPATH location, you should set a registry key to this location, i.e., set (check the .NET version key to match your .NET version):
[HKEY_CURRENT_USER SOFTWARE Microsoft .NETFramework v2.0.50727AssemblyFoldersEx DEVPATH]@="C:SharedAssemblies"
Based on the excerpted notes on assembly loading order in this answer:
How to prevent a .NET application from loading/referencing an assembly from the GAC?
I am guessing that calling LoadLibrary on the local DLL file before asking the library to load as an assembly, might move it up in the search order for you.
Sadly, I am not sure how to get your LoadLibrary call to run before the framework starts loading referenced assemblies.
So this is just an idea, not a full answer.
To redirect one version to another, use the <bindingRedirect> element. The oldVersion attribute can specify either a single version, or a range of versions. For example, specifies that the runtime should use version 18.104.22.168 instead of the assembly versions between 22.214.171.124 and 126.96.36.199.
Instead of using bindingRedirect, you can specify the codebase path. I have a working example with MySQL.Data.dll.
<dependentAssembly> <assemblyIdentity name="MySql.Data" publicKeyToken="c5687fc88969c44d" culture="neutral" /> <codebase version="188.8.131.52" href="/bin/MySQL.Data.dll" rel="nofollow noreferrer noopener" /> </dependentAssembly>
This can be done in Web.config of the web application.
Why not install the version that you like into the GAC and then reference it in the GAC?