Bee Errors after Unity.Collections introduced dependency to Mono.Cecil (Unable to resolve type-definitions of precompiled assemblies)

Unity Engine
, , , ,
1

UPDATE: I just reverted all to before upgrading to URP, then updated Burst separately, which doesn’t result in the errors below, we still don’t know what causes the compilation to fail once URP is used in the project, so if anyone has any idea to that please respond :slight_smile:

(Thread might be moved to URP / C# compilation / dunno ?)

Original Post:

Soo, we recently started out next project and thus upgraded unity and decided to finally make the switch from built-in render-pipeline to URP.
With that our Burst package got a forced update from 1.8.13 to 1.8.16 and since that, Unity / Bee spits out errors en mass which seem to be the same issue for multiple In-Project-Assemblies of ours, all referencing a pre-build managed-dll of ours that hadn’t any issue before.
It seems to boild down to generic-[interface/struct]-types being unable to be resolved.
Funny thing is we don’t use any “Job”-related stuff there nothing marked with [BurstCompile]

Do you have any hint to what’s going on here?

Processing assembly Library/Bee/artifacts/1900b0aEDbg.dag/CustomAssemblyInTheSameProject.dll, with 135 defines and 250 references
processors: Unity.Jobs.CodeGen.JobsILPostProcessor, zzzUnity.Burst.CodeGen.BurstILPostProcessor
running Unity.Jobs.CodeGen.JobsILPostProcessor
Unity.Jobs.CodeGen.JobsILPostProcessor: ILPostProcessor has thrown an exception: Mono.Cecil.ResolutionException: Failed to resolve [Insert: PrebuildManagedDll-Assembly].[Insert: SomeInterfaceType]
at Unity.Jobs.CodeGen.TypeReferenceExtensions.CheckedResolve(TypeReference typeReference)
at Unity.Jobs.CodeGen.JobsILPostProcessor.VisitJobStructInterfaces(TypeReference jobTypeRef, TypeDefinition jobType, TypeDefinition currentType, ILProcessor processor, MethodBody body)
at Unity.Jobs.CodeGen.JobsILPostProcessor.VisitJobStructs(TypeReference t, ILProcessor processor, MethodBody body)
at Unity.Jobs.CodeGen.JobsILPostProcessor.PostProcessImpl()
at Unity.Jobs.CodeGen.JobsILPostProcessor.Process(ICompiledAssembly compiledAssembly)
at Unity.ILPP.Runner.PostProcessingPipeline.PostProcessAssemblyAsync(PostProcessAssemblyRequest request, Action2 progressSink) PostProcessing failed: Mono.Cecil.ResolutionException: Failed to resolve [Insert: PrebuildManagedDll-Assembly].[Insert: SomeInterfaceType] at Unity.Jobs.CodeGen.TypeReferenceExtensions.CheckedResolve(TypeReference typeReference) at Unity.Jobs.CodeGen.JobsILPostProcessor.VisitJobStructInterfaces(TypeReference jobTypeRef, TypeDefinition jobType, TypeDefinition currentType, ILProcessor processor, MethodBody body) at Unity.Jobs.CodeGen.JobsILPostProcessor.VisitJobStructs(TypeReference t, ILProcessor processor, MethodBody body) at Unity.Jobs.CodeGen.JobsILPostProcessor.PostProcessImpl() at Unity.Jobs.CodeGen.JobsILPostProcessor.Process(ICompiledAssembly compiledAssembly) at Unity.ILPP.Runner.PostProcessingPipeline.PostProcessAssemblyAsync(PostProcessAssemblyRequest request, Action2 progressSink)
at Unity.ILPP.Runner.PostProcessingService.PostProcessAssembly(PostProcessAssemblyRequest request, IServerStreamWriter`1 responseStream, ServerCallContext context)
Unhandled Exception: System.InvalidOperationException: Post processing failed
at Unity.ILPP.Trigger.TriggerApp.d__1.MoveNext() + 0xf74
— End of stack trace from previous location —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at Unity.ILPP.Trigger.TriggerApp.d__1.MoveNext() + 0x1149
— End of stack trace from previous location —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb6
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x42
at Unity.ILPP.Trigger.TriggerApp.d__0.MoveNext() + 0xc7
— End of stack trace from previous location —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb6
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x42
at Program.<$>d__0.MoveNext() + 0x1a3
— End of stack trace from previous location —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb6
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task) + 0x42
at Program.(String) + 0x20
at Unity.ILPP.Trigger!+0x48d4fb

One of the ‘problematic’ interfaces is this one:

public interface ICharArrayFormattable
{
    // Array is a readonly ref struct in this case
    Array<char> ToCharArray();
}

The other problematic one:

public interface IInComparable<T>
{
    int CompareTo(in T other);
}
2

Update 2:

Okay so far we can tell that it really isn’t burst, but a dependency of Unity.Collections 1.4+ (which is enforced by the hidden Unity Light Transport Library) to Mono.Cecil.

Side-Note Unity-Collections of 1.4+ isn’t even proposed by the package manager without adding URP in 2023.2.20f1. Is this version incompatible?!

As soon as this is present the errors above appear. (also kinda directly mentioned in the error-log:
“Mono.Cecil.ResolutionException: Failed to resolve [Insert: PrebuildManagedDll-Assembly].[Insert: SomeInterfaceType]”
Now I debuged further as we’re doing some small IL weaving on the managed library before loading it in unity, but so far we can tell that this shouldn’t be the isse as all those unresolved interface types have nothing to do with that part of the code.

Now I also finally found an 8 year old post of the Mono.Cecil Author responding to exactly the error-message being printed above:

https://mono-cecil.narkive.com/MCZQ5jLk/how-to-fix-failed-to-resolve-assembly
According to him, this is a result of Mono.Cecil being unable to read the type definition from precompiled “other” assemblies unless they’re provided via a an Assembly-Resolver.
Sooo, can we as Unity-“Users” somehow manipulate the whatever is happening there during compilation and add those precompiled dll’s to a “resolve from here” list thingy? I honestly would assume that unity would read the .dll’s being present automagically and consider those when compiling the stuff?!

3

Sooo, after all we got the the project to stop throwing this errors. If anyone finds this thread through googling the ‘fix’ is pretty simple:

Unlike the ‘normal’ build-pipeline Mono.Cecil’s Assembly Discovery doesn’t resolve managed Assemblies referenced by other referenced Assembly Definition References, so if you have a setup like:

Asm A --references–> Asm B --references → Managed Asm (.dll) C

It no longer suffices to references C on B. You also need to reference C on A. Otherwise when Cecil is collecting referenced Types it is unable to resolve the Types of C while inspecting the reference B on A.
This sounds dumb? Well it kinda is, as the only thing to change that behaviour to the way it was with the ‘normal’ compilation process, should be pretty easy. Unity just would need to add the path(s) to the managed reference(s), which were referenced in the currently built assembly for the other referenced assembly, as additional SearchDirectories. As it was explained by the Mono.Cecil author in the link posted above.