Unity Incremental C# Compiler - deprecated

From the link to assset store

Spoiler

Lightning Fast Compilation and Module Management for Unity
UtilitiesStranger
Games
Unfortunately, Lightning Fast Compilation and Module Management for Unity is no longer available.
This package has been deprecated from the Asset Store. This means that new purchases of the package are not allowed and that only users who already purchased or downloaded the package before it was deprecated, are allowed to download it.
In most cases, package deprecation happens because the publisher is unable or unwilling to support the package anymore. We suggest looking for alternative packages or contacting the publisher directly.
If you've already purchased it and need to download a copy, you can do so here.

 

Thank you for your comment and your interest in the asset.
Actually I started developing this asset before Unity 2017 was out. I faced the problem everyone does of hindering and annoying compile time and messy project that is hard to manage to I decided to create this asset. A lot of things were going on that delayed the development, until asmdef was out, so I decided to use it instead, but found a lot of things that doesn't meet my use cases so I continued developing my asset.
In the description below FastCompilationLibrary (FCL) will be used for the asset analogous to asmdef

Let me give you a detailed answer.

First let's list features in the FCL that are not in asmdef files, some of them are implemented, some of them are to be implemented that will be indicated between brackets.

1. FCL can self contain Runtime, Editor, Plugin Runtime and Plugin Editor source code, while asmdef can only contain Player code. (already implemented)
2. Each FCL can have its own scripting define symbols (already implemented) and can choose to not sync with Player settings define symbols, while asmdef force synchronization with player settings define symbols and doesn't allow specific symbols for each asmdef
3. FCL can have runtime editor assembly called in the gui [Runtime DLL (used in editor)] along with the runtime and editor assemblies. It sounds a little confusing but it's simple. A runtime editor assembly is a runtime assembly that is compiled using UNITY_EDITOR scripting define symbols and doesn't go into final builds, while the runtime is compiled without UNITY_EDITOR defined and should make it to the final build. See the use cases below of why this might be necessary. (already implemented but not documented yet)
4. All dependencies of a certain asset that are not C# code like AAR files for android or gizmos that have to go into Assets/Gizmos can also be self contained in the FCL subdirectory and the asset will copy them appropriately (to be implemented)

Keep in my mind that the asset has practical problems that needs to be fixed, the major one is that the use of template cls file and the deprecated xbuild. However I think the concept itself is very good for developers and those issues can be fixed with time. I want to update the asset so that it builds the same way Unity build the Assembly-CSharp.dll and Assembly-CSharp-Editor.dll, but I'm not sure how Unity does it. It definitely doesn't use xbuild and probably doesn't use msbuild because it's not included with Unity and even if visual studio is not available it compiles, so can someone tell me that?


Second the features of asmdef from my point of view that's not in the asset

1. A huge advantage is that any mono behaviour or scriptable asset assigned will still be assigned correctly with the same GUID before and after using asmdef (I plan to add conversion of GUIDs in the future)
2. There is one solution that has all the csproj files including asmdef (this feature is to be implemented in FCL also)
3. It can be defined to only certain platforms. That is also supported by FCL through import settings of the compiled DLL, however platform settings will be added to the FCL file itself in the future.

Finally here are some use cases that can take benefit from the plugin more than the asmdef

Use Case - Assets that has Runtime and Editor source code (use of feature 1):
Almost all scripting assets or editor extensions have runtime source code and Editor source code (the one under Editor folder). Using asmdef if you modify any runtime script all the editor code of all assets along with Assembly-CSharp-Editor will be recompiled. However if you modified FCL's runtime or editor source code, only the FCL along with Assembly-CSharp-Editor will be compiled, but the other FCL will not be compiled except if they have the modified FCL as dependency.
Also you will have a self contained project just for your editor scripts of the specific FCL encouraging modular design and preventing you from accidentally using another Editor script that gets compiled into Assembly-CSharp-Editor or from another FCL that's not a dependency.

Use Case - Scripting assets with options using scripting defines (use of feature 2):

Some assets have optional components that can be enabled/disabled with scripting define symbols. For example Asset A might support Asset B through a scripting define symbol called ASSET_B_SUPPORT.
In case of asmdef, if you want that support you will add ASSET_B_SUPPORT to the player setting scripting define symbols which will make everything just recompile.
In the case of FCL you will add ASSET_B_SUPPORT to the specific FCL scripting define symbols.

Use Case - Runtime scripting assets with some editor code (use of feature 3):

Some scripting assets has MonoBehaviour with a code like this.

Code (CSharp):

1. #if UNITY_EDITOR
2. //some code that only runs in editor
3. #endif

I personally use this a lot especially with [ExecuteInEditMode].
Using asmdef when building a game binary the asmdef assembly will be recompiled without UNITY_EDITOR defined. With FCL the runtime library binary that was built without UNITY_EDITOR will be used without having to be recompiled.

Use Case - Scripting assets customization and management with git (use of features 1 and 4):

A lot of the editor extensions and scripting assets will need to be modified to make professional game. Even in-house developed assets will also need to be edited for new games produced by the same studio. The workflow allowed by this asset will help greatly with such situation.

1. The developer can have a self contained subrepository with the in-house or third party scripting assets
2. The developer can create branch specific to the his game needs and he can always update the third party asset on master branch then merge the update from master into the game specific branch if he wanted to and revert back those updates if it breaks his game. That would be extremely complicated if the whole game is in one repo.
3. The design of FCL dis-encourage mistakes that reference code from the game itself inside the FCL code allowing the FCL to be reused in future games from the same studio

Use Case - Assets with Plugin source code (use of features 1 and 4):

Some scripting assets and specially mobile SDKs might have some CSharp scripts in the plugin folder and other scripts in other folders, for example Assets/Facebook/Scripts and Assets/Plugins/Facebook/Scripts. Using asmdef will not make a lot of different for the plugin part. Using FCL's current and future features however you get 2 main advantage

1. Self contained folder. So you can have all your scripts and other files inside subfolders under Assets/CompanyName/FCL Name for easy management and distribution
2. Compiling other plugin scripts will not make your plugin scripts re-compile except if the modification is in another FCL plugin script that's a dependency on your FCL

Use Case - Scripting assets publishing:

I believe the current way of publishing scripting assets on the asset store and even on github has a problem.

Problems with importing from the asset store

1. When you import from the asset store sometimes assets has multiple folders under the Assets folder because of the restrictions of having only one Assets/Gizmos and stuff like that. That makes it difficult to track changes in version control for that individual asset.
2. Scripting assets usually come in compiled and source forms with the source being zip file which makes it difficult to update if you are working with modified version of source, because after update you will have to manually delete the dll, extract the zip file to the correct location. That format is also difficult for asset creators to create because of the manual steps each time they want to publish an update

On git hub, usually whole project is stored in the repo which makes it impossible to just import it into your project cloning as sub module.

FCL proposed solution is to have assets distributed as self contained in one subfolder of the Assets folder with the FCL asset file containing necessary information for compiling the code and moving special files like gizmo files to the correct location.
In case of github, only that subfolder content should be stored in the repo which should be all what Unity needs to work correctly with the asset.

I'm sorry for this wall of text but I think it would benefit everyone so I'm glad to share it with the community.

 

After publishing the asset I found some bugs, so I deprecated the packages, fixed the bugs, then resubmitted to the store and I changed my mind and decided to make it free.
Please use the bitbucket version for now.

 

I tested the incremental compiler on our current project and was able to reduce compilation times slightly, so I think it's going in the right direction.

As has been mentioned in this thread, the benefit only shows when using asmdef files and splitting up the code into reasonable assemblies. This works well for code our team writes, but it gets tedious with our 3rd party asset store plugins. Previously it was nice to have all 3rd party assets in their own assembly, split into runtime and editor folders. Basically, put into Plugins folder and forget. But now I have to create multiple asmdef files per plugin (some of them have a dozen editor folders) and hook up all the dependencies between them (often I don't know these and have to go through each compilation error until everything is fixed again), because I have to separate editor from runtime assemblies.

Now I have my project split into 20 assemblies and one test assembly which contains only a single script. If I change this script, only this one assembly is recompiled, which takes 2.5 seconds (vs a full recompile of all assemblies standing at 18 seconds). To validate the improvements, I removed the incremental package and the compile time went up to 3-4 seconds again.

Sadly, the editor stutters and hangs during assembly reload (or potential asset serialization) after each compile, which makes the total time from making a change in code to seeing it in the inspector or play mode, feel more like 5-10 seconds.

When I compare all of this to building a dll in Visual Studio and copying it to Unity as part of the build process, I must say, that VS can build and copy the same library within a fraction of a second. Reloading in Unity also seems to be faster when using the DLL (not sure why this could be or if I'm imagining things, it's hard to measure this time exactly).

My personal bottom-line: I like the idea of the incremental compiler and I'm looking forward to seeing compile times dropping to 0.5 seconds on average, but the time it takes for the editor to stop freezing after compile and before play mode impacts my experience much more. Additionally, the work involved in setting up asmdef files and maintaining them when adding 3rd party code, consumes more time than saved by reduced compile times (at the current time). For my current project it took roughly an hour to split everything into separate asmdef files, which means, I would need to compile the project 3-4 thousand times before actually saving time.

 

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)
15.  

@Dom_Laflamme
Is there something you could say about this issue?
I can confirm it's still not working in `2018.2f10` and `2018.2.11f1` with the latest IC (0.0.42.preview22).
Should we avoid the incremental compiler altogether when using UNET?

 

Thank you very much for your reply. After your reply I have studied asmdef more in depth and now I'm aware of more features than I initially thought.

I created Lightning Fast Compilation and Module Management for Unity Pro that works with Assembly Definition Files and make it more convenient for certain use cases.
I'll update the free version to include asmdef support too.
I have updated the documentation regarding misinformation for asmdef and I'll update the bitbucket page too.
If the user of our plugin choose to use asmdef integration unfortunately custom definition symbols will not be available, but it's still very convenient.

I still believe that custom definition symbols will be greatly beneficial, but I understand the difficulties that may arise out of that.

Thank you again.

 

Hi @Xarbrough
I created an asset for this exact use case.
Lightning Fast Compilation and Module Management for Unity Pro
For your use case do the following.
For each asset from the asset store create a new fast compilation library with 'runtime' and 'editor' and 'Use Assembly Definition Files' enabled.
You can create the fast compilation library in the same folder of the asset by naming it after the asset folder. If the asset is in Assets/Devdog just name the library Devdog.
Or if you want to create it in another folder just copy the source code (all of it not including plugin source code) under the library folder.
Press 'Convert CS Files in Library Directory' and the library will auto detect the runtime and editor files and move them to appropriate places automatically creating two asmdef one for editor and one for runtime and adding dependency for you.
Of course you can use the dll approach if you don't want to use asmdef files.
Please check the documentation and contact me if you face any difficulties.
In the future hopefully asset creators will use this asset to create their asset in similar fashions and users of the assets can use a free version of this plugin to take advantage of faster compilation times.

 

Updating incremental compiler to 42 preview 21 today cause some XML summary comment issues in VC2017.


Reinstalled WIN Unity 2018.3.0b4 + VC2017 but this issue didn't fix up. Downgrade to the previous package does not fix it. Does anyone know how to get rid of this issue? Looks like code is depreciated all over the place.

Thank you.

 

Seems like you've got a setting somewhere that's set to complain if you don't have xml docs for methods. Very strange for that to kick in from updating the compiler. Check VC's settings menu, search for "xml" or "comment"

Warnings for "missing" comments is not a part of the language standard, but something a lot of editors include as it's a somewhat common in-house code guideline (see all of Unity's publicly available code).

 

Missing XML comment publicly

That's definitely happen when installing the new version 42 preview 21.

I have create a new empty project, did not installed bust, jobs, entities, Incremental. Tested a script all went nice!
Then added the latest bust, jobs, entities, Incremental and this issue starts over the whole new project.

Was able to fix it. Open Assembly-CSharp.csproj and Assembly-CSharp-Editor.csproj in the project folder root with text editor. find "nowarn".

Code (CSharp):

1. change from:
2. <NoWarn>0169</NoWarn>
3. to:
4. <NoWarn>0169,1591</NoWarn>

Edit: Unfortunately every time the compiler overwrite the existing changes in Assembly-CSharp-Editor.csproj. And setting suppress warning 1591 in VS2017 community is not recommended. There is no Project > Properties > Suppress Page.

 

It's the incremental compiler messing with <DocumentationFile> element in csproj files, not sure why. It started two months ago. I fixed it by patching the code that modifies csproj: https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-7#post-3620134

 

Hi!

We just ran into this issue, as a team member started using the Linux editor. The workaround is simply to use the 2018.3 beta, as that supports C# 7 out of the box.

I don't know if the incremental compiler is actually active on Linux builds - since having the package installed doesn't give access to C# 7 in 2018.2, I'm guessing that there's no incremental compiler that's Linux compatible, so the default compiler's used instead even if the package is installed. That's guesswork, though.

 

CS1591 Solution

Great that works! Opened the Unity.Pure.CSharp.Tests.dll with a simple text editor and renamed
"D o c u m e n t a t i o n F i l e" to "D o c u m e n t a t i o n F i l 0" and saved.

 

Was there ever a fix for this? I'm encountering this error whenever I import a specific asset (NodeCanvas) into my project.

Unity: 2018.2.6f1
Incremental Compiler: 0.0.42-preview.21

 

How do you know what version to add to the package mgr? For example, I see this post from March -- but I just see it now in October: Can I just enter the version I see now and upgrade it within?

If I don't know the version but know the package name, can I leave an empty str "" for the version?

 

The Incremental Compiler should already be in your Package Manager now, it depends what Unity version you're on I believe.

 

Last I tried it (few weeks ago) I still had the same issue. So unless something was fixed since then, no, same issue.

 

Hi. I used old inrcremental compiler and System.Threading.Task.Extensions.dll, System.Runtime.CompilerServices.Unsafe.dll from nuget for using ValueTask. It works quite well.

But when I update incremental compiler to latest(0.0.42-preview.21), it has internally old version of System.Runtime.CompilerServices.Unsafe (4.0.3.0) and I cannot use System.Threading.Task.Extensions anymore because it requires 4.0.4.1 of Unsafe.

Is there any method to use ValueTask with latest incremental compiler?

 

Hi, I got:

Code (CSharp):

1.  (0,0): [11.04.2018 01:14:31.509 nachm.] GetAnalyzersFromCompilation threw an exception: System.ArgumentNullException: Value cannot be null.
2. Parameter name: source
3.   at System.Linq.Enumerable.Where[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicate) [0x0000d] in <1b13ba6391c74847bbc3eddc86df7eee>:0
4.   at UnityEditor.Compilation.CodeAnalysisManager.GetAnalyzersFromCompilation (System.String assemblyFilename, System.String[] unityCompilerArguments) [0x0003f] in <b6235404321846dd874d88447d55cf5a>:0
5. System.Threading.ThreadHelper:ThreadStart()

Unity: 2018.3 B8
Package version of the incremental compiler: 0.0.42-preview.24

 

RoslynCSProjectAssetPostprocessor.cs screws with csproj encoding; it should be utf-8 AFAIK (or at least it should preserve prior encoding), instead it forces utf-16 with wrong BOM, resulting in issue almost identical to https://github.com/JetBrains/resharper-unity/issues/727

BTW, does anyone know if IC has any issue tracker whatsoever?

 

I'm getting the exact same thing. It started happening when upgrading from preview.21 to preview.24, so it's a recent regression.

Here's a stack trace with full logging turned on:

Code (csharp):

1.  
2.  (0,0): [11/05/2018 11:24:22.659 AM] GetAnalyzersFromCompilation threw an exception: System.ArgumentNullException: Value cannot be null.
3. Parameter name: source
4.   at System.Linq.Enumerable.Where[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicate) [0x0000d] in <839a3cb835c04d14aeb58d83bb7bc4bd>:0
5.   at UnityEditor.Compilation.CodeAnalysisManager.GetAnalyzersFromCompilation (System.String assemblyFilename, System.String[] unityCompilerArguments) [0x0003f] in <b6235404321846dd874d88447d55cf5a>:0
6. 0x0000000141535DE8 (Unity) StackWalker::GetCurrentCallstack
7. 0x000000014153C326 (Unity) StackWalker::ShowCallstack
8. 0x000000014140B85B (Unity) GetStacktrace
9. 0x00000001408AF3B0 (Unity) DebugStringToFile
10. 0x00000001418DA7D8 (Unity) DebugLogHandler_CUSTOM_Internal_Log
11. 0x00000000394746D0 (Mono JIT Code) (wrapper managed-to-native) UnityEngine.DebugLogHandler:Internal_Log (UnityEngine.LogType,string,UnityEngine.Object)
12. 0x00000000394745A3 (Mono JIT Code) [DebugLogHandler.cs:10] UnityEngine.DebugLogHandler:LogFormat (UnityEngine.LogType,UnityEngine.Object,string,object[])
13. 0x0000000039473E25 (Mono JIT Code) [Logger.cs:48] UnityEngine.Logger:Log (UnityEngine.LogType,object)
14. 0x0000000071587609 (Mono JIT Code) [Debug.bindings.cs:117] UnityEngine.Debug:LogError (object)
15. 0x000000007158727B (Mono JIT Code) UnityEditor.Compilation.UnityLog:Error (string,string,int,int)
16. 0x0000000071586939 (Mono JIT Code) UnityEditor.Compilation.CompilerLog:MessageInternal (UnityEditor.Compilation.LogTarget,UnityEditor.Compilation.MessageOutput,UnityEditor.Compilation.MessageOutput,string,string,int,int)
17. 0x00000000715863E3 (Mono JIT Code) UnityEditor.Compilation.CompilerLog:Error (UnityEditor.Compilation.LogTarget,string,string,int,int)
18. 0x00000000715861C3 (Mono JIT Code) UnityEditor.Compilation.CompilerLog:Error (string,string,int,int)
19. 0x00000000715860D3 (Mono JIT Code) UnityEditor.Compilation.CompilerLog:Error (string,string)
20. 0x0000000071585FF3 (Mono JIT Code) UnityEditor.Compilation.CompilerLog:Error (string)
21. 0x000000007158053B (Mono JIT Code) UnityEditor.Compilation.CodeAnalysisManager:GetAnalyzersFromCompilation (string,string[])
22. 0x000000007157E9B3 (Mono JIT Code) UnityEditor.Compilation.RoslynIncrementalCompiler:InvokeCompiler (string[],UnityEditor.Compilation.CustomCompiler/OnCompilerMessage,UnityEditor.Compilation.CustomCompiler/OnCompilationDone)
23. 0x000000007157DC9C (Mono JIT Code) UnityEditor.Compilation.ExternalCompilerBridge/<>c__DisplayClass6_0:<StartCompiler>b__0 ()
24. 0x0000000034AB50EF (Mono JIT Code) System.Threading.ThreadHelper:ThreadStart_Context (object)
25. 0x0000000034AB3B61 (Mono JIT Code) System.Threading.ExecutionContext:RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
26. 0x0000000034AB2EBB (Mono JIT Code) System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool)
27. 0x0000000034AB2CD3 (Mono JIT Code) System.Threading.ExecutionContext:Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object)
28. 0x0000000034AB232B (Mono JIT Code) System.Threading.ThreadHelper:ThreadStart ()
29. 0x0000000034AB2200 (Mono JIT Code) (wrapper runtime-invoke) object:runtime_invoke_void__this__ (object,intptr,intptr,intptr)
30. 0x00007FFF818AA65B (mono-2.0-bdwgc) [mini-runtime.c:2809] mono_jit_runtime_invoke
31. 0x00007FFF81831B72 (mono-2.0-bdwgc) [object.c:2915] do_runtime_invoke
32. 0x00007FFF8183AD32 (mono-2.0-bdwgc) [object.c:3067] mono_runtime_invoke_checked
33. 0x00007FFF818550CF (mono-2.0-bdwgc) [threads.c:1042] start_wrapper_internal
34. 0x00007FFF81854E16 (mono-2.0-bdwgc) [threads.c:1092] start_wrapper
35. 0x00007FFFB8A23034 (KERNEL32) BaseThreadInitThunk
36. 0x00007FFFBB431461 (ntdll) RtlUserThreadStart
37.  

@Dom_Laflamme, should we report incremental compiler bugs like this with the bug reporter, or is it still bleeding edge enough that we should just keep it to this thread?

 

I have the exact same error each time I press Play / Stop in our project.
This happens on 4 dll recompiled due to script changes :

Code (CSharp):

1. - Starting compile Library/ScriptAssemblies/Designer.Editor.dll
2. (0,0): [11/06/2018 11:40:47.821 AM] GetAnalyzersFromCompilation threw an exception: System.ArgumentNullException: Value cannot be null.
3. Parameter name: source
4.   at System.Linq.Enumerable.Where[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicate) [0x0000d] in <1b13ba6391c74847bbc3eddc86df7eee>:0
5.   at UnityEditor.Compilation.CodeAnalysisManager.GetAnalyzersFromCompilation (System.String assemblyFilename, System.String[] unityCompilerArguments) [0x0003f] in <b6235404321846dd874d88447d55cf5a>:0
6. UnityEngine.DebugLogHandler:Internal_Log()
7. UnityEngine.DebugLogHandler:LogFormat(LogType, Object, String, Object[])
8. UnityEngine.Logger:Log(LogType, Object)
9. UnityEngine.Debug:LogError(Object)
10. UnityEditor.Compilation.UnityLog:Error(String, String, Int32, Int32)
11. UnityEditor.Compilation.CompilerLog:MessageInternal(LogTarget, MessageOutput, MessageOutput, String, String, Int32, Int32)
12. UnityEditor.Compilation.CompilerLog:Error(LogTarget, String, String, Int32, Int32)
13. UnityEditor.Compilation.CompilerLog:Error(String, String, Int32, Int32)
14. UnityEditor.Compilation.CompilerLog:Error(String, String)
15. UnityEditor.Compilation.CompilerLog:Error(String)
16. UnityEditor.Compilation.CodeAnalysisManager:GetAnalyzersFromCompilation(String, String[])
17. UnityEditor.Compilation.RoslynIncrementalCompiler:InvokeCompiler(String[], OnCompilerMessage, OnCompilationDone)
18. UnityEditor.Compilation.<>c__DisplayClass6_0:<StartCompiler>b__0()
19. System.Threading.ThreadHelper:ThreadStart_Context(Object)
20. System.Threading.ExecutionContext:RunInternal(ExecutionContext, ContextCallback, Object, Boolean)
21. System.Threading.ExecutionContext:Run(ExecutionContext, ContextCallback, Object, Boolean)
22. System.Threading.ExecutionContext:Run(ExecutionContext, ContextCallback, Object)
23. System.Threading.ThreadHelper:ThreadStart()

 

I have another question cause I don't remember if this happening with previous incremental compiler revision (I didn't install it for a while).
But each time I start Unity this csc.exe window command is displayed but never shutdown until Unity is shutdown or until I close it.

 

Updated to "com.unity.incrementalcompiler": "0.0.42-preview.24",
and unity can not launch and open project

 

I believe that pops up, and stays up, if you have "Show output in console window" checked in the Compiler preferences:



Try unchecking it and see if that helps.

That preference should probably be renamed. I assumed that "console window" meant the Unity console window, not a Windows console window.

 

That's a good point ! That was this, I totally missed this point thanks !
But I don't understand the utility of this one cause it stays empty forever

 

In my case I had to use unity beta 2018.3.b09, go into package manager and select "Show preview packages"

After that I was able to see the package in package manager on the latest stable version (2018.2.14f1 at the time of this writing)

 

Something that makes this more obnoxious is that the error message contains a timestamp, which means the Unity Console can't even collapse these messages. Maybe remove the timestamp from the message? The messages appear otherwise identical.

 

This isn't directly related to the Incremental Compiler, but as I was adopting it, I found that I was getting really bad Unity Editor performance as I added more and more ASMDEF files. For things like adding a new c# script, the Editor log shows it's doing an Asset Import, like this:

Total AssetImport time: 20.854323s, AssetImport time: 15.353629s, Asset hashing: 0.000173s [0.6 KB, 3.150748 mb/s]

Before I added any ASMDEF files, that would take 3-4 seconds. Now it takes 20 seconds with about 35-40 ASMDEF files. Does anyone else experience this? It seems like a deal breaker in terms of using ASMDEFs, as it really kills the Editor performance. I tried clearing out my asset cache, but it doesn't have any effect.

 

Sharing my fix to (because I didn't see it anywhere on web, searched for 2 days):

Internal incremental compiler exception: Type initializer "ZeroMQ.lib.zmq" threw exception. (server log);

Unable to start the incremental compiler service:System.Exception: Subscribe exception: EAGAIN(11): Resource temporarily unavailable (unity log)

Environment: Windows 10, Unity 2018.1.9f1 (reproduced with 2018.2.14f1 too)

The fix: just installed VS 2017 and resolved the issue https://visualstudio.microsoft.com/ru/thank-you-downloading-visual-studio/?sku=Community&rel=15
Interesting, which part of VS resolved the issue... I have no issue on another pc, it does not have VS (only JetBrains Rider), but for example, it has MS Build Tools 2015

Shortest repro:
- using this guide https://unity3d.com/learn/tutorials/topics/scripting/introduction-ecs
- create empty project
- build settings -> c# level set to 4.x, restart
- minimize unity, replace Packages\manifest.json contents with:

Code (JavaScript):

1.         {
2.           "dependencies": {
3.             "com.unity.incrementalcompiler": "0.0.42-preview.1",
4.             "com.unity.entities": "0.0.12-preview.4"
5.           },
6.           "registry": "https://packages.unity.com",
7.             "testables": [
8.                 "com.unity.collections",
9.                 "com.unity.entities",
10.                 "com.unity.jobs"
11.             ]
12.         }

- maximize unity, wait resolve & import => got error
Note: it is reproduced on 0.0.42-preview.24 too

 

I am trying to use c# dynamics with the incremental compiler, but I keep getting this error:

error CS0656: Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'

I did some searching, and according to this stackoverflow post, to use dynamics with Roslyn you need to add a project reference to

Microsoft.CSharp.dll

. I tried doing this in my IDE and by editing msc.rsp, but the errors are still there. How do I properly add an assembly reference?

 

Hi @JimmyCushnie , I was discussing your issue with Nav Gupta. Did you have some example code that is failing that you can share here?

 

@ibyte for sure, here's some example code that causes CS0656 when the incremental compiler is installed:

Code (CSharp):

1. void Test()
2. {
3.     dynamic test = new List<string>();
4.     test.Add("test");
5. }

And here's the actual code I'm trying to use. Errors are on lines 68 and 188. (I know that code is a mess, cleaning it up is on my todo )

 

@JimmyCushnie Just to confirm for my test I am using Unity 2018.3.0b8 and Incremental Compiler 0.0.42-preview-2.4. Incremental compiler option shows up in preferences. I added your Test function to a script and called it in Start(). I don't see a CS0656 error. Will research a bit more. Would you confirm the Unity version you are using? Thanks

 

@ibyte I was using 2018.2.10f1. I just tried the example code in a fresh 2018.3.0b9 project, but I still get the error.

In the project window, right click click on the script and click "reimport". Is there still no error? If you install the incremental compiler after making the script, the error won't show up until you cause a reimport (either manually, like I described, or by editing the script).

 

Part of my editor log showing the reload and play session

 

@JimmyCushnie What Platform are you building to? I get the same error are you when I switch to iOS or WebGL as a build platform for example.

 

@ibyte I'm building for Windows. That news is alarming, though, as I had hoped to use this code in webGL.

On a whim, I tried it in 2019.1.0a8, and to my surprise it worked just fine. I'm reinstalling 2018.2 now to see if that fixes things.

 

@JimmyCushnie

https://docs.unity3d.com/Packages/com.unity.incrementalcompiler@0.0/manual/index.html

part way down the page - supported on Windows only

The very first post in the thread did you do step #4?

 

Unfortunately, the reinstall did not work. Still the only way I've gotten it to work is with 2019.1, and given that that's in alpha I'm not too comfortable using it for production...

Where do I find my editor log? I'd like to compare mine with yours.

 

@ibyte I thought the "supported on Windows only" referred to the editor, not generated binaries.

No I had no idea you were supposed to delete /ScriptAssemblies!!! I'm testing it now!

 

With the console tab selected, top right corner control for the Console window, Open Editor Log

 

@ibyte thanks.

Deleting ScriptAssemblies did not work. I even tried deleting the whole library/ folder, but the errors persist.

 

Could be. the location of the text is a little ambiguous. Hopefully if it is limited to windows it is because it is in preview status.

 

@JimmyCushnie Not sure if you tried a brand new project and followed all the steps in the first post. Note step 2 was already done.

 

I've finally fixed it holy cow!!!!!!!!!! Adding lots of keywords so that people searching can find it.

When using Unity's incremental Roslyn compiler, to add an assembly dll reference, which is necessary to use c# dynamics, you need to to the following:

1. Find the path of your Unity Editor installation
2. Go into the following subfolder: [Version of Unity]\Editor\Data\MonoBleedingEdge\lib\mono\4.7.1-api\Facades
3. Copy-paste a copy of the dll you want to use into that folder. To use dynamics you need Microsoft.CSharp.dll, which can be found at C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5.

Dependencies seem to be automatically sorted out; even though Microsoft.CSharp.dll has like 5000 dependencies, I was still able to use it without copy-pasting any of them.

Thank you very much for all your help @ibyte. I am SO relieved to finally have all this sorted out.

 

It's quite odd that I had to do this and you didn't, though. I wonder what's up with that.

 

@JimmyCushnie Glad to hear you got it sorted out. When I went review my directories I did not have the dll in Facades but it was one level up from that. It is still not clear to me the differences in our environments but glad we could be of some assistance.

We really appreciate you giving Unity Live Help Experts an opportunity to help you with your issues and hope you come back when you need help in the future.