Error while loading assembly on separated AppDomain - c#

My application creates multiple AppDomains and I manually configure the binding redirects via the SetConfigurationBytes method. I grab the config file, check for all assemblies installed on the private folder and then set the assemblyRedirect as on the example below. This is to ensure that I'll always use the shipped version of a given assembly:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" culture="neutral" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="2.2.18.0" />
</dependentAssembly>
However, when an assembly being loaded in a different AppDomain depends upon the System.Net.Http assembly, I get the following error: System.IO.FileLoadException: Loading this assembly would produce a different grant set from other instances.
There's two possible ways I've saw to solving this: either by removing the <dependentAssembly> element on the config for this DLL, or to add this assembly on the GAC.
I didn't like any of this because the first may cause problems with other assemblies and the second relies on the GAC, which some of my clients don't like.
Anyone have a different idea on how to solve this?
Thanks in advance.

Related

Assembly Redirecting not pointing to the expected assembly

I am trying to do assembly redirecting in the following way:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
</dependentAssembly>
But I am getting the following exception at runtime:
Inner Exception 1:
MissingMethodException: Method not found: 'System.Net.Http.HttpClient
ServiceStack.JsonHttpClient.GetHttpClient()'.
I tried to find the modules that are loaded during runtime and I found the following:
As you can see that System.Net.Http.dll has been loaded twice and each with different version to different place. It is happenning even after I have included the assembly redirection mentioned above.
The project that I am buiding creates .dll file and it refer to several other projects with x86 build. It is based on .NET 4.6.1 and not possible to update due to other unavoidable dependencies. Cleaning and rebuilding the whole project did not help.
Any further idea to try with ?
------------------------------- EDIT --------------------------------------
The service stack is loaded as well without duplicate which I am having in System.Net.Http . Check the following screen-shot:

Assembly.LoadFrom how behaves on multi version dll

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.

Application trying to reference incorrect assembly version

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.

Strong named assembly alongside unsigned assembly

I have a situation where Docusign API is referencing the RestSharp signed assembly with a public key token of 598062e77f915f75. In the same project I am using the Twilio API which also references the unsigned Restsharp assembly, obviously with a null public key token.
I can make one or the other work but not both at the same time since I can't add both the signed and unsigned RestSharp references since they both have the same name.
When I have a reference to the signed assembly, the Docusign part works but the Twilio code errors with this:
Could not load file or assembly 'RestSharp, Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
When I reference the unsigned assembly, Docusign errors with this:
Could not load file or assembly 'RestSharp, Version=100.0.0.0, Culture=neutral, PublicKeyToken=598062e77f915f75' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Is there any way around this?
I have tried binding redirects in every combination I can think of:
<dependentAssembly>
<assemblyIdentity name="RestSharp" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-100.0.0.0" newVersion="105.2.3.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="RestSharp" publicKeyToken="598062e77f915f75" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-100.0.0.0" newVersion="105.2.3.0" />
</dependentAssembly>
I can think of few possible ways to solve this issue:
Binding redirect. Works if assemblies have same public key, otherwise you need to specify code base. See SO answer: Referencing 2 different versions of log4net in the same solution
Using GAC. Not sure if it would work with unsigned assembly.
Making use of AppDomain.AssemblyResolve event (see How to use Assembly Binding Redirection to ignore revision and build numbers)
Signing / unsigning assembly with one key using ildasm.
I once had similar issue with different log4net versions being referenced by our project and 3rd party library. Here is a blog post.
I was facing the same issue. I have used the Nuget package of RestSharpSigned. This resolved my issue.
Try to redirect every version up to the current to the latest installed version:
<dependentAssembly>
<assemblyIdentity name="RestSharp" publicKeyToken="598062e77f915f75" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-105.2.3.0" newVersion="105.2.3.0" />
</dependentAssembly>

Could not load file or assembly Telerik.Web.UI in ASP.NET

I had telerik version 2012.2.607.35 When I update it to version 2015.2.623.45
I got this error:
Could not load file or assembly 'Telerik.Web.UI,
Version=2012.2.607.35, Culture=neutral, PublicKey
Token=121fae78165ba3d4' or one of its dependencies. The located
assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)
I replaced all reference telerik to version 2015.2.623.45 in project references but the error exist yet.
While the assembly binding redirect is a way to solve this, as suggested by the answer, I would advise you to find the fully qualified assembly reference and make it non-fully qualified. It is likely to be a Register directive in the web.config or in a user control. Doing that will make future updates easier, otherwise you will get the same error the next time you upgrade unless you also update the bindingRedirect.
you should define assembly in web.config file
<dependentAssembly>
<assemblyIdentity name="YourDllFile" publicKeyToken="2780ccd10d57b246" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-YourDllFileVersion" newVersion="YourDllFileVersion" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
<bindingRedirect oldVersion="1.0.0.0-2015.2.600.45" newVersion="2015.2.623.45" />
</dependentAssembly>
I had a similar problem. I checked the version of the .dll in the bin folder on my website and the version throwing the error. Since the code where the error was being thrown was not my own, I realised the version of the .dll was a dependency of 3rd party code. As it turns out the .dll in my bin had been overwritten with an older version.
Solution was to put the correct version of the .dll in the bin folder (since this was installed with the application initially) seems an update failed to install the newer version.

Categories