Unity Incremental C# Compiler - deprecated

This bug is on Unity's side, they write LangVersion 7 instead of 7.2 into the csproj file. Apparently that's by intent? See bug report: https://youtrack.jetbrains.com/issue/RIDER-18053. Rider has a workaround - if you go to (in Unity) File->Preferences->Rider, there's an option to override the lang version Rider thinks Unity's using.

 

Thanks for the quick reply!

I will try doing that again (using the Rider preferences override to 7.2) which I had already tried once but maybe Unity crashing lost that setting.

Additionally, I will note that the RIDER-18053 bug mentions that the 7 vs 7.2 thing was fixed in 0.0.42-preview.16, and I'm on .18 - so maybe it was unfixed or maybe it was never actually fixed.

Cheers

 

I got your sample to work -- took some fiddling though:
Open in Unity, open in Rider, get plugin installed, go back to Unity, set Preferences...


Install Incremental Compiler 0.0.42 in Package Manager ...

Set "Player Settings" ...


Restart Unity
Go into Assets - > Sync C# Project


Finally both Rider and Unity are happy, runs in Editor anyway. At multiple points one or the other would claim an error like you posted.

 

BTW, if stuff with Rider + Unity isn't working as expected, submit an issue (or a PR) to their plugin repo:
https://github.com/JetBrains/resharper-unity

The JetBrains guys are super responsive and helpful. Such a nice change from fighting with MonoDevelop or Visual Studio Unity plugins.

 

I've just tried compiler, awesome!
The problem is that when built to android, application loads slower. When i've tried to use modern library like that one https://github.com/louthy/language-ext, it added a whole minute to loading. Is it expected?

 

Still no luck with .19 (same unet weaver error)

 

The recent versions of the plugin write <DocumentationFile> tags to the csproj-files, and my VS starts blaming me for not having XML comments for all publicly visible types or members. It's quite annoying.

 

IncrementalCompiler 0.0.42-preview19

When trying to build for UWP, NETFX_CORE is not defined. Whereas UNITY_WSA seems to be defined even in editor. Is there any similar define I can use that is only enabled in UWP?

 

While I agree that's not desired default behaviour I sure could use the odd gentle poke to comment, even on a one-person project you will thank yourself later.

 

I just patched the plugin and renamed <DocumentationFile> tag into <StupidDocumentationFile>

 

Same thing is happening for me with LanguageExt.Core dll, compilation time practically doubled.

 

Sorry, I didn't follow the whole thread, so probably my naive question is already answered somewhere here.

How can I enable C# 7.2 (and even better 7.3) in Unity 2018.2.4? For now compilation fails with message
“error CS1644: Feature `readonly structs' cannot be used because it is not part of the C# 6.0 language specification”

How to make Unity generate <LangVersion>7.2</LangVersion> in csproj?

/cc @Dom_Laflamme

 

@Qbit86 - if you have Jetbrains Rider you can set an override for the csproj files via it's options in the Unity preferences menu. There's several posts earlier in the thread detailing using VS.

 

The steps are (kudos to @PedroGV and @SugoiDev):
1. Install CSharpLatest plugin to the project: https://github.com/zoon/C-Sharp-Latest-for-Unity/releases
2. Deactivate building from IDE: "Unity Preferences -> Compiler -> Enable building from IDE -> Off"
3. Update incremental compiler to C# 7.3: https://gist.github.com/zoon/d35a0777bd83d2971a1ec10ecff2c060

P.S. Rider can have some issues with setting C# version; as a solution they provide some pieces of CSharpLatest:
https://gist.github.com/van800/875ce55eaf88d65b105d010d7b38a8d4

 

Hi
Have problem with Assets/mcs.rsp file. I use it to add reference to System.Net.Http.dll.

Content of file is:
-r:System.Net.Http.dll

Incremental compiler can't find this dll, it works only if I specify absolute path to assembly. Absolute path is not an option because if you work in team where some works on Windows and some MacOS, obviously paths will be different.

It would be great if it will be fixed!
Or maybe there is some other ways to make it works.

 

For us it seems like the UnetWeaver issue is finally resolved? deleting ScriptAssemblies and using the latest preview packages of everything relevant and 2018.2.5 has resulted in successful builds

 

@Dom_Laflamme Is there any #define directive for Roslyn? It's useful for stuff like this:

Code (CSharp):

1. #if ENABLE_ROSLYN
2.     ref var v = ref entry[i];
3. #else
4.     var v = entry[i];
5. #endif

 

Ref locals and returns are indeed C# 7.0 feature: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/ref-returns (If you are using them, at some point you may also want to use “ref local reassignment”, which is C# 7.3 feature.) And Roslyn is just implementation of these features.

You can always send private message to addressee, if you really don't want someone to quote your post. Nothing to complain about if it is posted in public forum.

 

How did you do this ?

 

If you using Roslyn, but compile to c# 6, this example will not working. Roslyn != c# 7.

 

And if required, I'll combine directives with the one that is related to the C# version.

You don't know all the details of a project that we are working on, and cases where we need such directive, but you draw parallels between the specific compiler and the C# version.

 

Unity staff are the best source to respond to @nxrighthere in this case.

 

So far i now, Roslyn will be built in in 2018.3, maybe the only default c# compiler (or experimental and the default in 2019). At this point an make a compiler directive no sense.

 

Enough. Don't be thread banned @ everyone possible that next crosses my line of sight with petty nonsense.

 

Latest IncrementalCompiler version does not even create IncrementalCompiler folder. ScriptableAssembly is created instead.

 

Very nice thank you. I tried ILSpy but wasn't able to find a matching constant.

 

What incremental Compiler does when it does nothing?
Constant 2-3 % cpu use. Even if almost empty scene is not running.

 

So I tried the new Incremental Compiler and right from the start it made iteration time much longer, not shorter as advertised.

Steps without IC:
1. Update script1.cs in VS.
2. Alt-Tab to Unity, wait 5-10 seconds to "unfreeze" and recompile.
3. I only see warnings about the scripts I just modified in the console which is neat.
4. Double-click on script2.cs which brings me to VS with 1-2 second delay.

Steps with IC:
1. Update script1.cs in VS.
2. Alt-Tab to Unity, the same 5-10 second wait.
3. I see warnings from every single cs file in project, including the third-party assets. This is a deal-breaker on it's own. I don't care about the code in project that I didn't write and don't ever plan to modify (like Unity's Standard Assets which are filled with such warnings).
4. Double-click on script2.cs which brings to VS, which starts to unload and reload every project in solution. This takes additional 5-10 seconds and happens on every iteration.

In the end I don't see why anyone would want to use this for normal Unity development. I guess I'm missing some other benefits...

 

This alone has forced our studio to purchase Rider licenses because Visual Studio is completely and utterly unusable. I brought it up earlier but no one replied.

If your project has a lot of assembly definitions like ours does, it can take anywhere from 1-2 minutes every time you double click on a script in unity. This absolutely destroys prodictivity. For me it was quicker to end task visual studio and relaunch it from scratch by double clicking a script. Doing it this way seemed to about the whole 'unload/reload" cycle, and just opened up relatively quickly (5-10 seconds, but that has always been the case for me with cold launching visual studio).

Microsoft will be loosing a lot of developers to this! Our studio of 4 is out and we've already swapped to rider which does not exhibit this issue.

 

While this is true, I simply either using VS to navigate scripts, or opening via any explorer, outside Unity.
I don't get it, where this such tremendous lag comes from. but that is beyond the scope of Incremental Compiler, since I had same issue, before I even knew, what is ECS about.

 

Have you tried to use VS Code with plugins instead? I heard it must be faster than VS.

 

We did not have these issues before Increment Compiler.

Also, yes, navigating the scripts using visual studio is fine, but I have been using unity for 5-6 years now, and it is a big part of my workflow to open a script in the project window (double click script), in the inspector window (double click components script) and through the console (double click an error/warning/log). All of these operations trigger a 1-2 minute wait, and at least in our studio, we all do these things frequently. And not being able to do any of that is silly. If I am looking at a component on a GameObject and I want to change it's behavior, I naturally double click on the component to bring it up in visual studio for editing. It is such a waste of time tabbing to visual studio and relocating the script there. With Rider (and I presume with VSCode?) there is no wait. It just opens the script immediately. Just as Visual Studio did before we added Incremental Compiler to our project.

No, I have not. I make heavy use of resharper, and Rider basically has resharper baked in, so my workflow doesn't have to change that much. To be clear I just happened to try Rider first because we were already using Resharper. I don't mean to come off as "Microsoft sux!". I really really like(d) my visual studio and that is the only reason I am so vocal about it. I want it back.

 

I would be a bit careful here on a potential claim.
I don't know much of technical aspect of integration VS to Unity, but it may be, that Unity rather than MS has actually issue here. And since they are both collaborating, it even may be, they both failing on that matter.

This is interesting, since I read that people had similar lag issues in past, as well as myself, with many assembly files, or assets +VS. And many of probably didn't even knew, what ECS is. So naturally without entities or Compiler.
Atm. I don't have many assembly files in my ECS project, so is hard to judge. At least until then.

 

Microsoft has another issue with 32-bitness of VS, while JetBrains seem to overcome this limitation in Rider (but not in VS+ReSharper).

 

I've had bouts of the editor not popping to front, no matter which editor I had set to open files. It could very well be a strange issue with Unity itself, which accidentally is fixed by switching editor.

 

Hi!
Can not make it work - getting error

Code (CSharp):

1. Unity.Compiler.Client.InvokeCompiler Exception:System.AggregateException: One or more errors occurred. ---> System.InvalidOperationException: There is an error in XML document (1457, 57). ---> System.Xml.XmlException: '.', hexadecimal value 0x00, is an invalid character. Line 1457, position 57.
2.  

full
https://gist.github.com/dimmduh/08e71985ae8850b9b6663cdd12b4b9ed

tried removed fodler in library after install, restarted unity.

 

What has worked for me:

• Ensure you got latest Unity.
• Then remove all, but not asset folders.
• Open project.
• Install Entities (in my case was prev 11)
• Install Compiler
• Install Burst
• Reimport Project packages
• Restart Unity

 

Does incremental compiler support building for UWP? I was not able to get it working. But my primary issue is that incremental compiler doesn't recognize ENABLE_WINMD_SUPPORT or the WINDOWS_UWP directive.

 

What is the future of the incremental compiler, since the Roslyn compiler in 2018.3 is apparently server-based? https://forum.unity.com/threads/httpclient.460748/page-2#post-3668035

Also, does the package offer any advantages (apart from the possible performance boost), compared to the compiler shipped by default?

 

Please make a video of how the incremental compiler should work. I installed it, but it still compiles all solutions 20-30 seconds. Although it was said about 500ms.

 

The target is 500ms
Currently its a good step in the right direction however.
I've found that splitting my code into multiple assembly definitions per feature improve my compile times.

 

Can you elaborate how to do this? Thank you!

 

For starters have a look at the entry in the manual, I think it should explain all you need to know
https://docs.unity3d.com/Manual/ScriptCompilationAssemblyDefinitionFiles.html

 

More than assembly definition, is important location of scripts. For example you shouldn't keep them in resources folder.
Assembly definition for many cases (not all) has increased, or barely improved compilation performance. You can find quite few issue topics on that, around forum.

 

I'm getting a bug when using this with the Visual Studio debugger: every variable used in a local function is unavailable. It says they're not in scope. For example:

Code (CSharp):

1.     void Start ()
2.     {
3.         int x = 0;
4.         int y = 0;
5.         void Test()
6.         {
7.             x++;
8.         }
9.         Debug.Log("Breakpoint here");
10.     }

I can't inspect the variable x, but I can inspect y. This doesn't happen in a normal, non-Unity C# project. I'm using Unity 2018.2.7f1 and Visual Studio Community 2017. Has anyone had this issue before? I've tried reinstalling Visual Studio and trying this on a new Unity project.

Thanks.

EDIT: Adding a screenshot for clarification:

 

I broke the project into assembly definitions.
I change 1 file, it detects its change, compiles its assembler. And then it compiles all assemblies. As a result, the compilation also takes 25 seconds.

 

same error here!

 

I'm getting Warning 1591 on most of my classes, which is: "Missing XML comment for publicly visible type or member." In Visual Studio, I can suppress it in the project settings, but it seems like the settings keep getting reset every so often. Is there a way to change the default project settings?

 

Very nice feature and I hope it improves with time.
However I believe that having a library asset that compiles independently will hugely reduce compile time and will also encourage modular library management.

While assembly definition files achieve that somehow, it has its down falls, and it only supports Unity 2017.3+

I have created an open source asset called 'Lightning Fast Compilation and Module Management for Unity' that addresses
You can get it from bitbucket or asset store.
It's still in beta and a lot of features are yet to be added, so testing and feedback is greatly encouraged.
Once this asset becomes better it can change how assets in the asset store are distributed and how unity developers manage their game project.
My vision in this asset is to make scripts of big game projects manageable with less frustrating compile times.

Please check the documentation and tutorials for more information.