Unity Incremental C# Compiler - deprecated

Which manifest file there are about 13 files in Unity...\Editor\Data sub-folders that contain the word manifest?

 

The local manifest file, in Packages/manifest.json
This Packages folder is a sibling of your Assets folder.

 

I think there may still be a spaces in path issue.

Code (CSharp):

1.  (0,0): GetAnalyzersFromCompilation threw an exception: System.ArgumentException: Illegal characters in path.
2.   at System.IO.Path.GetFileName (System.String path) [0x0001b] in <e1a80661d61443feb3dbdaac88eeb776>:0
3.   at UnityEditor.Compilation.CodeAnalyzerManager.GetAnalyzersFromCompilation (System.String assemblyFilename, System.String[] unityCompilerArguments) [0x0002e] in <50909ec437ba4fef93e6aebf9535f3b9>:0
4. System.Threading.ThreadHelper:ThreadStart()

With my project existing in "E:\Unity Projects\Project Name" on Windows, 2018.2.0b2

 

Just tried the compiler with the latest RC. Everything did work flawlessy for me.
It would be nice if there was a toggle to disable it, so we can do some comparison before/after.
Btw, are the settings explained anywhere?

 

Can confirm. Had the same issue. Removed all spaces in the project path. Solved.

 

Whenever I restart playback and double click on a console message it ask me to reload the solution in visual studio.
Am I the only one experiencing this?
I think there was the same problem on the unofficial incremental compiler, can't remember what they did to fix it.

 

I've just started using the incremental compiler 0.0.38 on Unity 2018.2.0b1 and it works well, I love the fast compile times. But the integration with Rider for c# 7.2 is not working so well because it no longer seems to set the correct language version in the csproj files. I tried version 0.0.30 first and I recall it was setting it correctly there.

Also Rider now gives me compiler messages for "Missing XML comment for public visible type or member ..." which I don't know how to disable. It's pointing me to this page but that doesn't help me much since I don't know what is setting the -doc compiler flag.

EDIT:
Actually I found the xml thing right after posting, I've looked before but I guess I didn't see it that time. The setting to disable the XML comment warning is in Settings > Editor > Inspection Settings > Inspection Severity > C# > "Missing XML comment for publicly visible type or member". I would have expected to be able to disable it from the context menu like any other warning but there you go.

 

OO! How do you do the 'GetComponent<> is used in an Update method' generated error message?

 

Any updates on this?
Or an answer to how to disable the unet module?

 

For now, I'm patching the DLL as I described in a previous reply. I'm not sure if there's another way.
It works in my case because I don't use UNet at all.

Here's the link to the reply: https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-2#post-3445211

 

@Dom_Laflamme
Tested on WebGL build, project compile end with success, but there is one error:
(0,0): Unable to start the incremental compiler service:System.Exception: Subscribe exception: EAGAIN(11): Resource temporarily unavailable
Then I keep getting those errors:
(0,0): Object reference not set to an instance of an object
Latest Compiler package (0.0.39version), Unity 2018.1, only C# code was:
var b = 0b1010_1011_1100_1101_1110_1111;

In log file i got this:

Code (CSharp):

1.  (0,0): Unable to start the incremental compiler service:System.Exception: Subscribe exception: EAGAIN(11): Resource temporarily unavailable
2. (0,0): Unable to start the incremental compiler service:System.Exception: Subscribe exception: EAGAIN(11): Resource temporarily unavailable

 

Got it working on Unity 2018.1.0f2 using 0.0.39-preview.1. My compile(and refresh) time decreased from 15 to 5 seconds (looks promising!)

I found the following issues:

1 - Unity is recreating the ".csproj" almost every time I change something in my code (I have 22 projects due to various assembly definition files so it's taking more than a minute to reload them)

2 - Double clicking console output does nothing (should take me to the corresponding line of code)

3 - I got the "Copying assembly from directory Temp to Library/ScriptAssemblies failed" error

 

I got the project refresh issues too, but not the console output thing. I think it's because you are not waiting for the solution to reload. After you let it reload you should be able to double click on the console and go to the line.

 

Works great, thanks~

Still, would've liked for this to be fixed officially since this patching process can't be source controlled :<

 

I have a makeshift solution using an AutoHotkey script and ildasm/ilasm. It reads txt files and patches accordingly. If you're on Windows, it might help.

If someone from Unity gives the ok, I can post the script here or in a github repository.

 

You really are a sugoi dev, aren't ya? XD

 

I don't think that was the problem. I did wait the solution to reload and the problem persisted. I also noticed that Unity is not even opening my script editor anymore.

Btw, I'm using VS Community 15.6.7. Just updated yesterday from 15.6.2 while I was configuring the Incremental Compiler so it might be related.

EDIT: Went back to the default compiler and the console double click works as expected again

EDIT2: Back once again to the incremental compiler and the console double click is working now

EDIT3: After a single file edit the console double click is not working again

 

I've been trying to use the incremental compiler in our project. It works, but compiling within visual studio does not work. I believe a few others had this problem but I did not see a resolution to that issue yet. I am on the preview 0.0.39. We are using some of the new HD render packages and those seem to be giving the errors in Visual studio. We have engineers who tend to hit "build" in VS to compile their changes quickly, so this is a workflow that I hope that we can get resolve. We are seeing errors like this:

18>------ Rebuild All started: Project: Assembly-CSharp-Editor, Configuration: Debug Any CPU ------

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\Assembly-CSharp-Editor-firstpass.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\Assembly-CSharp-firstpass.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\Assembly-CSharp.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\com.unity.postprocessing.Editor.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\com.unity.render-pipelines.core.Editor.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\com.unity.render-pipelines.high-defintion.Editor.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\com.unity.render-pipelines.lightweight.Editor.dll' could not be found

18>CSC : error CS0006: Metadata file 'D:\projects\XXX\testbed\Temp\bin\Debug\com.unity.render-pipelines.lightweight.Runtime.dll' could not be found

 

How does building in VS speeds up things for you guys?
Do you have a post-build routine that copies the built DLLs to the Library/ScriptAssemblies folder?

I'm getting compilation times of around 1 second with the current incremental compiler.
Still getting HUGE assembly reload times (over 15 seconds, sadly), but compilation is very fast.
Assembly reload times has been my main pain point with Unity for years now. It increases a bit worse than linearly with the number of scripts and serialized stuff.

Do you guys do something that makes this process faster by building in VS?

 

I've been using this extension to work on a code-first parametric modeling library I've been building for some years. I wasted tons of time wanting to build a syntax editor or a visual editor because the compile time just killed it for any reasonable usage.

The Incremental compiler completely fixed that issue, its so fast, I make an edit, go back into unity, it reloads and then I can regenerate my model.

 

Sugio, have you tried breaking your project into multiple assemblies using Assembly Definition files?

 

Oh yeah. It helped a lot. I love custom assemblies. Only missing feature is "partial" custom assemblies, so we don't have to mess around with the folder structure from vendor packages/assets.

What really kills assembly reloads is the serialize/deserialize phases. I can see in the profiller those eating most of the time (from 7-12s).

No matter if a single file assembly or your monolithic core assembly changed, Unity will kill the current domain, and reload it completely. This causes the serialization system to serialize (SerializeBackups) then de-serialize (DeserializeBackups) everything. The more serialized data you have, the longer this will take.

There's also some very expensive stuff running in high frequency LINQ queries. If you inspect the code from UnityEditor.AssetPostprocessingInternal and UnityEditor.Scripting.ScriptCompilation.EditorBuildRules you'll notice that there's quite a bit of string comparisons happening in LINQ queries. I've seem predicates with string comparisons being ran 200k times on assembly reloads and take a considerable amount of time. But there's only a few hundreds of comparisons, when this is cached.

I even went as far to patch some, and add some caching. But, since the reference source code from github doesn't produce usable assemblies, I have to do manual patching of the IL. This isn't ideal to quick test changes so I put it on hold for now. Still, I managed to shave 2-3 seconds with some rudimentary optimizations on those two classes (adding proper equality comparers, some dictionaries and early returns).


I'm really excited to see improvements on this side. There's an old report from a dev that worked on Ori about assembly reloads and entering playmode taking several minutes. At the very least, it isn't so bad now (but, still far from the ideal 500ms!)

---

Edit: below are two shots of the difference the naive caching does when reloading.
It saves about 2 seconds in a busy reload.

No caching


With naive caching and good equality comparers

 

Mainly it's about more instant feedback about warnings and errors and less friction to navigate to those problems. It's also habit. I do this all the time because of muscle memory. Make a change, hit F7. No need to switch find error in console double click, switch back, blah blah.

We have also seen the problems with project reloading. I have found a setting in the tools for unity that seems to help:



Whether this is a good solution or not, I don't know.

 

Ah, gotcha. Thanks!

 

I tried it out this morning, and I'm having a few issues:
1. Double clicking to access warnings from the console doesn't seem to be working
2. Visual Studio is doing way more project reloads than makes any sense
3. The [UsedImplicitly] attribute seems to be ignored (I'm getting warnings for fields that had been fine previously

 

I have it set to false, but it doesn't seem to do anything. Still ask to reload.

 

I was having a similar issue before it stopped working in VS. Check to see if the files are in the Temp directory. If they are try using a pre build event like

Code (CSharp):

1. copy "${ProjectDir}Temp\*.dll" "${TargerDir}"

This is from memory so the macros might be a little different.

 

It will ask and you can ignore. At least it won't reload automatically. I think that's a step forward

 

A while ago, I created a tool that uses the Visual Studio API to propagate the changes done to the project files. So, adding/removing/moving/renaming a file/folder would not trigger a solution reload. Instead, the Unity side would pass some info to a helper standalone executable, and this executable would communicate with Visual Studio so that VS itself would make the changes to each project, live. It was all done in a background worker, so both Unity and VS were never hogged.

Overall, despite being very fast, it was also very hard to work with, with all the edge cases and VS API itself being very brittle. I ended up giving up on the tool when JetBrains Rider arrived in early access. Never managed to go back to VS since then. I miss a lot of stuff, but this reloading madness was just too much.

 

On a 2018 project which is fairly large, none of the scripts on my gamobjects or prefabs are recognized. No console errors outside of the unet weaver stuff. Compiler console doesn't give any clue. I'm guessing that deleting the full Library folder might make it work, but I can't afford to waste half a day to find out.

 

If the UNet weaver error is triggered, compilation will completely fail and nothing will work. I recommend closing Unity in that case, and not saving anything, as I had serialized stuff breaking with that (noticed in source control and reverted).

Did you try patching the UNet weaver dll to test? I put instructions to do that a few posts before. PM me if you need help.
If you're not using UNet, it should have no ill effect on your project.

Also, before deleting the full library, delete just Library/ScriptAssemblies (with the editor closed). This will cause a full reocmpilation.

 

Ya I experienced the serialization failing also on a previous attempt, so I committed everything before this last one. Good to know it is unet weaver, I was thinking for some reason that it was just an annoyance thing.

 

This UNet issue is probably keeping a lot of people from trying this. The copying issue is probably to blame too, but it's a rare issue.

Even with that, I'm super excited with the direction they're taking on performance. It was about time.

 

I went to try this out today and got a unetweaver issue and just turned it back off.

 

These errors are also present on my end with 2018.1.0f2.

 

It's a great idea, and I can't wait for it, my compile times are currently a minute or so on the client side, so anytime I have to test something over and over while making changes is frustrating. This is one of the features I am most looking forward to, just needs to be ironed out a bit more. I will definitely be keeping an eye on this though.

 

I'm getting this error after running the API Updater:

Internal error: Recursion detected while updating scripts (assembly name: Assembly-CSharp.dll

Can anyone else confirm this?

 

Got that a few times too. Close Unity, delete the Library/ScriptAssemblies and open it again.
When it asks about updating your scripts, deny. It should work.

 

Works pretty good so far - the only thing that kills this for our project is the long "Hold on" duration after building a standalone player. It seems to be disabling the package for the build and then reenables it

 

Just use it during dev time, then turn it off to build? I wish I could do that, my compile times are around a minute+ , I would be happy to have much faster dev time and then just spend a few extra minutes turning it off to build, lol. I get a bunch of unetweaver errors and such when I try to use it at all.

 

Yes, that would work, unfortunately we have to build out our server instance for testing each time

 

Ah, I hear ya, I end up running multiple copies of Unity at the same time now because I was tired of having to keep doing that, lol.

 

Does the compiler have an effect on both Mono and IL2C++, or just Mono?

Edit to add: I am also experiencing the issue where paths with spaces in them cause errors.

 

This seems neat but please do not create any features that depend on this compiler. Many people like myself prepare and manage our projects externally from Unity's managed solution file. If major features are ever tied to this compiler then it will be a problem.

 

@Glader This is just a roslyn-based compiler with extra caching and code analysis, and will probably remain so. You can use C#7+ features, but you can use msbuild or anything else that can compile your code.


The thing that I'm uncertain about is the burst compiler. That's a super specialized compiler for the new job system and ECS (it generates highly optimized binaries for performance). I'm not sure how that'll work in your case.

But, as long as you don't need burst, using this incremental compiler during development should not alter your workflow (besides lower compile times!).

 

@Dom_Laflamme
Any new version coming soon? Would like to use this but the continuos project refresh is pretty annoying.

 

I am currently trying out JetBrains Rider instead of Visual Studio and have to say that it works very good even with the incremental compiler. The only real problem is that the incremental compiler (at least I think it's it) sets the LangVersion in the csproj files to 7, instead of 7.2. Many C# 7.2 features like "in parameters" are supported, but Rider shows errors when I use them, because the project is not set up to the correct LangVersion. Unfortunately even an AssetPostProcessor can not set the LangVersion, as it seems to be overwritten directly after they run. Would it be possible to make this value customizable or set it directly to 7.2? It's a minor issue, really, but it's rather annoying right now.

[Edit] Sorry, just saw that the same question was already asked further up. In that case: Is there an update on the issue?

 

I just started using Rider myself this week. It is fantastic. Once this compiler gets smoothed out they will be an awesome match.

 

Heyo, just chiming in that I'm also seeing this error:

Code (CSharp):

1.  (0,0): Unable to start the incremental compiler service:System.Exception: Subscribe exception: EAGAIN(35): Resource temporarily unavailable
2. System.Threading.ThreadHelper:ThreadStart()

as referenced by these other folks in these posts:
https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-3#post-3482483
https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-3#post-3486396

However, it's only happening on one of my Macs. Doesn't seem to happen on my Windows machine or my other macOS machine.

 

Incompatible with UNET.
My personal project is using Google ARCore with UNET.
And also the project of my company is using UNET as well.

Just saw that others are encountering this issue as well.
It seems that it's once saw in Mar, 28.
When will it be fixed?