Unity Incremental C# Compiler - deprecated

You can try the alpha version of my plugin, which tries to set the highest possible version of C # in the projects and the recipe file.
https://github.com/zoon/C-Sharp-Latest-for-Unity/releases

 

I wrote a batch file (win) to speed up the installation of C # 7.3 into new releases of "com.unity.incrementalcompiler". You just need a nuget in your path.
https://gist.github.com/zoon/d35a0777bd83d2971a1ec10ecff2c060

Code (CSharp):

1. @rem update-unity-compiler.cmd
2. @rem start in */com.unity.incrementalcompiler@X.Y.ZZ folder
3. @echo off
4.  
5. @rem NOTE: FIND.EXE can clash with git/msys/cygwin's find
6. for %%a in (%ComSpec%) do set __system=%%~dpa
7. %__system%FIND.EXE /i "com.unity.incrementalcompiler" package.json 1> NUL
8. if %errorlevel% neq 0 goto :not_found
9.  
10. nuget install Microsoft.Net.Compilers -verbosity quiet
11. if %errorlevel% neq 0 goto :nuget_error
12.  
13. for /F %%D in ('dir /b Microsoft.Net.Compilers*') do set __roslyn_dir=%%D
14. if not defined __roslyn_dir goto :unknown_error
15.  
16. xcopy %__roslyn_dir%\tools\*.dll .bin\ /u /r /y 1> NUL
17. if %errorlevel% neq 0 goto :xcopy_error
18.  
19. echo Success:
20. echo   %__roslyn_dir% installed
21. goto :cleanup
22.  
23. :not_found
24. echo ERROR: com.unity.incrementalcompiler package is not here.
25. goto :eof
26.  
27. :nuget_error
28. echo ERROR: NuGet error (do you have it installed?).
29. goto :cleanup
30.  
31. :xcopy_error
32. echo ERROR: Error copying files, try to close all Unity instances.
33. goto :cleanup
34.  
35. :unknown_error
36. echo ERROR: unknown
37. goto :cleanup
38.  
39. :cleanup
40. if defined __roslyn_dir rmdir %__roslyn_dir% /s /q
41. set __system=
42. set __roslyn_dir=
43.  
44. :eof

 

Hello,

How can I access this feature?

 

My double clicking is also not working, mine was with VSCode.

 

slightly off topic question. I want to take advantage of the c# 7.0 features for my library, but at the same time keep it working on different version of Unity that may not support c# 7. The obvious solution would be to use .net standard library, but I can only build a .net standard dll outside Unity right? This means that I cannot use any UnityEngine feature in it, while I have some I need. Thoughts?

 

I had a go at dowloading the package - not very succeful i am afraid...
The old style black window for mono.exe opened up and started to execute, but never did close and I got a rather vague message in the console : "(0,0): One or more errors occurred."
All of my scripts attached to components have yellow exclamation triangles stating "The associated script can not be loadad. Please fix any compile errors and assign a valid script"

I am on compiler 0.0.41, Unity 2018.1, Win 10,

Any ideas on how to proceed would be highly appreciated.

br /mattias

 

It's undoubtedly the Unet Weaver issue, mentioned in previous posts. I got the feeling the developer didn't really have a good solution for it, that it might require changes in some other area he has no control over or something. Because he was pushing out other updates while not fixing this, and this one is a hard blocker.

 

Where to remove the spaces in path? I don't understand the error and frustrated as F*** and dunno what to do. Can you please explain what should i do?

 

The place with the extra spaces in it, bro. You just remove them and you are good to go!

 

You can, by adding a reference to the Unity DLLs

 

Hi, everyone.

My editor is close forcefully some time when I press the play button in the editor.
Is anyone have the same problem?

 

Hi all,

using https://gist.github.com/chuckbergeron/245e0f5906c89f7d01c02eeb052e1b04 to test compile times.

Spotted the incremental compiler on package manager and gave it a whirl. Total compile times being reported are around 7-8 seconds which is a bit too long for comfort.

I do notice that the actual spinny cog animation in the corner of Unity stops animating within 1-2 seconds and freezes for the remainder of the time (around an additional 5 seconds) - it feels as if something else is inflating compile times.

Does anyone have any insights?

Edit1: it seems potentially being Assembly Reloading?

Haven't the foggiest how to get that down.

Edit2: I had a thought serialisation might be taking up time and it does, but only a second or so.

Edit3: Profiling entering playmode reveals a long spike from HDRP roughly matching that time. It was an unexpected source and might well be related, within Reload Assemblies on profiler (editor).

 

Thank you. It makes sense but it's still not ideal to me. I was wondering, since unity needs to compile the DLLs separately, isn't there a way to tell unity to compile only a specific dll with usafe mode enabled?

 

Hi,

I received a "(0,0): One or more errors occurred." message when trying to use the incremental compiler (see post https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-4#post-3500667). It was suggested this was related to the Unet Weaver thing. I hardly understand what the unet weaver is (i am quite sure i dont use it in my game - unless some asset uses it) and I am not deeply into all of the good juicy tech stuff but in the quest for the promise of reduced compile times I nevertheless decided to try your advice to edit the process method (i dont have a clue what i am doing really - but merely following your instructions )

My question is: in the "edit method" part .- which edit do i choose? there is an Edit Method and an Edit Method (c#). And follow on question - how do i actually select (in edit method) or code (in edit method c#) to make it return true.

br /mattias

 

current version 0.0.38

https://github.com/Unity-Technologi...es/blob/master/Samples/Packages/manifest.json

how to know what is last version ?

 

Remove the manifest mod in thread, it is on package manager normally now, under the All tab, currently 0.0.42-preview.1 - this is the best way to keep up to date.

Other stuff:

Did anyone find a solution to double clicking an error (not debug log) -> VS line number?
Currently, logging takes me to the correct line but errors do not respond. Without this functionality, I spend more time hunting for line numbers than incremental compilation saves...

 

I notice that I can't go to the line number when the program did not compile more that when I got runtime error. Suggesting that incremental compiler mess with the .pdb or something constantly and makes you unable to jump before everything compiled successfully? (But sometimes I can't jump even at runtime error, weird)

 

I have this problem all the time even without the incremental compiler. 95% of the time it just ends up showing something like this :

Class.Method() <e1a80661d61443feb3dbdaac88eeb776>:0

 

Rough benchmarks

(times in seconds)
baseline (current project)
8.7

no editor folders
8.7

remove all own code
8.2

no art folders
8.1

remove rewired
6.4

remove probuilder (unity package manager)
6.2

remove progrids (unity package manager)
6.1

remove textmesh pro (unity package manager)
5.9

remove hdrp (unity package manager)
5.6

remove srp core (unity package manager)
3.5

baseline new scene - with a single default unity c# new file
3.3


install incremental compiler (note: this has greater effect if used with more source files!)
3.0

Observations seem like my own project and files are irrelivant and most of my sitting around
is Unity's fault + asset store. 2018.2b4

The numbers were recorded with https://gist.github.com/chuckbergeron/245e0f5906c89f7d01c02eeb052e1b04 and each test was done using a standard Create-> C# file, where I added and removed a space and saved it each time. It's not especially scientific but sufficed to demonstrate user pain from Unity itself.

I was pretty shocked because when you have a long term project you expect compile times to increase. What you really don't expect, is for that to be mostly Unity's fault. I did notice that if I install incremental compiler much sooner, obviously it has a greater effect, so it's not the compilation we're worrying about any more but sub optimal asmdefs or reloading.

I can live without the final bits of asset store and have gained some nice improvements trimming what I could. What I can't survive without, are all the native Unity packages we've been using. What the heck am I supposed to do with 5 seconds of Unity-induced thumb twiddling?

 

Kinda crazy. More so considering all those plugins should be compiled once since you never touch them again, right? That's the point if the IC?

Inboticed the dev hasn't replied since end if March.. uh oh.. maybe this has been silently shelved for now?

 

@Prodigga - I don't think this has been shelved per-se, but it's likely UT is getting all-hands-on-deck ready for Unite Berlin. Many devs are likely to be heads down trying to hit deadlines and won't have time to interact with the community. The package started showing up in the Package Manager quite recently, and the incremental compiler package does get up update every few weeks. That said, it'd be good to hear what the status is on the inside, since unlike the Input System repo we don't have a window into the internal pacing of this package or what's currently on the roadmap.

 

Yeah same as others have expressed... The incremental compiler isn't doing much for our well progressed project. Most of the compilation time seems to be Unity dealing with various serialization. I often have to wait 15-20 seconds, even though the code itself compiles in a couple seconds for me. It's starting to become unbearable to test code changes now and I'm somewhat at a loss of what to do.

 

Hi, when I try to install the latest version with the package manager in Unity 2018.1.0f2, I start getting hundreds of errors from some of my scripts and scripts from the asset store:

error CS0246: The type or namespace name xxxxxx could not be found (are you missing a using directive or an assembly reference?)

error CS0103: The name xxxxxx does not exist in the current context

Even though visual studio tells me there are no issues it's like Unity can't see the scripts...

Any idea why this may be happening? Did I do anything wrong?

 

Did you close unity, delete your ScriptAssemblies folder and then open your project?

 

Yes, I don't understand why this happens with some of the scripts. It did not throw errors with the stuff in the "3D with Extras" samples. But the moment I dropped some assets from another project it broke. Many VRTK scripts and a few of my own custom ones (with rather normal code). If I remove the compiler everything goes back to normal...

 

Weird. Well would you mind posting the full errors? IS there a reason you need to blank out asset store product names?

 

Blank out? I put xxxx because I have 600+ errors and there's nothing particularly useful or special about the contents, it's just the directory they're stored in (correct as far as I could tell ), and the name of the script. Some of the errors come from my own scripts, some from VRTK, SteamVR, OVR,etc. It just feels generally random.

Anyway, I'll try it out again later so I can post the errors but I'm a bit busy with work today. Don't think there's going to be anything specially useful though. They look like errors when you have forgotten to add a using directive (like using UnityEngine) but the scripts are fine, and work fine the moment I remove the compiler.

 

Oi solved it by upgrading the compiler to i think version .41 . Thanks bro

 

See, I knew it, bro. Glad we got that worked out.

 

Hi, I will be installing the latest beta today (or 2018.2.0b5 once it gets published), so I have to ask, is C# 7.2 support also present in Unity 2018.2.0b4? ETA for C# 7.3 support? Thanks.

 

Anyone? Also, does it support Span<T>?

 

I am using C#7.2 right now in that version (private protected, default, ref returns, discards, etc.)

It does not show up by default, but I heard you must install System.Memory NuGet manually to get them to show up in System namespace?

 

Also the problem with .csproj generated with Unity Incremental Compiler is that <LangVersion>7</LangVersion> instead of 7.2 and VSCode (Omnisharp) complains about all sorts of invalid operations where it actually compiles fine. Anyone has any workaround for this?

 

Thanks for replying. What about c# 7.3? Is it supported?

 

Thanks Hippocoder for stressing this point again.

I feel like I've ranted too much about this now (multiple bug reports, forum posts, conversations at Unite, conversations with enterprise support...) but this is all because of how AssemblyReload just doesn't scale well - O(n) with project size. Now that unity is pushing more and more stuff to C# this problem is becoming worse and worse. Every reload uses code that essentially does stuff like:

initializeOnLoadTypes = GetAllTypes().Where(t => t.GetAttribute(InitializeOnLoad))

For each type of attribute, callback method etc. It's no wonder you see reload times drop off that much after removing SRP + HDRP + ProBuilder + ProGrids + Rewired + Textmesh pro - that's more code than you'll likely ever write your own. It's a totally reasonable set of packages though, so it really feels like we need a solution here.

Again this is incremenal compiler is amazing work in a great direction, but... some unity folks acknowledging the problems with the Assembly reloads would make my week

 

@Joachim_Ante @pvloon It's the priority because 0.5s is going further and further way now with domain/assembly reload. Please advise us, thank you.

 

I tried just now and this compiles. Does it means 7.3 is supported? (Incremental compiler 0.042-preview.1)

 

For C#7.3 you can install latest Roslyn into incremental compiler + you need some plumbing for mcs.rsp/*.csproj and Visual Studio 15.7.1+.
Wrote a couple of helpers a few days back:
https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-4#post-3498855
https://forum.unity.com/threads/unity-incremental-c-compiler.523993/page-4#post-3498835

 

https://github.com/zoon/C-Sharp-Latest-for-Unity/

 

Indeed. It has gone to ridiculous levels for us. Here is the profiler after I created a new script.


37 seconds... And I'm using the incremental compiler. It's incredibly frustrating.

And deleting a script reveals a ridiculous amount of GC calls and file processing. This is on a high performance 1GB/s SDD as well.


Nearly 2 million GC.Alloc calls just from deleting a script. There must be a better way to handle script creation/deletion than processing every asset in the project again.

 

That does seem like it would add up... but wouldn't Unity have already optimised this case?

 

@GabrieleUnity, maybe u can find someone to revisit assembly reloading codebase to improve this area. I would like to see this assembly reloading will become as a package just like C# incremental compiler.

 

That's a reasonably assumption, but as far as I can tell, not a true assumption :/

As mentioned a few pages back this class:

https://github.com/Unity-Technologi...ripting/ScriptCompilation/EditorBuildRules.cs

Does 13K string comparisons, 100kb of garbage, on an empty project taking over 400ms, scaling O(n) with project size.





This is the main class to look for types and such:

https://github.com/Unity-Technologi...6c1ddcc9f1705/Editor/Mono/EditorAssemblies.cs

Entirely brute force reflection for every call. Eg this class:

https://github.com/Unity-Technologi...bfffb5994a3/Editor/Mono/AssetPostprocessor.cs

GetMeshProcessVersions runs every assembly reload and takes >300ms on an empty project, scaling O(n) with every type you add.



75K calls to reflection API's to check subclasses on an empty project.


This class does some of the attribute reflection heavy lifting:

https://github.com/Unity-Technologi...f1705/Runtime/Export/AttributeHelperEngine.cs



1000 attribute reflection calls on an empty project, scaling O(n) again.

The larger your project gets the more cases like this start to pop up. If you read over these code snippets they don't exactly feel very optimized - and I don't understand either why unity is not prioritizing optimizing these classes more. Even with broadly the same approach as today, it feels to me that with a little caching of reflection data, and refactoring the code to be a little more perf friendly, these parts could be an order of magnitude faster.

Or hey, maybe one day that C# source code license will land and the community will take care of it

 

Hello, For a test project I use the file mcs.rsp to add references to some libs, With the incremental compiler say that the file don't exist and can't load the dll.

 

Follow the instructions and everything works fine. Neither warnings no errors on the editor. However, when compiling with Visual Studio the following error code appears:

Any ideas?

 

@LordDarkon76 try full path, ie:

Code (CSharp):

1.  
2. -r:C:\Program Files\Unity\Hub\Editor\2018.1.0f2\Editor\Data\NetStandard\compat\2.0.0\shims\netfx\System.ComponentModel.Composition.dll
3.  

 

Unity Preferences -> Compiler -> Enable building from IDE - try turn it off.

 

@z00n: building works from the editor even with that property on. And I can switch to Play mode with no problem. The thing is that I cannot attach VS debugger and Play. If the property is on, the error appears on VS, and when it is off, I get "... Please use language version 7.2 or greater."

 

If you use CSharpLatest plugin, and get "Please use language version 7.2 or greater." in MSVS - just do:
Assets -> OpenC# Project one more time. Incremental compiler rewrites project files after you change its preferences.

 

@z00n: it did not work. The workaround was to open Assembly-CSharp.csproj and manually set:

  <PropertyGroup>

    <LangVersion>7.3</LangVersion>

  </PropertyGroup>

EDIT: the same has to be done on every project file created with assembly definitions.