Exception with assembly resolution
dazinator opened this issue · 13 comments
I have shipped a nuget package that contains an assembly that references Microsoft.Extensions.FileProviders.Abstractions version 1.0.0.0. (i.e it depends on the 1.0.0 nuget package)
The following shows this assembly and it's reference:
Now, I have a brand new solution, in which I have a project foo and a project foo.tests.
In project foo I added a package reference to my nuget package above.
I have also added a package reference to Microsoft.Extensions.FileProviders.Abtsractions version 1.0.1 to project foo and to project foo.tests. This is because I want to use the later version of Abtsractions assembly than the version my dependency has bought in.
When I run foo.tests - for any test that utilises this dependency, I get this exception:
It seems that dependency is explicitly looking for version 1.0.0.0 of the Abstractions assembly, where as I have upgraded to 1.0.1 so only 1.0.1 is available in the bin folder:
My question is, how do I solve this so that people can adopt my nuget package, but still update the Abstractions nuget package to later patch versions? In days of old, I would expect to add an assembly binding redirect to the app.config file (nuget usually did this for you) - except my projects do not have an app.config file anywhere to be found, and no option to add one either through project --> add new item dialog - because this is netstandard / netcore.
The following shows the dependency tree for my foo.tests project in case it's useful.
@dazinator can you share a minimal repro?
@natemcmaster - sure - here you go: https://github.com/dazinator/NetPack/tree/repro-assy-resolve
Just open the solution in VS 2017, build, and run the unit test.
Is this VS only? I have preview builds of VS installed, so not sure if my newer version fix it, but this passes fine on command line using .NET Core CLI 1.0.1.
Nvm, got a repro. Likely duplicate of microsoft/vstest#428
As I mentioned microsoft/vstest#428 (comment), you can workaround with
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>Can you confirm it fixes the issue for you?
Ah yes! Adding those has fixed the issue! Awesome thanks for the quick response.
Closing as duplicate of microsoft/vstest#428
Also - in case this is relevent, this became an issue after upgrading the solution from project.json based solution to the new csproj - which was done when opened in VS 2017 for the first time..
The fix is also available in a preview version of Microsoft.NET.Test.Sdk.
https://www.nuget.org/packages/Microsoft.NET.Test.Sdk/15.3.0-preview-20170425-07
Cheers.
I have applied this fix to my actual repository, but I am now seeing a different error when running some tests - just raising on the offchance this is related:
System.IO.FileLoadException : Could not load file or assembly 'Microsoft.AspNetCore.NodeServices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)
@natemcmaster I have updated the repro to show this latest problem. Would you like me to create a new issue for this one? https://github.com/dazinator/NetPack/tree/repro-assy-resolve
Try using the RTMed version of that package instead of the beta. If you still have issues, Microsoft.AspNetCore.NodeServices comes from https://github.com/aspnet/JavascriptServices.
@natemcmaster - Thanks I understand what you are indicating - i.e that there may be a problem with the signed assembly itself in that package. But if that is the case I am left wondering why these tests were prevsiously passing. I have not updated this particular package, I have only upgraded my solution form project json to csproj.. Tests that were passing now fail.
I will quickly check to see if upgrading to the RTM version of the package solves it though, cheers.
It's weird. I couldn't upgrade to the RTM version of that package because that requires me to upgrade my entire application from asp.net core 1.0.0 to 1.1.0. However downgrading the nuget package to a different version fixes it. For some reason the tests just don't like this particular assembly, even though they did before the solution upgrade. Maybe the assembly has somehow become corrupt or something, i'll try clearing my nuget cache and re-downloading the package.