.NET 4.81 MVC Project : ValueTuple keeps appearing in Web.Config causing web app runtime failure

[awbmansour]

Why is it that all of a sudden we started seeing this package appearing in Web.Config when we do a Nuget Package updates !?

It causes Web App runtime failure and the only solution is that we REMOVE Manually from Web.Config these lines

  <dependentAssembly>
    <assemblyIdentity name="System.ValueTuple" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.3.0" newVersion="4.0.3.0" />
  </dependentAssembly>

If we try to remove this package from the Solution, we receive an error

Unable to uninstall 'System.ValueTuple.4.6.2' because 'Microsoft.Identity.Client.4.83.3, System.Formats.Asn1.10.0.5' depend on it.

When we researched the subject on GPT / google, we found that this package is part of the FRAMEWORK and should not be mentioned in Web.Config, so why Nuget Packages refer to it !!!

This is breaking our CDN pipeline as we have to do manual intervention. It is really frustrating.

Please consider !!!

[ViktorHofer]

cc @ericstj

[ericstj]

Could you please clarify if some action you took added the bindingRedirect, or was it already present in your sources?

Removing the bindingRedirect is the correct thing to do.

The build will never touch web.config since it's a source file not an output. Perhaps it's Visual Studio / NuGet Package Manager added it when you installed? Another possibility is that you simply had the bindingRedirect present in web.config from an older version of the package (from before this was added to the framework). In either case removingit from web.config is the right thing to do. If NuGet package manager is adding it we can follow up to get that fixed.

package is part of the FRAMEWORK and should not be mentioned in Web.Config, so why Nuget Packages refer to it

Correct, but it wasn't always part of the framework, so some packages still reference it. Eventually everyone will update their packages to versions of .NETFramework that no loner require this package and we'll be past this.

[awbmansour]

Thank you for the quick response and clarifications.

Everytime I remove the assembly reference from web.config, then do a nuget package update, it reintroduces it back, specially when the update is related to one of the two packages Microsoft.Identity.Client or System.Formats.Asn1

Is it in your reach to encourage the owners of these two packages to update their dependencies and remove ValueTuple from it ? Please .. I have pasted this same issue under the two packages GitHub repo, but received No Reply yet from them. Only this forum is responsive !! Thank You.

[ericstj]

Are you using packages.config? You can update to PackageReference which does not allow any project changes on package installation.

[awbmansour]

We wre using package.config

Can't we fix the named Nuget Packages to remove the dependency on ValueTuple ? Instead of tryimg workarounds on each solution level ?

[ericstj]

I see -- yeah, packages.config has always had trouble with the inboxed packages, even without all the problems that System.ValueTuple has been through. The old logic in nuget v2 used for packages.config assumes that any assembly conflicts must be redirected. It doesn't consider RAR / framework information. We'd get the same problems for System.Net.Http, System.IO.Compression, etc. One way to avoid that is to set
https://learn.microsoft.com/en-us/nuget/reference/nuget-config-file#bindingredirects-section in your NuGet.config file.

Nuget computes these only considering the framework lists under ProgramFiles, by using ToolLocationHelper which is inconsistent with what the project resolves at build time. It doesn't appear that Nuget has any exclusion rules. We could ask NuGet to change the algorithm for comparison - to only compare Major.Minor - which would be consistent with the framework's loader behavior for framework assemblies. I'll open an issue in nuget. NuGet/Home#14853

Those packages do remove the dependency on System.ValueTuple in their targets for frameworks that don't require it - but we only target a single framework version for .NETFramework - the minimum supported which is 4.6.2. We could consider adding targets for net471 in dotnet/runtime. I have a few ideas will drop a link to a PR.

[riverar]

Still unclear why the ValueTuple package (4.6.2) references AssemblyName="System.ValueTuple" Version="4.0.5.0" which doesn't exist in netfx48. Are you potentially missing the root cause for the symptom?

#258 (comment)