Unity.Collections exception

Good day.

Is there any way to resolve an issue with the dublication of System.Runtime.CompilerServices.Unsafe.dll
I wish to use another version of it but I can't because it conflicts with the built in version in Unity.Collections package. When I drop another version of 4.5.0 unsafe library it throws the exception. I have another library that has dependency on the 4.5.0 unsafe library not the Unity.Collections one. So there should be a feature to remove the library that in the the package.

Library\PackageCache\com.unity.collections@0.0.9-preview.10\Unity.Collections\UnsafeUtilityEx.cs(13,24): error CS0433: The type 'Unsafe' exists in both 'System.Runtime.CompilerServices.Unsafe, Version=4.0.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Thank you.

@Joachim_Ante_1

Temporary fixed by deleting the dll from the Library/PackageCache folder.

1 Like

Try using Override References button on your .asmdef and manually choose the right .dll for your assembly

I don't have any .asmdef in my project. And adding one and setting to override doesn't work too.

[quote]
I don't have any .asmdef in my project. And adding one and setting to override doesn't work too.
[/quote]

What happens if you turn off auto including on the .dll? and auto referencing? [After also including it in the override of the asmdef]

1 Like

[quote=“tertle”, post:6, topic: 724698]
What happens if you turn off auto including on the .dll? and auto referencing? [After also including it in the override of the asmdef]
[/quote]

Have multiple errors and everything is broken.

You can try yourself from Nuget package https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe/4.5.2

I already did and it worked fine - got rid of the error. Hence my suggestion.

However I did not have any libraries referencing it or attempt a build so I couldn't confirm it'd work.

Solved by disabling auto reference, auto including and creating an asmdef file with overriding a new dll.
However still requires old .dll to be removed in order to properly create asmdef.

1 Like

Resuming this as I have the same problem. I can't manage to tell to my asmdef to use the Unsafe.dll I want to use (together with buffers.dll and memory.dll) without clashing with other dlls

PrecompiledAssemblyException: Multiple precompiled assemblies with the same name System.Runtime.CompilerServices.Unsafe.dll included for the current platform. Only one assembly with the same name is allowed per platform.

Edit: it seems that the dll auto reference option must be disabled too, but it doesn't help, even if I do so, it still conflicts with the existing dlls

It conflicts because the collections package is pulling in it's version. The simplest solution with the least impact on your project is just copy the version you want over what Unity provides. Assembly definitions cannot solve this problem.

It's also solvable with aliases. That's really what packages should be doing IMO.

1 Like

I wonder if a solution can be to ask the editor to ignore the dll and then load it at run time, with a different alias

edit: there are several possible solutions here: https://michaelscodingspot.com/how-to-resolve-net-reference-and-nuget-package-version-conflicts/ but I can see just one that may work with unity

OK solved with asmdefs only, please check these configs:

5291079--531012--upload_2019-12-17_12-58-50.png

5291079--531015--upload_2019-12-17_13-2-12.png

note everything is unchecked with the select platform for plugins. If there weren't the Unsafe dll from the other packages, it wouldn't have worked, however this is the only way I found to make the buffer and memory dlls work when other packages include unsafe. dll. Deleting the unsafe.dll will end up in a signature failure exception at run time (buffer and memory won't find the dll). I have no much clue about what's really going on, so consider this a work around.

2 Likes

Just to let some steam off: I hate this so much and it has cost me already so many hours since the day asmdef have been released and today I just once more horribly ran into it with a version incompability between an auto referenced System.Runtime.CompilerServices.Unsafe.dll between Collections and MessagePack (4.5.0 vs 4.5.1).

Why the hell does a package, where I do not have control over it, add dlls and mark them as auto referenced in the first place. Why don't I get control over it? Why is the whole asmdef thing still so incredibly unstable after all that time that unity fails to compile and crash hard to desktop because of that cycle and then falls back to the old default csproj folder based structure, although it should clearly know that it should expect .asmdef based project files as it HAD JUST FAILED COMPILING THEM which once more causes a compiler error because obviously those csproj obviously are not set up correctly regarding their dependencies, as how in the world could they even be... Why does unity even dare to override my manually and careful setup .asmdef file such that I have to revert the file via vcs because it fails to resolve that cycle? If you do that for the auto generated old way to structure projects, fine, but for project and dependency definition files where you expect me to set them up: do not overwrite them...

Sorry. I know, this is just a rant and not super constructive, but I just once more are spending hours to fix some minor version upgrade of a package that by no means should interfere with anything from a unity package...
Edit: Okay, now I feel better :) Hope everyone else here had a better day than I did.

Edit 2: [mention|YVIBsEH6MKHMot88lGvETg==] by the way. While this is a workaround it also means you will not have this particular dll in your build and referenced but the version from the package cache. This could cause a version discrepancy and nasty bugs which you only notice once the dll is loaded during Runtime. However - thanks for the idea, I will also do that for now and hope nothing breaks horribly soon.

1 Like

[quote=“MNNoxMortem”, post:15, topic: 724698]
Why the hell does a package, where I do not have control over it, add dlls and mark them as auto referenced in the first place. Why don’t I get control over it?
[/quote]

Same, here in 2021

EDIT: based on this thread I need a certain version of Unity Collections package, 0.15.0-preview.21 is latest version that I am able to work with using Unity 2020 LTS and latest Burst.

https://github.com/neuecc/MessagePack-CSharp/issues/716

Just a note for someone else looking for a solution to this problem without asmdef; I'm sure this won't work with all this kind of conflicts, but it worked for us:
Pulse Physiology Engine's "System.Runtime.CompilerServices.Unsafe.dll" conflicted with unity collection package's same file - using Unity 2019.4.15f1.
1. (In file explorer)Cut and paste the whole "com.unity.collections-xxx" folder from "projectfolder-Library-PackageCache" to the "projectfolder-Packages" folder(the one with manifest.json).
2.Rename the "com.unity.collections-xxx" folder, now in Packages, to "com.unity.collections".
3.Copy and paste the duplicate "--Unsafe.dll" from the conflicting asset to the renamed com.unity.collections folder.
Now you should have two copies of the same .dll in your project, in the asset's folder and in the packages folder.
4.In unity, select the .dll in the asset's folder and check the "any platform" toggle on and exclude all the platforms below it. Then select the .dll in the Packages and toggle on "any platform" but don't exclude any on this one.

That got rid of the error and the asset and project seems to work by a quick test. No idea if this is a good idea in the long run...

1 Like