extensions: Could not load file or assembly Microsoft.Extensions.Configuration.Abstractions, Version=3.1.0.0...
I have a Visual Studio 2019 extension that references Microsoft.Extensions.Configuration v3.1.1.
This assembly gets loaded by a code generator and then that generator fails with the following error:
Could not load file or assembly Microsoft.Extensions.Configuration.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60 or one of its dependencies. The system cannot find the file specified.
Notice that the version is 3.1.0.0, not 3.1.1.0 as I was expecting.
I’ve download the Microsoft.Extensions.Configuration package from nuget.org just to see if there was something wrong with the version of the package download by our build servers. If I open Microsoft.Extensions.Configuration.dll in ILSpy I see that the reference to Microsoft.Extensions.Configuration.Abstractions.dll is indeed to version 3.1.0.0.
The problem is that the package depends on version 3.1.1, which means that it is version 3.1.1.0 of Microsoft.Extensions.Configuration.Abstractions.dll that gets deployed in my extension, breaking assembly resolution.
Is this a bug in the NuGet package?
How can I work around it in the mean time?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 5
- Comments: 36 (15 by maintainers)
@anurse I can see that you have closed this thread but the problem still remains in a scenario where I cannot see that it has been addressed above. I’ve also followed issue #3213 (please do correct me here if I missed the proposed solution for this).
What is the recommendation for solving the following scenario which generates very much the same type of issue:
net standard 2.0 class libraries where the following dlls are referenced directly or indirectly
Microsoft.Extensions.DependencyInjection Microsoft.Extensions.DependencyInjection.Abstractions Microsoft.Extensions.Logging Microsoft.Extensions.Logging.Abstractions Microsoft.Extensions.Http
The problem occurs whith the following combination
System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Extensions.DependencyInjection.Abstractions, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’ or one of its dependencies.
Having referenced 3.1.3.0 previously for the class libraries, it now has been downgraded to 3.1.0.0 to make this work. This workaound prevent currently to upgrade libraries to latest and greatest version keeping up with improvements and possibly new features.
.net core related project, as of my understanding, will automatically be able to reference higher versions wihout a need for bindingRedirect whereas using .net framework bindingRedirect would be needed. Here we have a 3rd party application in Python loading these class libraries and having the version problem on Microsoft.Extensions.DependencyInjection.Abstractions.
How to you suggest to solve this case?
@Pilchie Your suggested workaround will not work in our case - our .NET ‘app’ is an add-in to a third-party application and we cannot edit that application’s binding redirects. Why does Microsoft.Extensions.DependencyInjection v3.1.3 have a runtime dependency on Microsoft.Extensions.DependencyInjection.Abstractions v3.1.0? When will this be resolved? Could you fix this for us by providing a publisher policy assembly?
(“Dll Hell” is here to stay)
Closing this thread. The behavior we have of linking against the
X.Y.0version of assemblies is intentional to ensure patches work well together. It does mean binding redirects are necessary and there are various places where that is more challenging (MSBuild, VS Extensions, etc.). Some guidance for that has been provided in this thread.@jason-daly said:
The reason is because that’s the desired before for .NET Core assemblies that might be in the .NET Core shared framework. This allows the newer package to work with any version of the shared framework, and for installing the shared framework to fix things even if the package isn’t updated. It’s unfortunate (and our team didn’t realize) the impact that has on binding redirects when running on .NET Framework. Fixing it is difficult - it basically means multi-targeting a bunch of packages across .NET Framework and .NET Core and .NET Standard, and having different versioning policies in each. Making a change that large and risky for a servicing release isn’t something we’re very comfortable doing.
Ah. @dougbu - here’s an example of what we were talking about where packages that support .NET Framework need to have different version requirements than ones entirely on Core.
@hugoqribeiro I think you should be able to work around this by adding an app.config file with a
<bindingRedirectentry for that assembly.