Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.Memory 4.6.0 release issue with NET48 #109827

Open
NXTwoThou opened this issue Nov 14, 2024 · 10 comments
Open

System.Memory 4.6.0 release issue with NET48 #109827

NXTwoThou opened this issue Nov 14, 2024 · 10 comments
Labels
area-System.Memory untriaged New issue has not been triaged by the area owner

Comments

@NXTwoThou
Copy link

NXTwoThou commented Nov 14, 2024

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 dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Nov 14, 2024
Copy link
Contributor

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

@julealgon
Copy link

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
Copy link
Author

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
Copy link

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
Copy link
Author

NXTwoThou commented Nov 14, 2024

@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
Copy link

@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
Copy link
Author

@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
Copy link

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
Copy link
Author

NXTwoThou commented Nov 14, 2024

@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
Copy link
Member

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Memory untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

3 participants