Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

"Could not load file or assembly" with BindingRedirect
tkarlsen
#1 Posted : Tuesday, April 25, 2017 2:42:48 PM(UTC)
Rank: Member

Groups: Registered
Joined: 3/30/2017(UTC)
Posts: 19
Location: United States of America

Was thanked: 4 time(s) in 4 post(s)
I'm running NCrunch 3.6.0.2 on VS 2017, and I have an ASP.NET Core project targeting .NET 4.6.2 and a library project that also targets .NET 4.6.2 but also has dependencies on some .NET Core stuff because I moved some of my data classes into it.

I have an NUnit test library project that runs tests only on the library project. NCrunch builds everything fine, and most tests pass, but a lot of the tests fail with the following runtime exception:

Quote:
System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.


VS 2017 added the following to my app.config after adding the .NET Core dependencies:

Quote:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Interactive.Async" publicKeyToken="94bc3704cddfc263" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.0.3000.0" newVersion="3.0.3000.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Runtime.Extensions" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Reflection" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.IO" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Diagnostics.Tracing" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Runtime.InteropServices" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>


If I delete these lines from the app.config in the test library project, everything runs just fine. However, every time I update Nuget packages VS 2017 puts those lines right back in there so it's a bit of a pain. Any ideas on how to better fix this issue?
Remco
#2 Posted : Tuesday, April 25, 2017 11:51:53 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Hi, thanks for sharing this problem.

I'm a little confused by this, as I was always under the impression that .NET Core and .NET 4.6.2 were mutually exclusive (hence why .NET Standard exists). How is it that you've managed to build this structure? Is there a reason you're not using multi-targeting or .NET Standard to share code between these two different platforms?
tkarlsen
#3 Posted : Wednesday, April 26, 2017 12:43:06 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/30/2017(UTC)
Posts: 19
Location: United States of America

Was thanked: 4 time(s) in 4 post(s)
Remco;10319 wrote:
Hi, thanks for sharing this problem.

I'm a little confused by this, as I was always under the impression that .NET Core and .NET 4.6.2 were mutually exclusive (hence why .NET Standard exists). How is it that you've managed to build this structure? Is there a reason you're not using multi-targeting or .NET Standard to share code between these two different platforms?


You can create an ASP.NET Core project but still target the full .NET framework, and the reason I'm doing that is because I have some dependencies on third party libraries that target the full framework. Here's an explanation of how (and why) to do it:

Use ASP.NET Core 1.1 with .NET 4.6

I changed the TargetFramework to net462. It builds and runs fine, so I'm not sure why it's throwing a runtime exception in NCrunch.
Remco
#4 Posted : Wednesday, April 26, 2017 3:31:14 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
tkarlsen;10320 wrote:


You can create an ASP.NET Core project but still target the full .NET framework, and the reason I'm doing that is because I have some dependencies on third party libraries that target the full framework. Here's an explanation of how (and why) to do it:

Use ASP.NET Core 1.1 with .NET 4.6

I changed the TargetFramework to net462. It builds and runs fine, so I'm not sure why it's throwing a runtime exception in NCrunch.


Interesting. I had no idea this was possible, but the purpose does make sense. Thanks for making me aware of it.

Right now NCrunch has a fairly binary view of .NET Core vs .NET Framework - it's either one or the other with no intention of libraries being shared between them. .NET Core projects have quite different considerations, especially in the areas of runtime assembly resolution .. so I guess it shouldn't be a surprise that the first problem we see here is an assembly resolution one.

I'll need to learn a bit more about the structure of your solution before I can start to draw any conclusions about how to address this use case. If you happen to have a sample solution you can share with me that produces this problem, this would be tremendously helpful. You're welcome to zip up and submit any code through the contact form - https://www.ncrunch.net/support/contact.

Of particular interest to me at the moment is how your test project is configured. Is this a .NET Core project, or is it a .NET Framework one? Does it use the new CPS system (reduced project XML)?
tkarlsen
#5 Posted : Wednesday, April 26, 2017 4:11:06 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/30/2017(UTC)
Posts: 19
Location: United States of America

Was thanked: 4 time(s) in 4 post(s)
Remco;10321 wrote:
tkarlsen;10320 wrote:


You can create an ASP.NET Core project but still target the full .NET framework, and the reason I'm doing that is because I have some dependencies on third party libraries that target the full framework. Here's an explanation of how (and why) to do it:

Use ASP.NET Core 1.1 with .NET 4.6

I changed the TargetFramework to net462. It builds and runs fine, so I'm not sure why it's throwing a runtime exception in NCrunch.


Interesting. I had no idea this was possible, but the purpose does make sense. Thanks for making me aware of it.

Right now NCrunch has a fairly binary view of .NET Core vs .NET Framework - it's either one or the other with no intention of libraries being shared between them. .NET Core projects have quite different considerations, especially in the areas of runtime assembly resolution .. so I guess it shouldn't be a surprise that the first problem we see here is an assembly resolution one.

I'll need to learn a bit more about the structure of your solution before I can start to draw any conclusions about how to address this use case. If you happen to have a sample solution you can share with me that produces this problem, this would be tremendously helpful. You're welcome to zip up and submit any code through the contact form - https://www.ncrunch.net/support/contact.

Of particular interest to me at the moment is how your test project is configured. Is this a .NET Core project, or is it a .NET Framework one? Does it use the new CPS system (reduced project XML)?


Thanks for the quick replies! I don't think I'm doing anything out of the ordinary for this use case. What happened was I already had the regular library project and the test project, both regular .NET Framework projects with the same looking XML project files. Then I decided to port my Webforms website to ASP.NET Core, and created an ASP.NET Core project. I set the ASP.NET Core project to target .NET 4.6.2, and everything is fine, including the tests, because I wasn't testing anything in the ASP.NET Core project.

The problem occurred when I moved a .NET Core class from the ASP.NET Core project to my library project. Specifically, I moved the ApplicationUser class (which inherits from the .NET Core class IdentityUser<>) so I could keep all my data classes in the library project. Since it inherits from a .NET Core class, all of a sudden a million .NET Core Nuget packages were added to my library project, and that's when Visual Studio started putting in the BindingRedirects. I didn't manually change anything in my library project or my test project to make it target .NET Core.

I'll see if I can try to create a simple solution demonstrating the problem tomorrow.
Remco
#6 Posted : Wednesday, April 26, 2017 11:41:16 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
tkarlsen;10322 wrote:

I'll see if I can try to create a simple solution demonstrating the problem tomorrow.


Thanks for doing this. Having looked as much as I can at this issue, I don't think I'll be able to progress with it further without a code sample.
tkarlsen
#7 Posted : Thursday, April 27, 2017 1:37:04 AM(UTC)
Rank: Member

Groups: Registered
Joined: 3/30/2017(UTC)
Posts: 19
Location: United States of America

Was thanked: 4 time(s) in 4 post(s)
Remco;10324 wrote:
tkarlsen;10322 wrote:

I'll see if I can try to create a simple solution demonstrating the problem tomorrow.


Thanks for doing this. Having looked as much as I can at this issue, I don't think I'll be able to progress with it further without a code sample.


I just spent some time trying to reproduce it in a new project without much success. Everything seems to work even with the BindingRedirects in a fresh solution with the same basic layout. I'll have to do some more experimentation to see what's going on. The tests that are failing seem to all be Stream related, but the exception seems to be thrown in weird places that don't make much sense. I'll try to fiddle with the code and see if I can narrow it down.
Remco
#8 Posted : Thursday, April 27, 2017 1:44:55 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,144

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
tkarlsen;10325 wrote:

I just spent some time trying to reproduce it in a new project without much success. Everything seems to work even with the BindingRedirects in a fresh solution with the same basic layout. I'll have to do some more experimentation to see what's going on. The tests that are failing seem to all be Stream related, but the exception seems to be thrown in weird places that don't make much sense. I'll try to fiddle with the code and see if I can narrow it down.


I'm not sure if this helps, but I've had enough bad experiences with assembly resolution conflicts to know that very often when there are multiple assemblies in the same application domain that contain the same type names, things seem to get very messy inside the CLR. Keep an eye on the included modules inside your test application domain when you have a debugger attached, and make sure they match the list of assemblies that you would expect to be loaded. I wouldn't be surprised if the intermittent behaviour you're experiencing is a result of type clashes and the variance of behaviour is caused by something totally random, like the sequence in which the assemblies are loaded.

This setting might be worth a look. I don't think this will solve the problem itself, but it might shake things up a little :)

http://www.ncrunch.net/documentation/reference_project-configuration_preload-assembly-references.
abdulhameedinfo
#9 Posted : Tuesday, August 14, 2018 10:22:49 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/14/2018(UTC)
Posts: 1
Location: Pakistan

Was thanked: 1 time(s) in 1 post(s)
Hi, i faced the same problem. After spending complete day i come up with the solution which work for me.
Go to Web.config file -->
runtime tag --> assemblyBinding --> Find
<bindingRedirect under <assemblyIdentity name="System.Runtime" -->
<bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0"/>
Update the highlighted part as below:
<bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.5"/>
build all solution. This worked for me. Thank you.
1 user thanked abdulhameedinfo for this useful post.
Remco on 8/14/2018(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.084 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download