System.Memory 4.6.0 release issue with NET48

[NXTwoThou]

I still have to maintain a bunch of ASP.NET webform projects. The solutions are a mix of .NET 9(winform/console) and .NET 4.8(asp.net webform and winform). Yesterday a lot of NuGet updates became available.

Microsoft.Bcl.AsyncIntefaces 9.0.0
System.Buffers 4.6.0
System.IO.Pipelines 9.0.0
System.Numerics.Vectors 4.6.0
System.Runtime.CompilerServices.Unsafe 6.1.0
System.Text.Encodings.Web 9.0.0
System.Text.Json 9.0.0
System.Threading.Tasks.Extensions 4.6.0

and

System.Memory 4.6.0

All of the .NET 9 apps run perfectly. The ASP.NET webform sites get errors trying to use System.Text.Json functions gives the following error:

FileLoadException: Could not load file or assembly 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]

If I revert to System.Memory 4.5.5, everything works fine. Reverting System.Text.Json to 8.0.0.5 gives the same error. Reverting everything but System.Memory back to the versions before still gives the same error. The only way to not error out is putting System.Memory back to 4.5.5.

I use BindingGenerator to build my assemblyBinding for my web.config

For System.Memory 4.6.0 it gives

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

For System.Memory 4.5.5 it gives

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

I recognize that .NET Framework bindings are kind of held together with duct tape. But this is the first time I've really run into an issue that bindingRedirect hasn't resolved.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

[julealgon]

If you are seeing an error for 4.0.1.2, it seems to me that you still have that old DLL lying around in the bin folder when the project runs. Can you try deleting your bin/obj folders, closing Visual Studio, deleting the .vs solution cache folder and rebuilding again with the latest version of the package?

Also triple check that you don't have the old reference in other dependent projects by upgrading the package in the entire solution to the same version.

[NXTwoThou]

If you are seeing an error for 4.0.1.2, it seems to me that you still have that old DLL lying around in the bin folder when the project runs. Can you try deleting your bin/obj folders, closing Visual Studio, deleting the .vs solution cache folder and rebuilding again with the latest version of the package?

Also triple check that you don't have the old reference in other dependent projects by upgrading the package in the entire solution to the same version.

That was part of my attempt to get things working last night. I completely cleaned out my bin folder. Made sure there were no other dlls in the website folder. Removed .vs. Did Update-Package –reinstall for each of the packages. I'd run into something similar about 10 years back where I learned about .vs not always playing nice on VS updates so it's part of my toolset. Sorry I didn't mention in my original post.

[julealgon]

My next suggestion would be to double check all references to System.Memory in the project.assets.json file in the obj folder of your webforms project. That might give you a hint regarding where each version is coming from (if there is more than one source).

[NXTwoThou]

@julealgon There is no project.assets.json nor obj folder in my ASP.NET 4.8 Web Site project.

As a FYI, here's my packages.config so you know what it's using. Things only die when I switch System.Memory to 4.6.0 from 4.5.5.

[julealgon]

@julealgon There is no project.assets.json nor obj folder in my ASP.NET 4.8 Web Site project.

I thought you meant you were having problems with a WebForms project, not a Web Site? Can you confirm?

Regarding the lack of the folder, I forgot that's probably only generated when using SDK-style csproj which I assume you are not using on this particular project... I'm using this for a while now and forgot some things only apply there.

Are you still using packages.config-driven NuGets for these projects? If so, I would recommend trying to convert to using <PackageReference elements instead. They still work on old-style csproj and should be more robust than raw file-based <Reference.

If you already use those, then I'm out of suggestions for now and would probably ask for a small repro if you could create that.

[NXTwoThou]

@julealgon There is no project.assets.json nor obj folder in my ASP.NET 4.8 Web Site project.

I thought you meant you were having problems with a WebForms project, not a Web Site? Can you confirm?

Regarding the lack of the folder, I forgot that's probably only generated when using SDK-style csproj which I assume you are not using on this particular project... I'm using this for a while now and forgot some things only apply there.

Are you still using packages.config-driven NuGets for these projects? If so, I would recommend trying to convert to using <PackageReference elements instead. They still work on old-style csproj and should be more robust than raw file-based <Reference.

If you already use those, then I'm out of suggestions for now and would probably ask for a small repro if you could create that.

@julealgon ASP.NET 4.8 WebForms(aspx/asmx) as "Web Site" in my solution. There is no .csproj for this type, thus, no ability to switch to PackageReference.

This is how it appears in the .sln:

Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = "WinVoice", "WinVoice", "{961A922C-59F6-465C-BC2C-825FDE57A2CC}"
ProjectSection(WebsiteProperties) = preProject
TargetFrameworkMoniker = ".NETFramework,Version%3Dv4.8"
Debug.AspNetCompiler.VirtualPath = "/WinVoice"
Debug.AspNetCompiler.PhysicalPath = "WinVoice"
Debug.AspNetCompiler.TargetPath = "PrecompiledWeb\WinVoice"
Debug.AspNetCompiler.Updateable = "false"
Debug.AspNetCompiler.ForceOverwrite = "true"
Debug.AspNetCompiler.FixedNames = "false"
Debug.AspNetCompiler.Debug = "True"
Release.AspNetCompiler.VirtualPath = "/WinVoice"
Release.AspNetCompiler.PhysicalPath = "WinVoice"
Release.AspNetCompiler.TargetPath = "PrecompiledWeb\WinVoice"
Release.AspNetCompiler.Updateable = "false"
Release.AspNetCompiler.ForceOverwrite = "true"
Release.AspNetCompiler.FixedNames = "false"
Release.AspNetCompiler.Debug = "False"
VWDPort = "59201"
SlnRelativePath = "WinVoice"
EndProjectSection
EndProject

[julealgon]

Oh interesting @NXTwoThou ... I see now. Sorry I don't have any other suggestions (other than potentially suggesting a conversion from WebSite to a WebApplication project, although that might be a larger effort for you).

[NXTwoThou]

@julealgon Thanks for the help. Everything is stable right now with 4.5.5 and everything else up to latest versions. If I get a pausing point in this project that got slammed on my desk at the end of the day yesterday, I'll see what I can do about creating a minimal repo.

Meanwhile I'll just watch to see if anyone else has a similar issue and if there's an update to System.Memory I'll test to see if it has the same issue. It's just a NuGet update, edit the web.config bindingRedirect, launch the site, log in, and about 3 clicks in can trigger it. I did it a -lot- last night trying different versions of the other 8 packages that got updated this week.

[huoyaoyuan]

I use BindingGenerator to build my assemblyBinding for my web.config

AutoGenerateBindingRedirects should be available for WebForms project. Does it make any difference?

[rozeboosje]

Same problem here, folks. When I add a binding redirect for System.Memory to 4.0.2.0 it "goes away" but then the same issue arises for System.Buffers

Any suggestion what to redirect that to?

[MagicAndre1981]

AutoGenerateBindingRedirects generates this entry in the exe.config for my 4.8 Winforms application:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
   <dependentAssembly>
     <assemblyIdentity name="System.Memory" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
     <bindingRedirect oldVersion="0.0.0.0-4.0.2.0" newVersion="4.0.2.0" />
   </dependentAssembly>
 </assemblyBinding>

and my .net Winforms 4.8 app works.

Btw, those old libs have a new home at https://github.com/dotnet/maintenance-packages and this issue should be transfered to the new location.

[MagicAndre1981]

@rozeboosje also add the entry <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to a PropertyGroup in your csproj

[NXTwoThou]

I use BindingGenerator to build my assemblyBinding for my web.config

AutoGenerateBindingRedirects should be available for WebForms project. Does it make any difference?

Nope, not available. ASP.NET web site in solution explorer. No .csproj, just a path to a folder, which is why it uses packages.config and can't take advantage of autobinding.

[rozeboosje]

Thanks folks.... BindingGenerator appears to be a lifesaver here

[jeffhandley]

Assigned to @tannergooding to review this and determine if further triage is needed.

[ilCosmico]

I encountered the same issue while updating from System.Memory 4.5.5 to 4.6.0.

In my case:

• I have both a WinForms project and a UnitTesting project in the same solution.
• Both projects target .NET Framework 4.7.2.
• The WinForms project updated successfully without any issues.
• However, the UnitTesting project fails with the same FileLoadException described in this issue.

I have already ensured that both projects have the correct app.config with binding redirects.
Yet, the UnitTesting project still fails to load System.Memory 4.6.0 properly.

Has anyone found a workaround for this scenario? Could this be related to how NUnit/MSTest handles dependencies?
Thanks!

[Matthias-Heinz]

We're using System.Collections.Immutable in a .NET Framework 4.8 Website project and got the same issue in form of a "Transitive" (not yet marked as such in .NET Framework, but you'll get the gist) dependency for System.Memory

> dotnet nuget why MyProject System.Memory

├ System.Collections.Immutable (v9.0.2)
│ └─ System.Memory (v4.5.5)
...

Adding System.Memory as a Top-Level dependency using version 4.6.0 doesn't change the exception. I'm kind of at a loss here...

Any estimate on a fix for this issue?

[Matthias-Heinz]

After fiddeling with this for hours on end in the last couple of days and just a bit more of it right after my previous post, I've discovered, that using System.Collections.Immutable (v9.0.0) instead of version 9.0.2 in the .NET Framework associated projects resolves the issue.

System.Memory and System.Buffers both can be set to their latest version of 4.6.0 each. No clue, what that's about specifically, but might be worth investigating as well!

[tannergooding]

CC. @ericstj, this is an issue that looks related to binding redirects and other package complexities that you're much more knowledgeable around. Is this something that you or someone on your team can assist with?

[ericstj]

The original post mentioned

The ASP.NET webform sites get errors trying to use System.Text.Json functions gives the following error:

FileLoadException: Could not load file or assembly 'System.Memory, Version=4.0.1.2, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)]

This error cannot occur if the bindingRedirect is present. Take note that ASP.NET web forms are special in that they require modifications to the source web.config. Make sure you've updated your source web.config with:

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

If anyone has a repro project they'd like to share we can have a look and help point out what's going wrong. Most likely your project isn't set up to autogenerate bindingRedirects.

As @NXTwoThou mentioned -- bindingRedirects are an important part of making packages references work on .NETFramework and getting them right is essential to being able to upgrade packages successfully -- especially these low level packages which are referenced by many others.

[ericstj]

Has anyone found a workaround for this scenario? Could this be related to how NUnit/MSTest handles dependencies?

Unit test frameworks need to honor the test assemblies .dll.config. Make sure your test assembly is producing a .dll.config with the correct bindingRedirects and make sure your unit test framework reads this. Some frameworks have had support for years whereas others are more recent.

xunit has support https://github.com/xunit/xunit/blob/72878584ab032c9d7cd02a3387de36e1b3233938/src/xunit.v3.runner.utility/AppDomain/AppDomainManager_AppDomain.cs#L167
nUnit has support nunit/nunit-console#418
VStest has support microsoft/vstest#428

[ericstj]

I haven't heard back if folks are still facing issues here. I'll go ahead and close this - if anyone has tried the above and still facing issues either reopen this issue, or open a new issue with a repro attached. Thank you.