Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  3. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

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

Discussion in '2021.2 Beta' started by Baawk, Aug 5, 2021.

  1. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    228
    Searcher v4.8 seems to include System.Memory/CompilerServices/Buffers.

    Not hard to manually remove them though.
     
  2. vladimirn

    vladimirn

    Unity Technologies

    Joined:
    May 16, 2018
    Posts:
    5
  3. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,518
    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?
     
  4. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    228
    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.
     
  5. Baawk

    Baawk

    Joined:
    Nov 15, 2017
    Posts:
    20
    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.
     
  6. Kichang-Kim

    Kichang-Kim

    Joined:
    Oct 19, 2010
    Posts:
    1,021
    @Baawk Fortunately, Google.Protobuf source code is available on github and you can build it as .NET Standard 2.1.
     
  7. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    803
    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".
     
  8. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    228
    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
     
  9. vladimirn

    vladimirn

    Unity Technologies

    Joined:
    May 16, 2018
    Posts:
    5
    This version of the searcher package was previously not causing problem as nothing basically depended on it, the recent release had an internal package depend on searcher 4.8.0. We are looking to publish a new version of the searcher package AND update the internal package to depend on that new version.

    What this means is that unless you used third party code that specifically depends on searcher 4.8.0 (pretty unlikely), you shouldn't have anything to do as soon as we publish the aforementioned fix.
     
  10. Baawk

    Baawk

    Joined:
    Nov 15, 2017
    Posts:
    20
    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.
     
    aromana likes this.
  11. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    803
    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.
     
  12. Kichang-Kim

    Kichang-Kim

    Joined:
    Oct 19, 2010
    Posts:
    1,021
  13. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,518
    Any ETA on this? Can't use any current 2021.2 beta or 2022.1 alpha because of this...
     
  14. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
    Can you be more specific about which issue you are looking for the fix for? I think there have been a few in this thread.
     
  16. castor76

    castor76

    Joined:
    Dec 5, 2011
    Posts:
    2,518
    Oh the "Searcher" package update to be specific.
     
  17. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
    Thanks! I'm not sure about that status of that one. Maybe @vladimirn can provide an update though.
     
  18. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    383
    We, too, cannot test 2021.1b due to the searcher Memory dll dependency.
     
    Last edited: Sep 20, 2021
  19. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    228
    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.
     
  20. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    228
    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.
     
  21. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,136
    The fixes are currently being reviewed. In the best case, they could land in 2021.2.0b14 and 2022.1.0a10.
     
    Ollhax, vladimirn and strich like this.
  22. Kichang-Kim

    Kichang-Kim

    Joined:
    Oct 19, 2010
    Posts:
    1,021
    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.
     
    LeonhardP likes this.
  23. doctorpangloss

    doctorpangloss

    Joined:
    Feb 20, 2013
    Posts:
    270
    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
     
  24. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    383
    Is this resolved yet?
     
  25. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,136
    strich likes this.
  26. strich

    strich

    Joined:
    Aug 14, 2012
    Posts:
    383
    Thanks for the update! I think we can expect b15 end of week? Not sure what the beta release cadence is.
     
  27. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,136
    Yes, the build is currently going through internal testing. Unless bigger issues are found, the plan is to release it later this week.
     
    Timboc, castor76, JesOb and 1 other person like this.
  28. Morphus74

    Morphus74

    Joined:
    Jun 12, 2018
    Posts:
    174
    Any update on this? I have b15 and Protobuf-net V3.0.101 still complaint about System.Memory
     
  29. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    803
    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?
     
  30. Baawk

    Baawk

    Joined:
    Nov 15, 2017
    Posts:
    20
    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.
     
  31. aromana

    aromana

    Joined:
    Nov 11, 2018
    Posts:
    137
    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.
     
    ProGameDevUser likes this.
  32. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    803
    Search for System.Memory.dll in the assets and delete it.
     
    ProGameDevUser likes this.
  33. aromana

    aromana

    Joined:
    Nov 11, 2018
    Posts:
    137
    Thanks! That worked.
     
    ProGameDevUser likes this.
  34. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    803
    Unity could issue a warning here if dlls are found that are now part of .NET Standard 2.1
     
    LeonhardP likes this.
  35. LeonhardP

    LeonhardP

    Unity Technologies

    Joined:
    Jul 4, 2016
    Posts:
    3,136
    Thanks for helping out here @runner78! I've passed the suggestion on to the team. For the time being, the topic is covered in the 2021.2 upgrade guide:
     
  36. ProGameDevUser

    ProGameDevUser

    Joined:
    Mar 17, 2018
    Posts:
    115
    Thank!!!:)
     
  37. Scott-Steffes

    Scott-Steffes

    Joined:
    Dec 31, 2013
    Posts:
    59
    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.
     
  38. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
    Why does having this file in the Assets folder speed up the compilation process? I don't expect it to impact C# compilation performance at all, but I don't think I understand the situation fully.
     
  39. Scott-Steffes

    Scott-Steffes

    Joined:
    Dec 31, 2013
    Posts:
    59
    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.
     
  40. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
    Thanks for clarifying. I do still have a question about this statement:

    Do you move the file to the Assets folder? Or do you delete it completely from the project?
     
  41. Scott-Steffes

    Scott-Steffes

    Joined:
    Dec 31, 2013
    Posts:
    59
    I move the file to the root of the Assets folder. It then compiles in the main assembly and works fine.
     
  42. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
    What happens if you remove the file completely from the project? It should not be required, as Unity now ships with this code in the .NET base class library.
     
  43. Scott-Steffes

    Scott-Steffes

    Joined:
    Dec 31, 2013
    Posts:
    59
    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.
     
  44. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,938
    Oh, I'm sorry! All along I thought this was a managed assembly that implemented ReadOnlySpan<T>, not a script that uses it. I apologize for the confusion!

    This sounds like a bug then, I don't think that the location of this C# file should have this impact. Can you submit a bug report for this if you have not already?