Currently com.unity.collections is referencing System.Runtime.CompilerServices.Unsafe 4.3
System.Memory requires System.Runtime.CompilerServices.Unsafe (>= 4.5.0) so anything referencing that will cause an error that cannot be fixed.
Please move this out to a “nuget.xxx” package with updated versions.
Hi there,
I have forwarded this issue to the team in charge of the com.unity.collections. Thanks for the report.
Thanks @ethan_jl_unity .
Would it also be possible to get some info on how these situations will be handled in the future, with unity packaging dlls from nuget?
Sorry to ping you again, but is there an update on this? It’s blocking updates to our shared libraries.
+1
This would be greatly appreciated. We are having massive issues with the NumSharp library at the moment, which needs System.Runtime.CompilerServices.Unsafe (>= 4.5.2) and at the same time we need Unity.Collections which ships with 4.0.3.0
To circumvent my problem, I had to:
Copy the folders com.unity.collections, com.unity.jobs, com.unity.test-framework and com.unity.test-framework.performance from Library/PackageCache/
Paste them inside my Assets folder
Delete or Disable System.Runtime.CompilerServices.Unsafe.dll from the Assets/com.unity.collections/
Uninstall Unity.Collections and Unity.Jobs from the Package Manager
So far everything works, and both NumSharp and Collections use the 4.5.2 version of System.Runtime.CompilerServices.Unsafe
I am really sorry you’re still having issues. The issues have been forwarded to the relevant teams and I’ll follow-up on this. In the meantime, you can get unblocked in a less drastic manner by embedding the faulty packages - similar to the steps taken by @GeorgeAdamon , but under the Packages/ directory. This allows the package manager to still see these packages and install their dependencies, and you don’t need to remove them from the project manifest.
So updated steps would look like:
Copy only the folder com.unity.collections from Library/PackageCache/
Paste it under Packages (optionally rename it to com.unity.collections so it has the same name as in its package.json file)
Delete or Disable System.Runtime.CompilerServices.Unsafe.dll from the Packages/com.unity.collections/
Thanks for the tip @maximeb_unity and we are looking forward for this issue to be resolved!
Could I please get more detailed information on the locations of these folders? I have looked in my editor and project folders and cannot find them. I’m on 2019.2.3f1. Thank you.
Both Library/PackageCache/ and Packages referred to folders directly in your project directory. Say your Unity project is in C:\Users\me\Documents\Unity\MyProject, then C:\Users\me\Documents\Unity\MyProject\Library\PackageCache and C:\Users\me\Documents\Unity\MyProject\Packages are the directories I was referring to.
Thank you for the quick reply.
For my project I did not have com.unity.collections package.
I did solve my compile problems by downloading the latest nuget packages and then moving the following the netstandard2.0 dlls to my Plugins directory:
System.Buffers.4.5.0
System.Memory.4.5.3
System.Runtime.CompilerServices.Unsafe.4.6.0
Hopes this helps others.
Unity must resolve this through this repository, curiously created by a Unity employee:
It’s the only logical way to do it.
They already have some nuget packages replicated in their package manager, just not all they are using. Though I haven’t heard if this is their official way of dealing with the issue…
Yes but that package is not the official Nuget package, it is recompiled by Unity and when you want to use an official Nuget package that depends on another official Nuget package, it won’t work. Or if you need some specific version and not the one that Unity provides.
That’s exactly what the link you provided is doing, it converts a nuget package to an npm/unity package. Unity - for who knows what reasons - has decided on npm as their package technology and I don’t see that changing, so we just have to work within that framework.
To make it work they’re going to have to officially maintain a number of packages (nuget.xxx in the package manager), though I haven’t heard anything official about this.
@maximeb_unity Six months later and this is still a problem, and there have been a number of package updates since with no fix.
Also you stated you were going to follow up with the relevant teams, what was the result of that?
@xoofx as you’re the author of of UnityNuGet and work on burst this is probably relevant to you.
As I’ve been updating to 2019.3 I’ve noticed burst is now packing a whole bunch of nuget dlls. It even includes mono.cecil that is in the nuget.mono-cecil package?
I’m getting two warnings when I load up unity with burst 1.2.1 but it doesn’t seem to be affecting anything. If I try to remove the dlls burst breaks so I’m not sure how they relate to the unity editor, or what to do here.
warnings
Could not load assembly System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
UnityEngine.Debug:LogWarning(Object)
Unity.Burst.Editor.BurstReflection:CollectAssembly(Assembly, HashSet1) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:260) Unity.Burst.Editor.BurstReflection:CollectAssembly(Assembly, HashSet1) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:256)
Unity.Burst.Editor.BurstReflection:GetAssemblyList(AssembliesType) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:239)
Unity.Burst.Editor.BurstLoader:.cctor() (at Packages/com.unity.burst@1.2.1/Editor/BurstLoader.cs:69)
UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes(Type[ ])
Could not load assembly System.Buffers, Version=4.0.2.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51
UnityEngine.Debug:LogWarning(Object)
Unity.Burst.Editor.BurstReflection:CollectAssembly(Assembly, HashSet1) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:260) Unity.Burst.Editor.BurstReflection:CollectAssembly(Assembly, HashSet1) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:256)
Unity.Burst.Editor.BurstReflection:CollectAssembly(Assembly, HashSet`1) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:256)
Unity.Burst.Editor.BurstReflection:GetAssemblyList(AssembliesType) (at Packages/com.unity.burst@1.2.1/Editor/BurstReflection.cs:239)
Unity.Burst.Editor.BurstLoader:.cctor() (at Packages/com.unity.burst@1.2.1/Editor/BurstLoader.cs:69)
UnityEditor.EditorAssemblies:ProcessInitializeOnLoadAttributes(Type[ ])
These DLLs are in a special folder .Runtime that is not supposed to be processed by Unity editor at all, they are not part of the user Editor AppDomain, so they can’t be found by BurstReflection.
I suspect that the issue you are seeing is likely coming from another package you are using that is actually using these DLLs. We should probably remove these warning in Burst because I’m not sure they are relevant when things can’t be loaded (because that’s likely not a code that will be bursted in the end)
Not only has this behaviour not been fixed with the update of DOTS; things have gotten way worse.
Previously, the answer provided by maximeb_unity helped.
Now, updating DOTS, numerous CS0246 errors pop up (Namespace of individual packages couldn’t be found, even between each other). When trying to import DOTS to a brand new HDRP project, with the second or third package already, infinite import loops occur (all dependencies shown in package manager installed IN “CORRECT” ORDER) - am I missing something? Am I the only one who observes this? How do I fix it? And most importantly: When won’t we have to deal with this anymore?
@Mortuus17 there was a versioning problem recently, I think you need to manually update burst? Something like that. I don’t think preview packages are shown as updates normally so you will have to turn them on or manually check available versions