Started with 2019.2: Unity consistently tries to update assembly on DLL

Once I upgraded to 2019.2 unity tries to update my project's DLL every time I build it. There are no messages as to why it tries to update it, and the DLL has no warnings or errors. I could not find any notes in the build logs as to what changed that would cause this





Unable to update following assemblies:Assets/Mod/Engine/DLL/ModV1.dll (Name = ModV1, Error = 131) (Output: C:\Users\KEVINJ~1\AppData\Local\Temp\tmp79643fe7.tmp)

System.NullReferenceException: Object reference not set to an instance of an object.
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR (System.Int32 errorCode) [0x0000a] in <a8ed250850854b439cedc18931a314fe>:0
at (wrapper cominterop) Mono.Cecil.Pdb.ISymUnmanagedWriter2.CloseMethod()
at (wrapper cominterop-invoke) Mono.Cecil.Pdb.ISymUnmanagedWriter2.CloseMethod()
at Mono.Cecil.Pdb.SymWriter.CloseMethod () [0x00000] in <b769d8a00e8245f489ba57d016607fc9>:0
at Mono.Cecil.Pdb.NativePdbWriter.Write (Mono.Cecil.Cil.MethodDebugInformation info) [0x00081] in <b769d8a00e8245f489ba57d016607fc9>:0
at Mono.Cecil.Cil.CodeWriter.WriteResolvedMethodBody (Mono.Cecil.MethodDefinition method) [0x000f1] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.Cil.CodeWriter.WriteMethodBody (Mono.Cecil.MethodDefinition method) [0x0002b] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.AddMethod (Mono.Cecil.MethodDefinition method) [0x00013] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.AddMethods (Mono.Cecil.TypeDefinition type) [0x00013] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.AddType (Mono.Cecil.TypeDefinition type) [0x000a2] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.AddTypes () [0x00018] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.BuildTypes () [0x00014] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.BuildModule () [0x0009f] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.MetadataBuilder.BuildMetadata () [0x00000] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.ModuleWriter+<>c.<BuildMetadata>b__2_0 (Mono.Cecil.MetadataBuilder builder, Mono.Cecil.MetadataReader _) [0x00000] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.ModuleDefinition.Read[TItem,TRet] (TItem item, System.Func`3[T1,T2,TResult] read) [0x00029] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.ModuleWriter.BuildMetadata (Mono.Cecil.ModuleDefinition module, Mono.Cecil.MetadataBuilder metadata) [0x0000f] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.ModuleWriter.Write (Mono.Cecil.ModuleDefinition module, Mono.Disposable`1[T] stream, Mono.Cecil.WriterParameters parameters) [0x000fb] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.ModuleWriter.WriteModule (Mono.Cecil.ModuleDefinition module, Mono.Disposable`1[T] stream, Mono.Cecil.WriterParameters parameters) [0x00002] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.ModuleDefinition.Write (System.IO.Stream stream, Mono.Cecil.WriterParameters parameters) [0x00019] in <a3989f8c34e6476eaca56644d5639ee8>:0
at Mono.Cecil.AssemblyDefinition.Write (System.IO.Stream stream, Mono.Cecil.WriterParameters parameters) [0x00000] in <a3989f8c34e6476eaca56644d5639ee8>:0
at AssemblyUpdater.Application.Program.UpdateAssembly (AssemblyUpdater.Application.AssemblyOptions config, AssemblyUpdater.Core.AssemblyUpdaterContext context) [0x00091] in <6b425e602f6d4793894614a2367e88a8>:0
at AssemblyUpdater.Application.Program+<>c__DisplayClass0_0.<Main>b__1 (AssemblyUpdater.Application.UpdateOptions o) [0x0004d] in <6b425e602f6d4793894614a2367e88a8>:0
at CommandLine.ParserResultExtensions.WithParsed[T] (CommandLine.ParserResult`1[T] result, System.Action`1[T] action) [0x0001e] in <5f6458f0234f43a48c09047109c24684>:0
at AssemblyUpdater.Application.Program.Main (System.String[] args) [0x00046] in <6b425e602f6d4793894614a2367e88a8>:0
Following assemblies were successfully updated but due to the failed ones above they were ignored (not copied to the destination folder).
UnityEditor.Scripting.APIUpdaterLogger:WriteErrorToConsole(String, Object[])
UnityEditorInternal.APIUpdating.APIUpdaterManager:HandleAssemblyUpdaterErrors(IEnumerable`1) (at C:/buildslave/unity/build/Editor/Mono/Scripting/APIUpdater/APIUpdaterManager.bindings.cs:224)
UnityEditorInternal.APIUpdating.APIUpdaterManager:UpdateAssemblies() (at C:/buildslave/unity/build/Editor/Mono/Scripting/APIUpdater/APIUpdaterManager.bindings.cs:111)
UnityEditorInternal.APIUpdating.APIUpdaterManagerrocessImportedAssemblies(String[]) (at C:/buildslave/unity/build/Editor/Mono/Scripting/APIUpdater/APIUpdaterManager.bindings.cs:369)

 

I have the same problem. I have uploaded a test project. When you reimport the files in the plugins, the error will show in the console.

 

I have the same problem after upgrading from 2018.4 to 2019.2.
Do you have any update?

 

@RakNet and @CaryLee
were you guys able to find a solution to this?

 

Nope, still getting the issue.

 

I was going to test this on 2019.3.0f1 (RC) but it has another problem and I doesn't start up.
Also I don't think they fixed it on 2019.3 either.

 

@RakNet
For my external assembly projects, I used to reference only the Managed/UnityEngine.dll; not the DLLs in Managed/UnityEngine folder.

2019.2 is forcing me to reference individual module DLLs one by one. This may also be the source of the problem we are facing.

Do you experience this too?

 

@RakNet
Also, have you ever file a bug report for this?

 

I think I found a temporary solution to this.

I compiled my assembly using DLLs from Unity 2019.1.14 because I don't need any changes from 2019.2.15.

2019.2.15 was able to import it correctly.

Also.. 2019.1.14 DLLs doesn't force me to reference individual module dlls. I can just reference the Managed/UnityEngine.dll and it can compile.

I think the cause of the problem was this change.

I hope being able to reference only the Managed/UnityEngine.dll works fine with 2019.3 and beyond. I'll try that next.

 

2019.3.0f3 (RC) has the exact same problem.

Assembly project have to reference individual module DLLs instead of single UnityEngine.dll.

Unity throws the same error when the compiled assembly is imported:

"Unable to update following assemblies:Assets/<name of assembly>.dll (Name = , Error = 131) (Output: C:\Users\<username>\AppData\Local\Temp\tmp79643fe7.tmp)

 

I tried most of the versions. This problem start exactly at 2019.2.0.

 

I submitted a report for the bug causing this bug. The error we are experiencing here is an effect of the main bug.

For my personal record keeping purposes, I created another post for the causing bug.
https://forum.unity.com/threads/bug...-compiled-starting-from-2019-2-0-also.793692/

 

Yes, however it was not acted upon.

 

I am building my assemblies using the DLLs from the same Unity version which we try to import our assemblies. My assemblies doesn't have any obsolete method calls. Unity doesn't need to modify/update them.

This problem happens on 2019.2.0 and above.

Also, the cause of this problem is another bug/problem. Can you comment on this problem too?
https://forum.unity.com/threads/bug...-compiled-starting-from-2019-2-0-also.793692/

 

@AdrianoVerona_Unity Do you have any updates on your "Exception" point (#3 above)? It sounds like you're saying that from 2019.2 on, we can write managed plugins, but we can't debug them, because the PDB and DLL files will be out of sync once the API Updater process alters the the latter and not the former. This is assuming that we reference Unity modules instead of the usual monolithic

UnityEngine.dll

. That seems like a pretty serious issue. Has it been resolved in any of the Unity 2019.3 or 2020.1 pre-releases?

Also, FWIW, I was able to get the API Updater working after deleting the PDB like you suggested. I was experiencing an

InvalidOperationException

, not a

NullReferenceException

like @RakNet, but the error occurred during Mono.Cecil assembly parsing, so I'm sure the error was related. Again, I'm now just unable to debug my API-updated assembly...

 

@Rabadash8820 In my experience, Unity tries to reimport/modify our DLLs again and again because it fails due the the exception.

Only way to avoid this problem as a workaround is to reference older Unity DLLs from version 2019.1.X as long as you don't need any API from newer ones.

 

@Xtro Yeah that's been my experience as well, unless I delete the PDBs anyway. Referencing the old Unity DLLs isn't an option for me unfortunately, as I need to reference the

UnityEngine.UI.dll

from the new

com.unity.ugui

package, and because it references the Unity modules, I have to reference those modules in my plugin's csproj as well, leading to this weird DLL update scenario.

 

Can you not reference the old UI dll too?
I'm doing it.

 

I'm not sure what you mean by the old UI dll. The old DLL is gone;

UnityEngine.UI.dll

is no longer present in Editor/Data/Managed under 2019.2.x. If you mean using that DLL from a previous version of Unity...I suppose that might work. I would have to keep additional installations around which is less than optimal, and I don't really like the idea of mixing versions of Unity APIs; that's just begging for build errors at some point... Still, I might give that a try.

Would still like to know the status of this issue in 2019.3 @AdrianoVerona_Unity

 

@AdrianoVerona_Unity

Any estimate for fixing the problem?

I still didn't get a response from QA team about my bug report. It can be seen here: https://forum.unity.com/threads/bug...-compiled-starting-from-2019-2-0-also.793692/

 

Nice to hear. My humble opinion, it wasn't a good decision.

Referencing individual assemblies instead of UnityEngine.dll is very very tiresome and it's hard to maintain.

 

Finally we have an issue tracker entry for my bug report here: https://forum.unity.com/threads/bug...e-compiled-starting-from-2019-2-0-also.793692

 

Hi Adriano. I got an answer from Unity QA about my bug report. They say it's by design and they provide a possible solution to my problem. I haven't tried it yet. https://forum.unity.com/threads/bug...rting-from-2019-2-0-also.793692/#post-5381919

But you said you may revert this decision of replacing modules with UnityEngine.dll.

It is really gonna happen? How should I proceed? Should I wait for the revert?

 

@AdrianoVerona_Unity

Necroing this to ask if there has been any progress or workarounds for the PDB issue? I am building portable PDBs and I am seeing the following exception:

Spoiler: Code

Code (CSharp):

1. Unable to update following assemblies:Assets/Deep Space Labs/SAM/Scripts/Editor/EditorSAM.dll (Name = EditorSAM, Error = 131) (Output: C:\Users\kyleg\AppData\Local\Temp\tmp258b8091.tmp)
2.  
3. System.InvalidOperationException: Operation is not valid due to the current state of the object.
4.   at Mono.Cecil.ModuleDefinition.ReadSymbols (Mono.Cecil.Cil.ISymbolReader reader) [0x0002f] in <a6860a9f6366437387ebdc1f225b7fd4>:0
5.   at Mono.Cecil.ModuleReader.ReadSymbols (Mono.Cecil.ModuleDefinition module, Mono.Cecil.ReaderParameters parameters) [0x0005a] in <a6860a9f6366437387ebdc1f225b7fd4>:0
6.   at Mono.Cecil.ModuleReader.CreateModule (Mono.Cecil.PE.Image image, Mono.Cecil.ReaderParameters parameters) [0x00081] in <a6860a9f6366437387ebdc1f225b7fd4>:0
7.   at Mono.Cecil.ModuleDefinition.ReadModule (Mono.Disposable`1[T] stream, System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0000d] in <a6860a9f6366437387ebdc1f225b7fd4>:0
8.   at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0006c] in <a6860a9f6366437387ebdc1f225b7fd4>:0
9.   at Mono.Cecil.AssemblyDefinition.ReadAssembly (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <a6860a9f6366437387ebdc1f225b7fd4>:0
10.   at AssemblyUpdater.Core.AssemblyUpdaterContext.ReadAssembly (System.String assemblyPath, APIUpdater.Framework.Log.IAPIUpdaterListener listener, System.IO.FileAccess mode, System.String[] searchPaths) [0x0006e] in <2f1fd028b428454284156a3a0c9586d6>:0
11.   at AssemblyUpdater.Core.AssemblyUpdaterContext.From (System.String assemblyPath, APIUpdater.Framework.Configuration.ConfigurationProvider configuration, System.String[] assemblySearchPaths, APIUpdater.Framework.Log.IAPIUpdaterListener listener) [0x00015] in <2f1fd028b428454284156a3a0c9586d6>:0
12.   at AssemblyUpdater.Core.AssemblyUpdaterContext.From (System.String assemblyPath, System.String[] assemblySearchPaths, APIUpdater.Framework.Log.IAPIUpdaterListener listener) [0x00000] in <2f1fd028b428454284156a3a0c9586d6>:0
13.   at AssemblyUpdater.Application.Program+<>c__DisplayClass0_0.<Main>b__1 (AssemblyUpdater.Application.UpdateOptions o) [0x0001d] in <2f1fd028b428454284156a3a0c9586d6>:0
14.   at CommandLine.ParserResultExtensions.WithParsed[T] (CommandLine.ParserResult`1[T] result, System.Action`1[T] action) [0x0001e] in <5f6458f0234f43a48c09047109c24684>:0
15.   at AssemblyUpdater.Application.Program.Main (System.String[] args) [0x00048] in <2f1fd028b428454284156a3a0c9586d6>:0
16.  
17. UnityEditor.Scripting.APIUpdaterLogger:WriteErrorToConsole (string,object[])
18. UnityEditorInternal.APIUpdating.APIUpdaterManager:HandleAssemblyUpdaterErrors (System.Collections.Generic.IList`1<UnityEditorInternal.APIUpdating.AssemblyUpdaterUpdateTask>)
19. UnityEditorInternal.APIUpdating.APIUpdaterManager:UpdateAssemblies ()
20. UnityEditorInternal.APIUpdating.APIUpdaterManager:ProcessImportedAssemblies (string[])

The issue is definitely the PDB file, because if I remove it the API Updater runs without issue. I have double checked to make sure I am using a portable PDB and not the native one.

The issue occurs when updating from a DLL built on Unity 2021.1.0f1 to Unity 2021.2.14f1.

Has it been fixed for 2022?

Edit:

I should also mention that I understand why the API Updater is running and even know the lines of code that are being updated by it. The issue I have is the DLL is for an Asset Store product, where I'd like to support a Unity 2021.1 version, a Unity 2021.3 (LTS) version, and so on. So I'd like in between users to just use the API updater to update the two lines of code, but unfortunately that is not possible at the moment with the PDB issues.

 

@AdrianoVerona_Unity

Submitted

CASE IN-38297

It says not to share the bug report link. Should I? Or should I PM you with it?

To be honest, while it would be nice to have this fixed, it seems like it might be with 2022 so I am not going to be upset if you don't have the time to look at it, as I can likely work around the problem if it's just isolated to pre-2022.