I've a dll with 2.0.0.1 version in one server which can be downloaded by accessing http://someipaddress/assembly/test.dll and I'm having another application which need to download this test.dll and have to access those methods.
When surfing for this, i've got three different methods to do,
1. Assembly.LoadFrom()
2. Assembly.LoadFile()
3. Assembly.Load()
I've tried Assembly.LoadFrom("http://someipaddress/assembly/test.dll")
Now i've replaced test.dll with 2.0.0.2 version and
What will happen the application download 2.0.0.2 test.dll and already downloaded test.dll 2.0.0.1.
Application which dll will refer?
Will it use existing test.dll 2.0.0.1 since its already downloaded while accessing test.dll 2.0.0.2?
Please suggest on this.
It'll depend on how you're referencing the assembly. By default if there's no binding redirect, your new dll will cause an exception. You can get around this by specifying an binding redirect rule in your application's configuration file like so;
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Test" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.2" newVersion="2.0.0.2" />
</dependentAssembly>
</assemblyBinding>
</runtime>
But you'd need to update it upon getting the new version of the dll.
Related
I'm getting the following exception when trying to call GetDatabase method of the MongoClient class after adding a new configuration using VS config. manager:
Could not load file or assembly 'System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I installed the latest System.Buffer nuget package v4.5.1, created dependentAssembly in my app.config and Reference in my .csproj file, but I still have the same issue. For some reason it tries to reference System.Buffer with v4.0.2. Has anyone had a similar error and how did you solve it?
Could not load file or assembly 'System.Buffers, Version=4.0.2.0…'
Solution
1) use CMD(run as Administrator ) and type
cd xxxx(xxxx\packages\System.Buffers.4.5.1\lib\netstandard2.0))
run
gacutil /i System.Buffers.dll
Then, when you finish it, please run update-package -reinstall under package manager console to reinstall the package.
2) you can try to change Version=4.0.2.0 to Version=4.0.3.0 in csproj file.
Besides, there is a similar issue you can refer to.
The easiest way is to use Nuget package manager, downgrade system.buffers to any lower version, and then upgrade it to the latest again.
In my case, I had to add the assembly reference in the web.config that was already published in the Azure App Service, inside the <configuration></configuration> tag:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I ran into this issue when adding the Azure.Storage.Blobs package to a Class Library where I was attempting to create a blob uploader client. When I added the package, it created an app.config with the correct binding redirect:
<dependentAssembly>
<assemblyIdentity name="System.Buffers" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
</dependentAssembly>
<dependentAssembly>
The issue, however, is that this binding redirect needs to live in the app.config of the application, not the class library: Can a class library have an App.config file?
So, adding the binding redirect is the correct way to solve this issue. Just make sure the binding redirect is specified in the calling web/console/etc app.
Another solution: just remove references to the assembly in the Web.config files of the projects generating the exception.
The references can look like:
<dependentAssembly>
<assemblyIdentity name="System.Text.Encodings.Web" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.4.0" newVersion="4.0.4.0" />
</dependentAssembly>
I ran into a similar issue, tried all the steps above. In the end, another project had an older version of the same library. Too many projects in the solution, the other reference was scrolled out of view.
I have a visual studio project with is running absolutely fine.
But a new client requirement comes up for deployment for placing the different dlls in different folders.
We have a framework dll which can be used in a different project. There are some third-party dlls on which this framework dll depends upon. So when I use this dll from my project every dependent dll is copied to my local on the build as CopyLocal property is true.
But now with new requirement we can not have CopyLocal property set as True. The client wants no local copy of any dll, rather he wants framework related dll in some location. When I am doing this the dependent DLL's are not getting loded.
I know I have two options:
I can put them in GAC, but I don't want to do this as I want them to support xcopy.
Using reflection(But I am not sure of this that is this the right approach)
Can we do anything using configurations??
You can configure assembly probing paths using the <probing> configuration element:
Specifies application base subdirectories for the common language runtime to search when loading assemblies.
Example from MSDN:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
However, if the assemblies in question reside outside the application base ("which is the root location where the application is being executed"), you have the <codeBase> configuration element:
Specifies where the common language runtime can find an assembly.
Example from MSDN:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<codeBase version="2.0.0.0"
href="http://www.litwareinc.com/myAssembly.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
For the exact details of how the runtime locates assemblies you can refer to this MSDN article.
As OP pointed out, unfortunately codeBase element is a usable option for strong named assemblies only. For private assemblies you need a workaround. Some viable ideas can be found in this discussion such as:
file system links (NTFS junction point) + probing element or AppDomainSetup.PrivateBinPath
AppDomain.CurrentDomain.AssemblyResolve event
I've tested the latter and can confirm it works:
AppDomain.CurrentDomain.AssemblyResolve += (s, e) =>
Assembly.LoadFile(Path.Combine(Settings.Default.AssemblyPath, Path.ChangeExtension(e.Name.Substring(0, e.Name.IndexOf(',')), ".dll")));
I have a application running on a windows server 2012 that was using Telerik.Web.UI.dll version 2014.1.403.45.
During the latest deployment the Telerik dll under /bin folder got updated with 2015.1.401.40.
Because of new dll some functionality stopped working.
When i replace the dll on server with older version i get following error
Parser Error Message: Could not load file or assembly 'Telerik.Web.UI, Version=2015.1.401.40, Culture=neutral, PublicKeyToken=121fae78165ba3d4' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I also tried to assembly binding
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" culture="neutral"/>
<bindingRedirect oldVersion="2015.1.401.40" newVersion="2014.1.403.45"/>
<assemblyIdentity name="Microsoft.WindowsAzure.Storage" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-2.1.0.4" newVersion="2.1.0.4"/>
</dependentAssembly>
</assemblyBinding>
I am still getiing the same error.
Is there any way to handle this without deplying the entire code again?
i got this type of issue, but in different case(in Unit Testing). for that I cleared the Bin. then did a build. then issue resolved for me.
Maybe there is a way, but I would redeploy. Build it again with the reference to the older version. That's the safest way and the best way to make sure all references point to the same assembly.
To be absolutely sure about the right references, set the dll to copy to local is true, and copy and replace it with the one on your server.
I have the following dll hell:
a ASP.Net project
references WebGrease
which references Antlr3.Runtime.dll 3.3.1.7705 [stored in /bin/ folder of the asp.net app]
references Custom project
which references NCalc.codeplex.com
which references Antlr3.Runtime.dll 3.1.3.22795 [stored in /bin/CustomProject/ folder of the asp.net app]
unsurprisingly these two version of Antlr are not working well together and I get "The located assembly's manifest definition does not match the assembly reference" errors
I am unwilling to modify the WebGrease project.
I am attempting to upgrade the NCalc project to use 3.3.1.7705 however I am struggling with this
Do you have any suggestions on how to get these two DLL's to work together?
EDIT unfortunately the NCalc code is not compatible with the newer version of antlr so I cannot used binding redirects
Thank you
Providing NCalc can use the later version of Antlr3.Runtime - ie there are no breaking changes you should be able to use a binding redirect to direct it to load the later version
eg in the web.config file ass something like
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NCalc" publicKeyToken="xxxxxxxxx" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.3.0" newVersion="3.3.1.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I don't think the 4th digit on the versions is used
I am trying to downgrade a NServiceBus dependency so instead of using 4.0.0.0 to use 2.5.0.0
I am trying with the following ways, none of which seem to work.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NServiceBus"
publicKeyToken="9fc386479f8a226c" culture="neutral"/>
<bindingRedirect oldVersion="4.0.0.0" newVersion="2.5.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
I also tried with codebase :
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NServiceBus"
publicKeyToken="9fc386479f8a226c"
culture="neutral"/>
<codeBase version="2.5.0.0" href="NServiceBus.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Still, nada. I went through the msdn documentation and there is no mention of using this capability in a backwards way. Is this possible?
I'm actually using your first statement for some interop DLLs because the clients in our company have a different state regarding office updates. This is the code I use :
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="office" publicKeyToken="71E9BCE111E9429C" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="11.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
This provides backwards compatibility from version 14 of the DLL to version 11. Could you provide a link to the DLL u are using?
I've downloaded the NServiceBus framework (version 3.3.8) and investigated the DLL with ILSpy. I would suggest you do the same with your DLL. For my DLL it shows me the same public Key token as yours. Are you sure, that you use version 4.0.0.0 and not verision 3.3.0.0. Or you missmatched the public Key tokens perhaps.
According to MSDN: https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110).aspx
This value can specify an earlier version than oldVersion.
referring to the newVersion attribute of bindingRedirect. Also in the "Remarks" section:
You can also redirect from a newer version to an older version of the assembly.
Their example is:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
I did notice it also mentions something about Explicit assembly binding redirection in an application configuration file requires a security permission, maybe that's affecting you as well?
The answers above are good answers but they are missing important part. And if you read comments, some devs no longer believe this is working. In fact, this is working and working both ways, up version or down
Important: culture
In my experiment, it started to work only when I set culture to neutral. (examples above have 'en-us')
<assemblyIdentity name="..... culture="neutral"/>
In my setup I have WinApp that references Lib1 and Lib3. Lib1 references Lib2 and Lib3. Lib2 references Lib3. And when I push the button, a call propagated all the way from WinApp to Lib3 (both, direct and through chain of libs), and text return displayed on screen. Lib3 is strong named.
Run 1 - no culture set [assembly: AssemblyCulture("")], no binding redirect set - WORKS!
Run 2 - Lower version in Lib3, set binding redirect to 'en-us' - FAIL!
Run 3 - Lower version in Lib3, set binding redirect to 'neutral' - WORKS! Works up-version and down-version.
On other runs - playing with setting [assembly: AssemblyCulture("en-us")] - all attempts failed when AssemblyCulture was not empty. In fact, when set this attribute in WinApp, it wouldn't even compile
Error CS7059: Executables cannot be satellite assemblies; culture should always be empty
So, here we go. Since I don't understand all intricacies of role of the AssemblyCulture I only claim that my experiment only proves that under specific conditions version redirect works fine.
If I didn't get you wrong I have done the same thing with stimulsoft report DDLs which I had the latest version installed but I wanted 2010.3 in my application. but not through the config file and redirecting:
I simply removed the reference from the solution explorer and added the old DLL refrence, then I set the copy Local property and recompiled so that the DLL would go with application in a same directory, every thing works fine. also done it with some other dlls as well.