Extensions: Could not load file or assembly Microsoft.Extensions.Configuration.Abstractions, Version=3.1.0.0...

[hugoqribeiro]

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?

[Pilchie]

See https://github.com/aspnet/announcements/issues/401 - You should be able to workaround this by adding a <PackageReference for the dependency package. This should be fixed in our next servicing update.

[Pilchie]

Can you try that and let me know if that works around the issues?

[hugoqribeiro]

It does not.
This is a csproj with packages.config (.NET 4.7) (a VSIX for Visual Studio).
I've tried referencing the 3.1.0 package in there but the build fails with "Detected package downgrade error".

This reference is really transient:

Modeling.ServiceDesigner.CodeGeneration (NET) references...
Primavera.Hydrogen.DesignTime.Specs (NETStandard) that references...
Primavera.Hydrogen.Core (NETStandard) that references...
Microsoft.Extensions.Logging that references...
Microsoft.Extensions.Configuration.Binder that references...
Microsoft.Extensions.Configuration that references...
Microsoft.Extensions.Configuration.Abstractions

More

Modeling.ServiceDesigner.CodeGeneration also references Primavera.Hydrogen.Core.
Other projects in the SLN reference Primavera.Hydrogen.Core.

This results in that the final bin directory that gets packaged in the VSIX file contains version 3.1.1.0 nevertheless.

[Pilchie]

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 <bindingRedirect entry for that assembly.

[Pilchie]

Moving out of 3.1.2, since it's unlikely we'll be able to address this in that release.

[hugoqribeiro]

Why? Isn’t just a question of fixing the reference of Microsoft.Extensions.Configuration to Microsoft.Extensions.Configuration.Abstractions?

[Pilchie]

We're already locking down to validate what we hope is our final build for 3.1.2.

[jbaehr]

Please note that Microsoft.Extensions.DependencyInjection is also affected: Microsoft.Extensions.DependencyInjection v3.1.1 has a runtime dependency on Microsoft.Extensions.DependencyInjection.Abstractions v3.1.0

[codehunter13]

same error here. our codegenerators are failing and we are blocked... Please fix

[Pilchie]

@codehunter13 The recommendation here is that you add a binding redirect to the version that is deployed. We can't update the dependency to point to patch versions, or that breaks people that get the assembly via the .NET Core Shared Framework.

AFAIK, the only way for us to fix this would be completely restructure these packages to have different dependencies entirely for .NET Framework, .NET Standard, and .NET Core. That's unlikely to be something we tack for a servicing release, because the risk is too large.

Adding @ericstj in case he has any other ideas.

[jason-daly]

@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)

[davidfowl]

😞

[TimPurdum]

Ditto for this being a large issue. Started using the DI framework in common code, but I also have to support existing VB6 applications, and creating a .config for each one is a big issue based on release processes.

EDIT A workaround that works for my situation is rolling back to DependencyInjection version 3.1.0

[codehunter13]

@codehunter13 The recommendation here is that you add a binding redirect to the version that is deployed. We can't update the dependency to point to patch versions, or that breaks people that get the assembly via the .NET Core Shared Framework.

How do you add a binding redirect to a visual studio extension?

Currently i rolled back to version 3.1.0. but now i got the error:
Could not load file or assembly 'System.Text.Json, Version=4.0.1.0
Calling assembly : Microsoft.Extensions.Configuration.Json, Version=3.1.0.0
Assembly Name is: System.Text.Json, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
WRN: Comparing the assembly name resulted in the mismatch: Revision Number

DLL Hell is back :(

[Pilchie]

VS allows you to add binding redirects via ProvideBindingRedirectionAttribute

[jbaehr]

@Pilchie That's good to know, thanks!

Do you have a similar trick at hand for MSBuild tasks? I have this issue with GitVersionTask

[Pilchie]

I don't think MSBuild has anything yet, although they were looking at it. Paging @rainersigwald for that. In the meantime, I think the guidance has been to use a ToolTask so that you have your own exe and can have your own config.

[Pilchie]

@jason-daly said:

Why does Microsoft.Extensions.DependencyInjection v3.1.3 have a runtime dependency on Microsoft.Extensions.DependencyInjection.Abstractions v3.1.0?

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.

[phantom2017-Nov]

Can you please advise as to exactly how we add the "ProvideBindingRedirectionAttribute" to an Azure Function App project / Solution ?

Exact error I am getting is this:

Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified. System.Private.CoreLib: Could not load the specified file.

This is quite frustrating to say the least .. Please help.

(targeting - asp.net core 2.2)

[ericstj]

/cc @joperezr

[Pilchie]

ProvideBindingRedirectionAttribute is specific to Visual Studio. I don't know if there is a way to do something similar for Functions or not.

[phantom2017-Nov]

I am using Visual Studio 2019 / 16.5.2 -- Asp.net core 2.2 / Class library project

[phantom2017-Nov]

Added this to the App.config:

publicKeyToken="adb9793829ddae60"
culture="en-us" />

Still no luck .. same error as before ..

[phantom2017-Nov]

[joperezr]

@phantom2017-Nov if you are targeting asp.net core, then you are hitting a problem that is not the same as the one people are hitting in .NET Framework. Your case is probably caused by not deploying your application correctly or having some custom deployment mechanism or reference mechanism which is not copying any version of Microsoft.Extension.*.dll you depend on to your bin folder.

The ones hitting it in .NET Framework are caused by having two dependencies and having those dependencies themselves depend on different versions of Microsoft.Extensions.*. So basically whatever the newest version is will end up in the bin directory right next to your library, but your dependency that depended on the older version won't be able to find it as it will only find a newer version. This is a classic binding redirect problem, and it can be fixed either by using the attribute that @Pilchie shared above, by editing your App.config (or web.config if on a web.project) or if your project output is a library (for .exes we generate binding redirects automatically) you have to add a property into your .csproj

    <PropertyGroup>
      <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
    </PropertyGroup>

in order for a .dll.config file to get generated automatically by MSBuild which will contain the binding redirect. Then, hopefully the app host that will load your .dll will respect this .dll.config when loading and will apply the right binding redirects.

@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.

@jason-daly if the host of the app loads libraries as they should be, then they should be also respecting the .dll.config file of your library and should apply the binding redirects.

[phantom2017-Nov]

I already did that - GenerateBindingRedirectsOutputType to csproj -- still no luck ..

[joperezr]

@phantom2017-Nov for your problem, if you could provide a msbuild.binlog we can try to analyze why is Microsoft.Extensions.DependencyInjection.Abstractions not being copied to the bin folder. To produce a binlog, just build using the following command from a developer command prompt msbuild yourProject.csproj /t:rebuild /bl:msbuild.binlog and share the ouptut file.

I already did that - GenerateBindingRedirectsOutputType to csproj -- still no luck ..

Yes as I explained above, yours is a completely different problem if you are targeting Core, binding redirects are ONLY relevant when running in .NET Framework.

[phantom2017-Nov]

I got that (that the issue is relevant to .Net framework) - I have now removed the app.config -- also, pl. note that I have not deployed it anywhere - simply running the code locally ...

Will run the command you have specified and get back to you...

[phantom2017-Nov]

I can see there is a warning about Newtonsoft.Json version issue .. but other than that I am not seeing much ... pl. find attached...
msbuild.txt

[phantom2017-Nov]

have used a txt extension - but it had .binlog extension

[phantom2017-Nov]

OK - I simply created a new Solution and basically did the same thing -- for some reason the error simply went away ! (the error is still happening in the original solution..)
Not only that, the dependency injections worked and the startup azure function is being called fine.. so we will never know what the issue was I guess -- very likely some packages / references messed up in the original solution.

[rainersigwald]

MSBuild does not have a mechanism to provide binding redirects for a task based on .dll.config (the Framework doesn't provide such a mechanism). The best option may be to inherit from AppDomainIsolatedTask and apply your own AssemblyResolve hook within the task, or to shell out to an application you control.

[jbaehr]

Edit: Sorry, my initial comment wasn't really helpful. I appreciate the various workaround proposals but non the less the situation is somewhat unfortunate.

[anurse]

Closing this thread. The behavior we have of linking against the X.Y.0 version 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.

[icr8ive]

@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

• Referencing any version higher than 3.1.0.0.
• These net stadnard 2.0 Libraries are referenced in 3rd party application: Python application referencing these libraries, where in this case all related assemblies are added to predefined folder in python project.

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?

[mairaw]

Also wanted to add this in case someone else runs into the same issue as I was having with an Azure Functions project and lands on this issue from Google.

I managed to fix this issue by upgrading the AzureFunctionsVersion property from v2 to v3:

  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
  </PropertyGroup>