Bug 2021.2.0b6 and System.Memory/ReadOnlySpan under .NET 4.8

Searcher v4.8 seems to include System.Memory/CompilerServices/Buffers.

Not hard to manually remove them though.

 

Yeah, this was what I posted earlier. Searcher has the dll and that is what I posted. And I thought the fix mentioned was for that. Hopefully it is addressed soon. Will it be in form of updating Searcher from the package manager?

 

Mmmm System.Collections.Immutable depends on System.Memory and there is no version targeting standard 2.1 (only standard 2.0 / framework 4.6 with dependency or net6 without).
While we can disable validation checks and that makes it work in the editor, trying to build the project fails (either classic build or new scripted / asset config based system).
Yes, I have disabled the "validate references" at project level settings (not just individual dlls) but it still fails to build reporting an incorrect (since code works in the editor) missing reference error.

Reported it as Case 1364682.

 

Google.Protobuf suffers from the same problem and cannot be loaded because it's missing System.Memory. There's no netstandard2.1 option available, and it would be rather bizarre to use one when targeting 4.8. Yes, I know that Unity's 4.8 is a bit more than 4.8, but that's something which is not obvious for people that haven't followed this thread.

In fact, I've made a simple, stupid dll that references System.Memory 4.5.4, and just contains some references to it in a class. 2021.2.0b11.3437 does not load this dll, because it's missing System.Memory - so the bug is still apparent for third party assemblies.

I can turn off reference validating, but then the project just dies again when running it, because it can't find System.Memory (FileNotFoundException System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51).

I've opened a ticket for that (1364865) with an example csproj/dll. For me, this issue is still not resolved because it still seems to break all third party assemblies referencing System.Memory.

 

@Baawk Fortunately, Google.Protobuf source code is available on github and you can build it as .NET Standard 2.1.

 

With normal .NET applications it is not a problem to use .NET Standard 2.0 libraries with dependency on System.Memory, there the System.Memory assambly of the final framework is used (in my test it was .NET5). And the NuGet version "ignored".

 

Except it is still not working in Unity. Editor throws error importing dlls that can be ignored by disabling "Validate References" and it does actually work in editor but it won't let u build your game anymore :S

 

Both of these answers ignore the fact that any pre-built assembly referencing System.Memory, ever, is not going to be compatible with Unity 2021.2, when they were perfectly compatible with 2021.1 and a self-supplied System.Memory.dll. I'm also not sure if it's a good idea to build stuff against netstandard2.1 when you want to run it on .NET 4.8, even with Unity's slightly expanded framework support.

Because .NET 4.8 does not have System.Memory as a framework library, it has to be loaded in - as a NuGet, or just as a normal assembly (likely from NuGet) - for the application. So if you're using a netstandard2.0 library in a .NET 4.8 application, you have to supply the System.Memory.dll yourself to get it to work. This is not the case with netstandard2.1 (because System.Memory technically no longer exists/is a part of the framework itself) nor some version of .NET Core or newer.

Here, we have the problem that Unity is technically running 4.8, does not offer a type redirect for libraries that are looking for System.Memory.dll, and therefore basically cripples all libraries that directly (or indirectly) depend on a type in System.Memory. It doesn't matter that ReadOnlySpan and friends technically exist, the runtime can't find them because they're in a different assembly.

A possible fix would be for Unity to just supply a System.Memory.dll that fits the bindings, but redirects them to the mscorlib. Or, for better or worse, revert the 4.8 profile to be a proper 4.8 profile, without framework extensions.

 

Mono has already a type forwarder for System.Memory.
The problem may be due to the strong-name validation of the assemblies, which .NET core /.NET5+ no longer does.
Maybe Unity should deactivate the global, because it won't play a role in the future anyway.

 

Microsoft.CodeAnalysis.CSharp no longer works in Unity 2021.2b (also Unity's code-analysis package does not work too https://docs.unity3d.com/Packages/com.unity.code-analysis@0.1/manual/index.html). This is very disappointing.

 

Any ETA on this? Can't use any current 2021.2 beta or 2022.1 alpha because of this...

 

Oh the "Searcher" package update to be specific.

 

We, too, cannot test 2021.1b due to the searcher Memory dll dependency.

 

As a workaround for the searcher bug, find the package manager cache in your user folder (AppData in windows) and delete the System.Memory.dll and meta files from the Searcher "Lucene" folder.
After deleting the cache, delete the copy from your project packages folder (just the dll) and it should work again. (Well, u wont be able to build your game, but editor and play mode work fine)

Oh, u might need to disable dll reference validation at project level. I don't remember if it was necessary or not.

 

Btw, any update regarding:
(Case 1364682) Project fails to build due to an incorrect missing System.Memory error even with validate references disabled at project level

Its been several days since I reported it and still no feedback from QA teams.

 

I misconfigured my project and after fixing it, code-analysis packages works in Editor. But it prints many "Failed to load types in assembly XXX" warnings. I sent it as Case 1367233.

 

If you need a good test case for netstandard2.1 compatibility, try the managed GRPC library.
- It supports netstandard2.1 and netstandard2.0 https://github.com/grpc/grpc-dotnet/pull/1118
- The implementation depends on having a working http/2 client, which only netstandard2.1 does
- Unity *should* use the netstandard2.1 http/2 client stuff correctly

 

Is this resolved yet?

 

Thanks for the update! I think we can expect b15 end of week? Not sure what the beta release cadence is.

 

Any update on this? I have b15 and Protobuf-net V3.0.101 still complaint about System.Memory

 

That should only be a problem if there is a custom System.Memory in the project/package.
Protobuf-net has a Standard 2.1 version, do you use that?

 

As far as I can tell, this seems to be fixed for good with 2021.2b16. I was able to load my third-party assemblies that rely on System.Memory and haven't noticed anything strange yet.

 

I have this same issue with MessagePack-CSharp, a popular library for MessagePack encoding/decoding in Unity. (It's serves a similar purpose to the the Protobuf library mentioned above)

The package seems to reference System.Memory and I get hundreds of:

Code (csharp):

1.  error CS0433: The type 'ReadOnlySpan<T>' exists in both 'System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
2.  

Any ideas on how to fix this? It makes my project unusable under Unity 2021.2.

 

Search for System.Memory.dll in the assets and delete it.

 

Thanks! That worked.

 

Unity could issue a warning here if dlls are found that are now part of .NET Standard 2.1

 

Thank!!!

 

It looks like this error still happens if you put a script that uses ReadOnlySpan in the Standard Assets folder so it ends up in the Assembly-CSharp-firstpass project.

Unity still runs fine, but if I try to "Attach to Unity" in VS to debug I get this error:

Code (CSharp):

1. Error CS0433 The type 'ReadOnlySpan<T>' exists in both 'System.Memory, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'    Assembly-CSharp-firstpass    C:\code\KingdomOfNight\Assets\Standard Assets\ExcelLibrary\Office\Excel\BinaryFileFormat\Decode\ByteStringDecoder.cs

The error goes away if I move this file out of the Standard Assets folder, but I want it there to speed up the compile process.

 

If you place scripts in a folder called "Standard Assets" they get complied to a separate project called Assembly-CSharp-firstpass
This project doesn't need to get recompiled every time you change other regular scripts so it makes development faster. It's better than using asmdef files because it also respects the "editor" folder convention.

 

I move the file to the root of the Assets folder. It then compiles in the main assembly and works fine.

 

I'm not sure what you're saying. The file I'm taking about is a custom script I wrote that uses System.ReadOnlySpan<T>. Obviously if I delete the script the error will go away, but I need the script.

All I'm saying is that if you have a script that uses ReadOnlySpan and you place it in the special "Standard Assets" folder. The error this thread has been talking about comes back.

The game runs fine in the editor, but if I try to debug in visual studio I get the error.

Code (CSharp):

1. Error CS0433 The type 'ReadOnlySpan<T>' exists in both 'System.Memory, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' and 'mscorlib, Version=4.0.0.0, Culture=neutralAssembly-CSharp-firstpass    C:\code\KingdomOfNight\Assets\Standard Assets\ByteArrayReader.cs

Clearly it's been fixed for regular scripts, the issue is that it's still broken for scripts in the "Assets/Standard Assets" special folder.