Unity Incremental C# Compiler - deprecated

Well shoot, I figured I would try again now that the compiler has been updated a bit, but right off the bat I was greeted by:

Code (CSharp):

1. UNetWeaver error: Exception :System.IO.IOException: Sharing violation on path Temp\Assembly-CSharp.pdb
2.   at System.IO.File.Delete (System.String path) [0x00073] in <e1a80661d61443feb3dbdaac88eeb776>:0
3.   at Unity.UNetWeaver.Weaver.Weave (System.String assName, System.Collections.Generic.IEnumerable`1[T] dependencies, Mono.Cecil.IAssemblyResolver assemblyResolver, System.String unityEngineDLLPath, System.String unityUNetDLLPath, System.String outputDir) [0x002cf] in C:\buildslave\unity\build\Extensions\Networking\Weaver\UNetWeaver.cs:1862
4.   at Unity.UNetWeaver.Weaver.WeaveAssemblies (System.Collections.Generic.IEnumerable`1[T] assemblies, System.Collections.Generic.IEnumerable`1[T] dependencies, Mono.Cecil.IAssemblyResolver assemblyResolver, System.String outputDir, System.String unityEngineDLLPath, System.String unityUNetDLLPath) [0x0004c] in C:\buildslave\unity\build\Extensions\Networking\Weaver\UNetWeaver.cs:1888

 

Before z00n's solution I was using this band-aid way to fix the problem, that is scan all of your .csproj files and replace the line every time the script recompiles. For me it does not add noticable reload time. It might be useful for you.

https://github.com/5argon/E7Unity/tree/master/-EditorScripts/CsprojMod

 

@5argon: that was it! I forgot to install @z00n plugin. Thanks!

So, the steps are:

1. Install @z00n's plugin: https://github.com/zoon/C-Sharp-Latest-for-Unity/releases

2. Deactivate building from IDE: "Unity Preferences -> Compiler -> Enable building from IDE -> Off", and

3. Run @z00n's nuget command on the folder where Package.json file is located for the incremental compiler: https://gist.github.com/zoon/d35a0777bd83d2971a1ec10ecff2c060

 

Hm, unfortunately I see exactly zero benefit when activating the Incremental Compiler :-(

Our Setup:
- Unity 2018.1.2f1
- IncrementalCompiler 0.0.42-preview.1 (PackageManager)
- i7 CPU
- Both Unity and the project are on an SSD.
- When we start a new project, we use our script base/framework, which we developed over the years, as a base. It consists of about 600 scripts (which should be a great test for an incremental compiler!) plus about 50 Editor scripts (none of which are running constantly).
- This framework originally also has about 150 Shaders, Materials, textures, and Prefabs (each), and 13 Models. However, for these tests I deleted all of those (which actually doesn't make any difference in the timinigs at all), so the project contains ONLY the 660 scripts, plus 80 Scenes (which shouldn't matter, either), and little else.
- This script base currently has about 280 compiler warnings (sue me...who has time for cleaning up stuff like that? x-D About 95% of those are "is obsolete" warnings (we develop since Unity 2.6...))
- According to the profiler, these warnings are NOT the reason for any slowdowns: LogStringToConsole, called 285x, GC alloc 0.8MB, 53ms
- All times were measured between "switching back to Unity after editing+saving a file in VS2017" and "the compiler warnings are dumped to the Console".
- All times were measured with the Profiler window CLOSED.

I compared 2017.4.3 to 2018.1.2, and also compared .NET 3.5 to .NET 4.6/4.x, which also makes a noticeable difference.

The results are as follows:
2017.4.3 .NET 3.5: 6.5s
2017.4.3 .NET 4.6: 8.8s
2018.1.2 .NET 3.5: 7.2s
2018.1.2 .NET 4.6: 8.0s
2018.1.2 .NET 4.6 incremental: 6.5s
2018.1.2 .NET 4.6 incremental, no unnecessary packages (=the stuff apparently included in every new project by default, i.e. Ads, Analytics, In-App-Purchasing, ...): 6.5s

The conclusions:
- Using .NET 4.x is MUCH slower than .NET 3.5, for both Unity versions
- 2018 is slower than 2017 for .NET 3.5, but faster for .NET 4.6...?
- Yes, using the incremental compiler IS faster than the built-in compiler (although by only 20%, which is not what I would expect from compiling 659 scripts less)
- ...but the resulting waiting time of 6.5s is EXACTLY the same as 2017 with .NET 3.5, so the net benefit for us is...exactly ZERO :-(
- If only those scripts are re-compiled that actually change - WHY does Unity still dump all 285 compiler warnings each time?

After these results I used the Profiler trying to figure out what's taking so long. It's still not really clear to me, especially since the output is often quite inconsistent (i.e., sometimes the total time of a tree claiming to be 0ms, when in fact there is at least one entry with 1150(!)ms (see last screenshot). Or claiming that 4900ms are spent in Encoding.GetEncoding(), and so on).

First there is a block of 20-40 frames of "Throttle MainMessageLoop" of 100ms each. No idea what it does, but that's already 2-4 seconds...

This block is immediately followed by 2.3 seconds of AssetDatabase.Refresh. It spends time in GetMeshProcessorVersions(), GetAudioProcessorVersions(), GetTextureProcessorVersions(), and such. Even though the project doesn't contain ANY of these...

Then, a few pages later, there are two major peaks. The first one is about 1 second, which spends most of its time (plus 26MB GC allocation...) in something called "Weaver":


Then, only a few frames after this, the major compile/assembly peak shows up. 5.3 seconds, falsely(?) attributed to "Encoding.GetEncoding()", and more importantly, calling all the GetMeshProcessorVersions(), GetAudioProcessorVersions(), GetTextureProcessorVersions() etc. from above AGAIN!

This last screenshot is about the incorrectly logged 0ms time. It is from the frame immediately following the second screenshot.


Am I missing something? Or will these issues be resolved for the release version?
It would be really, REALLY great if Unity were able to NOT mess with 659 classes unnecessarily if only one class in one file (which no other class uses!) changes! :-/
So the concept of an incremepntal compiler is GREAT! ...but so far we don't seem to get an improvement from it :-(

 

Read the thread why. Sadly the amazing gains from the compiler are occluded by assembly/domain reloading and (re)serialisation.

While I am here - any ETA on jumping to error lines when double clicking console? Doesn't work here.

 

@Dom_Laflamme Will Unity gain performance-improvement by updating C# runtime, like this? Any plans?

https://blogs.msdn.microsoft.com/do..._source=vs_developer_news&utm_medium=referral

 

I did read the thread (well, most of it, anyway) and yes, I noticed the posts that mentioned the problems you describe, and even @Dom_Laflamme mentiones in his original post already, that "the new compiler does not impact the time it takes to do a “domain reload”".
However, he also says "The assembly in question (Unity.Mathematics) is rebuilt, then all assemblies dependant on it are quickly re-emitted.". But this is not what we/I see. There is no "quickly". If the difference between 6.5s and 8s is indeed from compiling only ONE script, as opposed to all 660, it means that 80% of the waiting time of a typical live project are NOT affected by the incremental compiler optimizations.

What I'd really like to hear is an "official" statement of the developer along the lines of "Yes, that is correct" or "No, you need to configure x or structure your code like y to improve these times", and maybe even "We are aware that the pure compile times are only a fraction of the total time the user sees, and we are looking into optimizing these parts as well" (for example, maybe there is a way to NOT re-emit/re-serialize/re-whatever all assemblies, if they are unaffected by the modified script, etc.)

 

I know I still have the same assembly reload time, but I am surprised you are not gaining anything from incremental compiler at all? My project got a MASSIVE speed up from like 10-20s (more when modifying something up the dependency chain) to 4-5s every time regardless of what script I modified, I don't have to worry about making changes to scripts with a lot of dependencies now. And of course plus the same assembly reload time of about 3-5s. I am very sure it is better with UIC, I used to be able to open Facebook to check notifications and come back every time I add a single Debug.Log but now I can't anymore. (It is good that I can't)

This is the amount of scripts and asmdefs I have currently by the way, if it might help debugging why the new compiler results in more compile time for you.

 

Just tested this locally and it seems to work out well. Recompilation does seem to be about the same or marginally slower than before.

I'm also testing out using C# 7.2 features, namely ref locals and ref returns, and it compiles and builds properly locally. The package doesn't seem to allow it, however, in Unity Cloud Build:

Code (csharp):

1.  
2. 1329: [Unity] Assets/Code/src/Runtime/Match/Match.cs(74,7): error CS1644: Feature `byref locals and returns' cannot be used because it is not part of the C# 6.0 language specification

 

No speed up for us, 11.5 second compile time before and after..

I see in the profiler
6.5 seconds is assembly reloading,
1.2 seconds is SceneTracker
1.2 seconds is UpdateScene

so it seems like compile time is fairly irrelevant..

I look forward to this 500ms turn round time happening one day though..

 

My goal is to one day win the lottery, I am going to work really hard to get as close to that as I can as well. : D

 

Unity uses a modified fork of Mono, so that's not really on the table, so to speak. But, if a future version of Mono adopts some of the changes in .NET Core 2.1, then yes, but then only once Unity merges that Mono update into its fork.

(I believe there's a decent chance of this happening eventually, as I believe the Mono project has been pulling in .NET Core code when it makes sense, and Unity devs have said they plan to update their fork of Mono more regularly.)

Edit: Even then, if you use IL2CPP, some of the reported perf gains may not carry through, whether it be due to language/compiler differences or how Unity produces the C++.

(Someone please correct me if I'm wrong on any of these points, this is just my personal understanding of things.)

 

Same issue: as it's happening with the Samples project from the github repo, I posted here: https://forum.unity.com/threads/samples.522629/page-2#post-3520312

 

Compilation time before: 7 sec
Incremental: 6 sec

Had to fix unet bug. I'll wait for more stable version.

 

Can we have someone from unity give opinions about assembly reload performance?
This same issue prevented us at Two Point Studios from using assembly definition files since it actually increased rebuild times due to it increasing assembly reload times.
It looks like without making assembly reload faster, an iterative compiler would make no difference for a lot of us.

 

Sorry if i'm obvious, but incremental compiler is still on preview. It's not meant for production ready, yet. I still wanna see the 500ms reload time, which I'm not 100% confident if they will get it, but this isn't something that you can get in few days.

 

The issue is even if the incremental compiler runs at 100% efficiency, it's still not the pain point while assemblies take so long to reload.

 

How do you uninstall the incremental compiler? I removed it from Package Manager but it's not removed in Preferences and the console is still opening. I guess it's still there. I want to know if it's the one causing the excessive unload/reload of asmdef projects.

 

@davenirline Are you also using the new Unity ECS?

Unity ECS (Entities) 0.0.12-preview.5 has a dependency on "com.unity.incrementalcompiler": "0.0.42-preview.1"

So even though you don't have it installed via the Package Manager, it will still be used.

 

I see. Thanks.

 

Moved our complete codebase back to Assets and the results are great so far. Mono compiler took around 60 seconds to compile + reloads. MSBuild took around 7 seconds + additional dll load step of a few seconds, still alot faster than the old mono compiler. Incremental (Roslyn) compiler as expected pretty much takes the same time as MSBuild and the dll load step is gone.

Could you please publish rough change logs for new versions in the future?

 

Hi @Dom_Laflamme
Another excited user here somewhat saddened by running head-first into the Sharing Violation error. Where can we "vote on this issue" or "register our interest" or "hear news" or whatever?

@SugoiDev / @hjupter Am I right thinking that UNet Weaver hack will prevent UNet from being used/working? I'm happy to hack but I *am* using UNet so

 

I'm not sure what the weaver actually does, but it probably is necessary for UNet. If you end up patching it, let us know your experience!


I don't know why this thread went silent of developers voices. This compiler is really nice and they are even using it with the ECS stuff.

 

The weaver makes the "magic" happen for SyncVars and so on.
For example it triggers dirty flags when you assign to a SyncVar field.

There are other things as well, but essentially it just does code/assembly rewriting to make it possible for SyncVars, RPCs and other stuff to be a thing.

 

Ah, thanks for the info!

We have an answer, then: the current Incremental Compiler is not compatible with UNet at all.
I guess users making use of UNet will have to wait until Unity manages to fix this.

 

I think the weaver is a really bad design. The concept behind it isn't solid at all and it yields almost no benefit. Photon needed no weaving nonsense.

 

I wonder if one of the reasons behind it not being fixed for this compiler might be that it will changed/be dropped.
I'm stoked to see reload times going down, finally. The weaver isn't light (not as unoptimized as the AssetPostprocessingInternal's PostProcessors, but still not good).

 

Forgive me. I have to strongly disagree. I see that in the completely opposite way.
I don't mean to convince you but maybe I can help you see why I think the UNet weaver is actually excellent, so let me explain:

The concept is that you don't have to do error-prone things like manually setting error flags. Surely you'd forget it here and finding out why suddenly things don't work only sometimes, is super hard and time consuming to debug.

Photon decided to do a really lazy bypass to the problem. They simply keep checking for changes, which not only causes a huge increase in needed cpu time, but also it obviously has to cache the "old known value" to it can compare against it to determine if there was a change.
Personally I hate the way photon does things. It's slow (continous checking), bloated (the need for caching which can be huge when you suddenly duplicate all value types), not even safe at all when you have value types that don't (or do but in the wrong way) provide custom equality operators!
Then there's no code generation at all, which means that caching has to be done in untyped, non-generic, and thus really slow dictionaries (which have quite a bit of overhead of their own since dictionaries use a "bucket system").
Value types get boxed all the time, further adding allocations and GC pressure... the whole concept of how Photon does things might seem cool from the outside, but it is pretty disgusting on the inside.

And now how are fields read/written? Through reflection, not even compiled into expression trees or anything. And of course since reflection cannot use generic type arguments you pay the price for boxing 3 TIMES! (networking, reflection read, reflection write)

If one is not aware of what fresh hell is going on behind the scenes here, then it might look nice, yea.
(And by the way, it's absolutely understandable that people don't take a look at this if they're working alone)
But if you take a look behind the scenes, it's absolutely insane...

IMHO Photon has literally THE worst networking implementation I could possibly imagine.
I can only guess why it was done that way. To save developer time? Not having the needed know-how to correctly do dynamic code generation or making their own weaver?
Sure it is portable and "easy" to understand if you know reflection, but whew, at what price...


There's a reason why Unity decided to have a "weaver" thing. The benefits it yields are:
- The UNet Weaver is as fast as theoretically possible. No extra overhead to check types
- No value type boxing
- Doesn't need to reserve space for anything, no dictionaries
- No allocations, not even any per-frame overhead since it uses bit masks.
- General improvements in basically every UNet system from SyncVars to Commands/RPC.
- It doesn't have to do reflection at any point (which is a huge plus for memory and cpu performance reasons)

I'd be interested in knowing why you think the UNet weaver it is not a solid concept.
Because from my current point of view the picture is pretty clear.

edit:
the sharing violation error in the weaver is likely an easy fix for the guys at unity.

 

Disclaimer:
I I didn't mean my previous post to be insulting if it came off that way. <3

Im simply saying that photon has massive potential for improvement and that the unet weaver is actually a pretty awesome thing if you know the reasons

 

I just reported an intermittently reproducible bug with the new incremental compiler:
Bug # 1048781

Partial files that have serialized fields in both files seem to get added in a different order between the editor and build causing serialization problems.
This worked fine in all previous versions of Unity, and works without the Incremental Compiler.

Other issues I've noticed
The compiler will just stop working multiple times per day, the spinner will just keep going forever and I need to close unity, which will sometimes freeze requiring killing the process. I haven't been able to reproduce this in a minimal project, so no bug report for this one.

It doesn't like lots of asmdef files, sometimes this also causes a serialization problem between editor/build. It also exasperates the constant Visual Studio reload problems. For now I have removed all asmdef files.

Edit: I also get the error "Copying assembly from directory Temp to Library/ScriptAssemblies failed" sometimes which requires restarting Unity. Not sure how to reproduce.

Spoiler: Bug Report Details

Unity 2018.1.3f1
Incremental Compiler 0.0.42-preview.5

Reproduction Steps:
1. Open Project
2. Build for windows
3. Observe any errors in console (sometimes the first build will error)
4. Build for windows again
5. Observe errors in console:

Type '[Assembly-CSharp]ExampleA' has an extra field 'OldField2' of type 'System.String' in the player and thus can't be serialized (expected 'NewField' of type 'System.String')

Fields serialized in Editor, class 'ExampleA'
'OldField' of type 'System.String'
'NewField' of type 'System.String'
'OldField2' of type 'System.String'

Fields serialized in target platform, class 'ExampleA'
'OldField' of type 'System.String'
'OldField2' of type 'System.String'
'NewField' of type 'System.String'

Error building player because script class layout is incompatible between the editor and the player.

6. If you do not get the errors, Close Unity and retry from Step 1. It doesn't happen every time, so might be a race condition.

Problem Description
Partial files that have serialized fields in both files seem to get added in a different order between the editor and build causing serialization problems.
This worked fine in all previous versions of Unity, and works without the Incremental Compiler.

Why are parial files needed?
- Some assets already use them such as the A StarPathfinding Project on the Asset Store. It uses them to separate legacy fields into a separate file.
- They are useful for code generation. Code gen can create partial files with some fields, you can create another class with extra fields without touching the code gen file.

Workaround?
If I build 5 times in a row, sometimes it will eventually work. Might just be luck that they all happen to get into the right order.

 

I noticed it stopping working randomly as well. The "Copying assembly..." error can be solved by reimporting an asmdef file to trigger a recompile. But, the problem where it just stays compiling forever I can only fix by reopening Unity.

Since it's very hard to consistently reproduce I also could never submit a repro project.
I guess this is one of the dangers of threaded code that touches IO. Very hard to get right and many unknown edge cases.

 

I thought it was informative, and it made me appreciate the UNet weaver more!

 

Speaking of assembly reload times, did anyone notice it's much slower to enter play mode since 2017?
I have a 7 second delay on every playback due to assembly reload which I don't think it was here before.

 

I have a counter that displays the time to enter/exit playmode, as well as compile and assembly reload times.
I noticed a huge increase when using audio stuff. If I disable my audio stuff, I get 2-3 seconds to enter playmode with a small scene. With audio it jumps to 5-7 seconds the first time, then under 5 for the next times.
It's pretty weird. I mean, it just kills the domain and loads a new one. There shouldn't be much difference.

But, with the incremental compiler, my total time has been below 10s for my main assembly.
With a few patches of the editor I can shave another 2 seconds or so, at the cost of some weird behavior that forces me to restart a few times a day.

I'm excited to see it getting even lower if Unity continues to make progress in this area.

 

While Weaver is cool thing that you can not control, you actually pay development time while it do the work.
If Unity will allow to specify on asmdef level that there is nothing to do for weaver than it will be fine.

 

Unity QA was not able to reproduce the errors I am getting with the incremental compiler & partial files (Bug # 1048781)

They recommended updating, so I just installed the latest Unity beta (2018.2.0b7) and the latest Incremental Compiler (0.0.42-preview.6), but it still happens for me.

I am not sure what could be different on my PC. Intermittent bugs are the worst kind, hopefully it will just go away after a few updates to the incremental compiler.

 

I like being wrong and I like being corrected. It's rare but valuable so thanks for your time

The reason for me disliking weaver was mostly, I hate mystery boxes in code. I wanted to know what it was doing, why and so on. Also it seems to be an ongoing maintenance problem. If it makes for efficient code and isn't just for SyncVars (which is what I originally thought it was for) then I'll get with the program!

 

I am greatly interested in using c# 7 more than speeding up the compiling times. Is there any idea when this product will be production ready? Currently our titles actually compiles without problems, but if I start using c# 7 there is no way back, so I need to be sure it will be fine

 

Please add support for stopping play mode on compile - it's a small but lovely quality of life feature missing in the recent builds (I think it used to work?)

 

I noticed this is actually an option in the 2018.2 betas under the Unity Preferences -> General tab. There's 3 options:
* Recompile and continue playing i.e. break everything (still the default)
* Recompile when playmode is stopped manually.
* Stop and recompile.

 

It does not function (as of 0.0.42 preview 7) and it used to and still does with the non-incremental compiler.

 

I always used my own because I like it to enter playmode again if the compilation succeeded, so I didn't notice that feature wasn't working anymore.

I wonder why it broke, since the incremental compiler supposedly doesn't change the compilation callbacks. The callbacks are firing as normal for me, as I use them to track the compile times as well as to exit playmode.

Maybe the new built-in feature uses something deeper that is being affected by this compiler?

 

Hello,
I placed "-warnaserror+" in Assets/mcs.rsp when CI check for Assembly-CSharp-*.dll.
But, incremental compiler use the compile option when build packages (ex. com.unity.postprocessing).
Can I set compile option only for my scripts?

 

Good news, assembly reload optimization is coming soon in 2018.1

 

Hello!

I encountered a blocking problem with the incremental compiler. Having it installed and trying to build for UWP (with IL2CPP backend, haven't tested with .NET) always results in an "InvalidOperationException: Sequence contains no matching element" error.

I reported it using the bug reporter and the case number is 1054425 if anyone wants it.

 

I tried to find the reason why I can't enable the c# 7.2 features, but couldn't find the answer. Can you point out to me what I am missing as the new by ref functionalities are not detected?

 

Use incremental compiler on package manager? that one was up to date for me.

 

So on the latest compiler package on 2018.1, I had an asset from the asset store cause the compiler to compile the project over and over. Every time I clicked into the editor it triggered compiling again. Restarted Unity still the same.

Asset was Aquas.

 

Latest compiler package used to recompile shader based assets for me, until I did the following:

1. update to a recent 2018.2 beta
2. clear the library folder

Seb replied to me here that it was a general Unity problem and I am sharing the information if by chance, it could be helpful to you: https://github.com/Unity-Technologies/ScriptableRenderPipeline/issues/1531

 

The new compiler sounds awesome, but, sadly, I can't use it because it floods my Console with errors as soon as I enable it. Previously everything worked fine.

The situation is that I have an asset inside the Plugins folder and my other scripts reference it. With the incremental compiler they can't. Even though everything looks fine from inside of the Visual Studio, Unity acts as if nothing from the Plugins folder existed.
Moving a handful of scripts inside Plugins doesn't work, as they reference other classes, and those others reference others, so eventually everything would have to be a plugin.

For the time being, I instead moved that asset outside of the plugins folder – which gets rid of the aforementioned errors, but still leaves me with these two which now appear every time Unity compiles:

Spoiler: Errors

Code (CSharp):

1. UNetWeaver error: Exception :System.InvalidOperationException: Operation is not valid due to the current state of the object.
2.   at Mono.Cecil.ModuleDefinition.ReadSymbols (Mono.Cecil.Cil.ISymbolReader reader) [0x0002f] in <28cdca1704d2491781795499c297b78b>:0
3.   at Mono.Cecil.ModuleReader.ReadSymbols (Mono.Cecil.ModuleDefinition module, Mono.Cecil.ReaderParameters parameters) [0x0004a] in <28cdca1704d2491781795499c297b78b>:0
4.   at Mono.Cecil.ModuleReader.CreateModule (Mono.Cecil.PE.Image image, Mono.Cecil.ReaderParameters parameters) [0x00081] in <28cdca1704d2491781795499c297b78b>:0
5.   at Mono.Cecil.ModuleDefinition.ReadModule (Mono.Disposable`1[T] stream, System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0000d] in <28cdca1704d2491781795499c297b78b>:0
6.   at Mono.Cecil.ModuleDefinition.ReadModule (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x0006c] in <28cdca1704d2491781795499c297b78b>:0
7.   at Mono.Cecil.AssemblyDefinition.ReadAssembly (System.String fileName, Mono.Cecil.ReaderParameters parameters) [0x00000] in <28cdca1704d2491781795499c297b78b>:0
8.   at Unity.UNetWeaver.Weaver.Weave (System.String assName, System.Collections.Generic.IEnumerable`1[T] dependencies, Mono.Cecil.IAssemblyResolver assemblyResolver, System.String unityEngineDLLPath, System.String unityUNetDLLPath, System.String outputDir) [0x0000f] in C:\buildslave\unity\build\Extensions\Networking\Weaver\UNetWeaver.cs:1763
9.   at Unity.UNetWeaver.Weaver.WeaveAssemblies (System.Collections.Generic.IEnumerable`1[T] assemblies, System.Collections.Generic.IEnumerable`1[T] dependencies, Mono.Cecil.IAssemblyResolver assemblyResolver, System.String outputDir, System.String unityEngineDLLPath, System.String unityUNetDLLPath) [0x0004c] in C:\buildslave\unity\build\Extensions\Networking\Weaver\UNetWeaver.cs:1888
10. UnityEngine.Debug:LogError(Object)
11. Unity.UNetWeaver.Log:Error(String) (at C:/buildslave/unity/build/Extensions/Networking/Weaver/Program.cs:20)
12. Unity.UNetWeaver.Weaver:WeaveAssemblies(IEnumerable`1, IEnumerable`1, IAssemblyResolver, String, String, String) (at C:/buildslave/unity/build/Extensions/Networking/Weaver/UNetWeaver.cs:1896)
13. Unity.UNetWeaver.Program:Process(String, String, String, String[], String[], IAssemblyResolver, Action`1, Action`1) (at C:/buildslave/unity/build/Extensions/Networking/Weaver/Program.cs:34)
14. UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface:TickCompilationPipeline(EditorScriptCompilationOptions, BuildTargetGroup, BuildTarget)

Code (CSharp):

1. Failure generating network code.
2. UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface:TickCompilationPipeline(EditorScriptCompilationOptions, BuildTargetGroup, BuildTarget)

Which, of course, leads to this:


Am I missing some setting or a workaround to this issue?