C# 6.0

What do you guys think?

 

I think "Roslyn" requires .NET Framework 4.5 and Unity's Mono is restricted to .NET Framework 2.0/3.5. ... yes ?

I imagine this will lead to some discontent with Unity because C# 6.0 has some great features in development.

 

I hope, due to the cooperation between Microsoft and Mono to make the .NET Framework open source, that with Unity 6 or so the latest version of .NET will be implemented. Fingers crossed.

 

I think C# 6.0 is awesome, just like I thought C# 5.0 was awesome and C# 4.0 was awesome, but unfortunately Unity is still on the decade-old C# 3.0, and not even a full implementation at that.

 

Yeah I think 6.0 has some great new features. I really like the is null operator (?). Gonna make things much nicer.

 

Once IL2CPP is really ready for prime time and being used for all platforms we will almost certainly see a major .net version upgrade. However, mono is still necessarily currently to allow the editor to work on platforms like IOS. So, with mono always being behind, c# 6 features are highly unlikely anytime in the foreseeable future.

 

Mono's nowhere near as far behind as Unity always is. Mono already has a preview C# 6 compiler available. Keep in mind Microsoft's own C# 6 compiler hasn't officially released yet either.

 

http://forum.unity3d.com/threads/unity-c-6-0-compiler.314800/ no?
Or am I missing something - this is about official support? is it? or just getting it however....
I read all the posts, as usual, this only helped so much

 

Evidently not as far as it used to be. I haven't kept up as much on mono news.

 

Hmmmm, interesting. I'd be really hesitant to have my entire codebase reliant on an Asset Store plugin but I'd check it out. It's still not quite as good as having an actual Mono upgrade since it has to convert everything to .NET 2 IL, so it wouldn't be able to support async or dynamic. It would also be a pain getting Resharper to understand which parts of C# 6 were available and which weren't. But it's a good idea; I hope they succeed.

 

Hi everyone, I'm the developer of C# 6 compiler for Unity.

I'll try to answer some questions.

We're using Microsoft Roslyn compiler, and it runs independently from Unity (it's a standalone application). It's not bound to Unity's Mono platform. Roslyn is capable of producing .NET 3.5 code.

It's possible to use C# 6.0 in Unity, because language version is mainly independent from the runtime version. Almost all features of C# 6.0 are supported, except for Caller Information.

Mono MCS compiler doesn't yet support all of C# 6 features, that's why Roslyn is used in our tool.

Resharper support - we use Resharper for all of our development in-house. It works flawlessly with C# 6.0, we haven't yet encountered any issues. The compiler tool has also been extensively tested, and is able to compile huge codebases without any issues.

The tool doesn't interfere with the compilation process in any way. It simply redirects compilation requests from Unity to Roslyn, and adds a few command line arguments to target .NET 3.5.


We're offering a few free licenses of the tool this week, send me a PM for a free copy.

 

nice try, aprils fool

 

No he's serious. He posted a thread about it.

 

I'm already using it, enjoying string interpolation, `nameof` and “Elvis operator” `?.` for null propagation in monadic way. However, no `dynamic` via DLR; and no async/await since we're restricted to .NET 3.5.

But language C# 6.0 itself is NOT restricted to .NET vNext! You can target .NET 3.5; generated code is compatible with ancient CLR. You can decompile it with dotPeek and see, how actually C# 6.0 syntax sugar can be expressed in C# 3.0 terms. Except `dynamic` of course, and new classes in standard library.

Unfortunately, Unity Editor is stuck with old language and runtime. So we need to precompile our logic code to assembly and then use it as usual managed plugin. On the other hand, this separation gives as possibility to develop Unity agnostic library for core game logic and use it in context with not Unity at all: e.g. server side, or console runner, or automatic tests.

 

Not entirely true The tool we have developed enables developers to use C# 6.0 right within Unity, without resorting to third-party compilers.

 

no dynamic - true
no async/await - false
no caller information attributes - false

Async/await is a syntax sugar, a C# 5.0 compiler feature, not the CLR 4 feature. It just relies on some types that come with .Net Framework 4/4.5 base class library. However, these types are available under CLR 2.0 as well. Have a look at AsyncBridge, it's been there for three years already.

The same is true for caller information attributes and these attribute types are also included in AsyncBridge.

It looks like both async/await and caller information attributes work fine in Unity. I checked it yesterday using the standard MS C# 5.0 compiler.

The only restriction we have - we have to use CLR 2.0. I have no idea why Unity is stuck to the old Mono's compiler, while the modern Mono's C# compiler supports all the fancy language features and still can target CLR 2.0.

 

One word...

Xamarin

 

Thanks for the idea, I'll take a look at the AsyncBridge project, and will see if it's possible to integrate it into our Unity C# 6.0 compiler.

As for the older CLR used by Unity - looks like they're having some licensing issues with Xamarin. They have a license for the old version of Mono. Another difficulty with upgrading to a newer CLR lies in Unity using a custom version of Mono. It is not possible to simply swap the older version of Mono runtime with the newer one - Unity made lots of changes to the CLR. Theoretically it should be possible to merge the changes made by Unity into the newest Mono runtime (the sources are open, and available on GitHub), however this would require a tremendous amount of work.

 

There's no integration needed. It's just a couple of libraries you drop in your project and async/await and caller information attributes start working, if you use a decent compiler of course.

Unity already has a compiler that supports C# 5.0. It just doesn't use it.

Code (csharp):

1. H:\Program Files\Unity\Editor\Data\MonoBleedingEdge\lib\mono\4.5>mcs.exe -?
2.  
3. Mono C# compiler, Copyright 2001-2011 Novell, Inc., Copyright 2011-2012 Xamarin, Inc
4. mcs [options] source-files
5.    --about              About the Mono C# compiler
6. ...
7.    -langversion:TEXT    Specifies language version: ISO-1, ISO-2, 3, 4, 5, Default or Future
8. ...
9.    -sdk:VERSION         Specifies SDK version of referenced assemblies
10.                         VERSION can be one of: 2, 4, 4.5 (default) or a custom value
11. ...

 

Yeah, and why doesn't it use it?

Xamarin, the company that licenses Mono, charges to use it on embedded systems and other things (which unity wants to support):
http://xamarin.com/licensing

Xamarin wants more money than Unity is willing to pay to upgrade their license to the latest version.

 

Latest Mono runtime would be nice to have, but just switching the compiler is a big step forward.

Code (csharp):

1. H:\Program Files\Unity\Editor\Data\MonoBleedingEdge\lib\mono\4.5>mcs.exe --about
2. The Mono C# compiler is Copyright 2001-2011, Novell, Inc.
3.  
4. The compiler source code is released under the terms of the
5. MIT X11 or GNU GPL licenses
6.  
7. For more information on Mono, visit the project Web site
8.    http://www.mono-project.com
9.  
10. The compiler was written by Miguel de Icaza, Ravi Pratap, Martin Baulig, Marek Safar, Raja R Harinath, Atushi Enomoto
11.  

 

I tested this mcs.exe, works fine.

Code (CSharp):

1. using System;
2. using System.Runtime.CompilerServices;
3. using System.Threading.Tasks;
4. using UnityEngine;
5.  
6. public class Test : MonoBehaviour
7. {
8.     private async void Start()
9.     {
10.         Debug.Log("Hello, World! " + DateTime.Now);
11.         await TaskEx.Delay(3000);
12.         TestCallerInfo();
13.     }
14.  
15.     private void TestCallerInfo([CallerMemberName] string member = "", [CallerLineNumber] int line = 0)
16.     {
17.         Debug.Log("Caller: " + member + "\nLine: " + line + " " + DateTime.Now);
18.     }
19. }

 

Is it consistent across platforms though? I'm not sure CompilerServices is available across mobile platforms (though I could be wrong). Running in the editor and running on a device (or with IL2CPP for that matter) are not the same thing.

 

Yeah, I'd be interested to know if this works cross-platform.

 

From the AsyncBridge site:
"AsyncBridge lets you use the VS 11 C#5 compiler to write code that uses the async and await keywords, but to target .NET 4.0. It was published by Daniel Grunwald (from SharpDevelop) here."
Would this even work in Unity?

 

I have no firm answer to this, just thoughts:

1. If IL2CPP supports all the CLR 2.0 IL-instruction set, all CLR 2.0 assemblies should be supported.

2. System.Runtime.CompilerServices is just a namespace name, like any other. Nothing special about it.


3. At least it works in the editor and Windows standalone builds.

Yes, it works. There are two versions of AsyncBridge. One for CLR 2.0, another for CLR 4.0.

 

That's pretty awesome; with this and C#6 compiling, it makes Unity almost feel like something made in this decade!

 

Can anyone confirm its usage on mobiles? If not I'll try to test it on the weekend.

 

Unity C# 5.0 and 6.0 Integration Demo
https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration

It supports four compilers:
1. The stock one.
2. Mono C# 5.0 compiler that comes with Unity.
3. Mono C# 6.0 compiler from the Mono 4.0.0.
4. Roslyn C# 6.0 compiler.

There's no rocket science inside. Check the description on bitbucket.

--
Sorry, ilya_ca. Mine is free.

 

Even with this tool, no dynamic keyword I suspect? Just syntactic sugar is added?

 

Yep. You'll get everything (including async/await), except dynamic-related stuff.

 

Nice. I forgot to test if AsyncBridge works on mobiles. Any confirmation?

 

I tested only the editor and Windows standalone builds. I could test Andriod but I don't usually publish to it. Did it once just out of curiosity, but already forgot how to do it.

 

Added a bunch of C# 6.0 feature examples. Mono's 4.0.0 compiler fails one.

Code (CSharp):

1. var foo = new[] { 1, 2, 3 };

It thinks that foo?[0] is int, but it's int? or Nullable<int>.

 

It's not rocket science, but still requires a lot of effort to put it all together, and make it bug-free.

You blatantly stole someone else's idea, and made it free, wow! Молодец, земляк!

Anyways, we will continue developing the tool. No, it's not going to be free, we have expenses to make it all possible.

The next version will support null-propagation on Unity objects, will have AOP support (null guards, INotifyPropertyChanged, and many others), and will have Mac support.

 

Man, all ideas are floating in the air. I just wouldn't use such a hack until it were fully transparent and open source or officially supported by Unity Technologies itself.

Sooner or later a new version of Unity will bring a change to the compilation pipeline and my whole code base will break. I want to be able to fix it myself.

 

I added a simple GUI to the demo scene.

Running on Android:

 

So what is precisely the idea stolen? The fact that version and implementation of the runtime is not strictly bound to version and implementation of some language compiler due to CLI standard? Am I stealing someone's great idea while using Roslyn C# 6.0 compiler for generating “Unity-compatible” binaries?

Понаехали! Куда ни плюнь, везде рашн девелоперс. (Шутка.)

 

Just playing around with async/await.

Code (CSharp):

1. using System.Net;
2. using System.Threading.Tasks;
3. using UnityEngine;
4.  
5. public class DownloadDemo : MonoBehaviour
6. {
7.     private async void Start()
8.     {
9.         var someResult = await DownloadTest();
10.         Debug.Log(someResult);
11.     }
12.  
13.     private void Update()
14.     {
15.         transform.Rotate(0, 90 * Time.deltaTime, 0);
16.     }
17.  
18.     private async Task<int> DownloadTest()
19.     {
20.         var task1 = DownloadAsStringAsync("http://microsoft.com");
21.         var task2 = DownloadAsStringAsync("http://mono-project.com");
22.         var task3 = DownloadAsBytesAsync("http://netstorage.unity3d.com/unity/0b02744d4013/builtin_shaders-5.0.2f1.zip");
23.         await TaskEx.WhenAll(task1, task2, task3);
24.  
25.         return (task1.Result?.Length ?? 0) + (task2.Result?.Length ?? 0) + (task3.Result?.Length ?? 0);
26.     }
27.  
28.     private Task<string> DownloadAsStringAsync(string address)
29.     {
30.         var task = new Task<string>(() => new WebClient().DownloadString(address));
31.         task.Start(TaskScheduler.Default);
32.         return task;
33.     }
34.  
35.     private Task<byte[]> DownloadAsBytesAsync(string address)
36.     {
37.         var task = new Task<byte[]>(() => new WebClient().DownloadData(address));
38.         task.Start(TaskScheduler.Default);
39.         return task;
40.     }
41. }

 

I'm testing WebGL builds. It looks like il2cpp doesn't like exception filters and AsyncBridge libraries that bring us async/await and caller information attributes support.

 

http://blogs.unity3d.com/2015/05/13/il2cpp-internals-a-tour-of-generated-code

 

Still playing around with async. Here's an example of button on-click handler that uses coroutines:

Code (CSharp):

1. using System.Collections;
2. using UnityEngine;
3. using UnityEngine.UI;
4.  
5. public class DownloadGoogleLogoDemo : MonoBehaviour
6. {
7.     public RawImage rawImage;
8.     public Button button;
9.  
10.     public void ShowGoogleLogosCoroutine() // can be on-click handler
11.     {
12.         StartCoroutine(ShowGoogleLogosCoroutineInternal());
13.     }
14.  
15.     public IEnumerator ShowGoogleLogosCoroutineInternal() // can't be on-click handler
16.     {
17.         button.interactable = false;
18.  
19.         var texture = new Texture2D(1, 1);
20.         rawImage.texture = texture;
21.  
22.         for (int i = 1; i <= 11; i++)
23.         {
24.             yield return new WaitForSeconds(.5f);
25.             var www = new WWW($"http://www.google.com/images/srpr/logo{i}w.png");
26.             yield return www;
27.  
28.             texture.LoadImage(www.bytes);
29.             rawImage.SetNativeSize();
30.         }
31.  
32.         button.interactable = true;
33.     }
34. }

The same using async/await:

Code (CSharp):

1. using System.Collections;
2. using UnityEngine;
3. using UnityEngine.UI;
4.  
5. public class DownloadGoogleLogoDemo : MonoBehaviour
6. {
7.     public RawImage rawImage;
8.     public Button button;
9.  
10.     public async void ShowGoogleLogosAsync() // can be on-click handler
11.     {
12.         button.interactable = false;
13.  
14.         var texture = new Texture2D(1, 1);
15.         rawImage.texture = texture;
16.         for (int i = 1; i <= 11; i++)
17.         {
18.             await .5f;
19.             var png = await AsyncTools.DownloadAsBytesAsync($"http://www.google.com/images/srpr/logo{i}w.png");
20.  
21.             texture.LoadImage(png);
22.             rawImage.SetNativeSize();
23.         }
24.  
25.         button.interactable = true;
26.     }
27. }

 

How can i run a bit on main thread like Loom or Foundation.Tasks? Thanks.

Code (CSharp):

1. public static void Register(string email, string password)
2. {
3.     try
4.     {
5.         var user = new ParseUser() { Username = email, Email = email, Password = password };
6.         user.SignUpAsync().ContinueWith(t =>
7.         {
8.             if (t.IsFaulted || t.IsCanceled)
9.                 UnityTask.RunOnMain(() => RegisterFail(t.Exception));
10.             else
11.                 UnityTask.RunOnMain(RegisterSucceed);
12.         });
13.     }
14.     catch (Exception e)
15.     {
16.         RegisterFail(e);
17.     }
18. }

edit: i tried async / await Task.Run but it says Task does not contain a definition for GetAwaiter and i cannot even find TaskAwaiter? idk

 

Code (CSharp):

1.     private async void Start()
2.     {
3.         WhereAmI();
4.  
5.         var task = new Task<string>(
6.             () =>
7.             {
8.                 WhereAmI();
9.                 Thread.Sleep(1000);
10.                 return "some data";
11.             });
12.         task.Start();
13.  
14.         await task;
15.  
16.         WhereAmI();
17.         Debug.Log("Result: " + task.Result);
18.     }
19.  
20.     private void WhereAmI()
21.     {
22.         Debug.Log("");
23.         Debug.Log("thread id: " + Thread.CurrentThread.ManagedThreadId);
24.     }

Output:

There's one prerequisite however. You should have UnityScheduler prefab on your scene. If you don't , await won't return execution back to the main thread.

 

I've updated and reorganized my repository again - https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration

The demo project now contains two folders:

Demo folder contains just demo scripts and demo scenes. You can delete it.

AsyncTools folder contains:

1. AsyncBridge.Net35 and System.Threading libraries.
You'll need those if you want to use async/await feature in your scripts.

2. UnityScheduler script and prefab.
It contains custom implementations of System.Threading.Tasks.TaskScheduler and System.Threading.SynchronizationContext. You'll need an instance of this script to exist in your scenes, if you want to be able to return execution back to the main thread.

3. AsyncTools script.
It's just a set of helper methods, not necessary but useful.

--
@rakkarage, check ThreadPingPong demo

Spoiler: Script source

Code (CSharp):

1. using System.Threading;
2. using System.Threading.Tasks;
3. using UnityEngine;
4.  
5. internal class ThreadPingPong : MonoBehaviour
6. {
7.     private void WhereAmI()
8.     {
9.         var threadId = Thread.CurrentThread.ManagedThreadId;
10.         Debug.Log(threadId == 1 ? "main thread" : "background thread #" + threadId);
11.     }
12.  
13.     public async void AsyncAwaitDemo()
14.     {
15.         WhereAmI(); // main thread
16.  
17.         var task1 = new Task(WhereAmI); // background thread
18.         task1.Start(TaskScheduler.Default);
19.  
20.         var task2 = new Task(WhereAmI); // main thread
21.         task2.Start(UnityScheduler.MainThread);
22.  
23.         var task3 = new Task(WhereAmI); // background thread
24.         task3.Start(TaskScheduler.Default);
25.  
26.         // returns execution of asynchronous method to the main thread,
27.         // if it was originally called from the main thread
28.         await TaskEx.WhenAll(task1, task2, task3);
29.  
30.         WhereAmI(); // main thread
31.         Debug.Log("done");
32.     }
33.  
34.     public void TaskContinueWithDemo()
35.     {
36.         WhereAmI(); // main thread
37.  
38.         var originalTask = new Task(WhereAmI); // background thread
39.  
40.         var continuationTask1 = originalTask.ContinueWith(
41.             previousTask => WhereAmI(),
42.             UnityScheduler.MainThread); // main thread
43.  
44.         var continuationTask2 = continuationTask1.ContinueWith(
45.             previousTask => WhereAmI()); // background thread
46.  
47.         var continuationTask3 = continuationTask2.ContinueWith(
48.             previousTask => WhereAmI(),
49.             UnityScheduler.MainThread); // main thread
50.  
51.         var continuationTask4 = continuationTask3.ContinueWith(
52.             previousTask => WhereAmI()); // background thread
53.  
54.         originalTask.Start(TaskScheduler.Default);
55.     }
56. }

 

Thanks alexzzzz. Pretty awesome to finally use async/await as well as the C# 6 features at the same time.

Is Thread.CurrentThread.ManagedThreadId guaranteed to be 1 for the main thread and greater than 1 for all background threads on all platforms?

I'm asking because we weren't sure if we could depend on it for UniRX: https://github.com/neuecc/UniRx/issues/33#issuecomment-59631878

We saw in the Unity 4 editor ManagedThreadId was often 1, when we expected it to be a higher number after creating new threads. That behavior did not occur in builds, which made us doubt the reliability. Of course, could have been a Unity 4 bug.

 

No idea, really. It just happened to equal 1 every time I ran the tests (editor, standalone for windows and android).

Actually, it's not even guaranteed that every managed thread runs in a separate native thread on all platforms.

 

When I run it on Android it seems to have a problem with Parallel in the AsyncTest of the Language Features Demo:

Code (CSharp):

1. E/Unity   (17378):  Unable to find kernel32.dll
2. I/Unity   (17378):  thread id: 5
3. I/Unity   (17378):
4. I/Unity   (17378):  (Filename: ./artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 65)
5. I/Unity   (17378):
6. I/Unity   (17378):  DllNotFoundException: kernel32.dll
7. I/Unity   (17378):    at (wrapper managed-to-native) System.Threading.Platform:SwitchToThread ()
8. I/Unity   (17378):    at System.Threading.Platform.Yield () [0x00000] in <filename unknown>:0
9. I/Unity   (17378):    at System.Threading.ManualResetEventSlim.Wait (Int32 millisecondsTimeout, CancellationToken cancellationToken) [0x00000] in <filename unknown>:0
10. I/Unity   (17378):    at System.Threading.ManualResetEventSlim.Wait () [0x00000] in <filename unknown>:0
11. I/Unity   (17378):    at System.Threading.Tasks.Task.InternalRunSynchronously (System.Threading.Tasks.TaskScheduler scheduler) [0x00000] in <filename unknown>:0
12. I/Unity   (17378):  Rethrow as TaskSchedulerException: TaskSchedulerException_ctor_DefaultMessage
13. I/Unity   (17378):    at System.Threading.Tasks.Task.InternalRunSynchronously (System.Threading.Tasks.TaskScheduler scheduler) [0x00000] in <filename unknown>:0
14. I/Unity   (17378):    at System.Threading.Tasks.Task.RunSynchronously (System.Threading.Tasks.TaskScheduler scheduler) [0x00000] in <filename unknown>:0
15. I/Unity   (17378):    at System.Threading.Tasks.Parallel.ForWorker[Object] (Int32 fromInclusive, Int32 toExclusive, System.Thr

Aside from that it's looking good.

 

Task Parallel Library hasn't been included in CoreFX yet. I'll try to backport it to Unity when its sources become available.

 

Ah, so you added the Parallel test after you posted the Android screenshot? Then it's all great. Well, aside from the IL2CPP issues but we depend on Unity for that.