C# 6.0

CSharp60Support.dll is an editor extension so place it inside any Editor folder.

PS
If it won't help immediately, restart the editor.

 

It worked when I deleted the other CSharp60Support.dll (root and asset folders) and only had one in Assets/Editor/

 

System.Threading.Platform.Yield() was calling SwitchThread() from kernel32.dll. I have patched System.Threading.dll using ILSpy+Reflexil to simulate the same behavior without calling any platform-specific functions.

I didn't test on Android yet, but the same error on Mac OS X has gone.

Check the patched versions of System.Threading.dll and AsyncBridge.Net35.dll on Bitbucket.

 

Android build runs fine now. 10 consecutive launches - no errors.

IL2CPP no longer fails to process AsyncBridge.Net35.dll, which means that iOS builds might also work but I have no iOS devices to test on.

 

News:

1. Unity 4 support for both Windows and Mac.

If you use Unity 4 on Mac, you'll need to download and install Mono from http://www.mono-project.com/download. This is due to Unity 4's mono runtime being too old to run the latest mcs.exe.

2. System.Threading.dll patched again.

The first attempt to patch System.Threading.dll caused issues with Resharper. Everything worked fine except Resharper refusing to load the library and highlighting half of my code in red.

3. Added new "Cross-Platform Test" scene to the demo project.

It has a script that explicitly calls System.Threading.Platform.Yield() so you could easily check if this method actually works on the platform you target.

 

Hello im getting this error

Code (CSharp):

1.  
2. Unhandled Exception: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
3.  
4.   at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)
5.  
6.   at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0
7.  
8.   at Mono.CSharp.RootNamespace.ComputeNamespaces (System.Reflection.Assembly assembly, System.Type extensionType) [0x00000] in <filename unknown>:0
9.  
10.   at Mono.CSharp.RootNamespace.ComputeNamespace (Mono.CSharp.CompilerContext ctx, System.Type extensionType) [0x00000] in <filename unknown>:0
11.  
12.   at Mono.CSharp.GlobalRootNamespace.ComputeNamespaces (Mono.CSharp.CompilerContext ctx) [0x00000] in <filename unknown>:0
13.  
14.   at Mono.CSharp.Driver.LoadReferences () [0x00000] in <filename unknown>:0
15.  
16.   at Mono.CSharp.Driver.Compile () [0x00000] in <filename unknown>:0
17.  
18.   at Mono.CSharp.Driver.Main (System.String[] args) [0x00000] in <filename unknown>:0
19.  
20. The following assembly referenced from F:\CaelDominis\github_1\Assets\Roslyn\System.Reflection.Metadata.dll could not be loaded:
21.      Assembly:   System.Runtime    (assemblyref_index=0)
22.      Version:    4.0.0.0
23.      Public Key: b03f5f7f11d50a3a
24. The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (F:\CaelDominis\github_1\Assets\Roslyn\).
25.  
26. Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
27. Missing method .ctor in assembly F:\CaelDominis\github_1\Assets\Roslyn\System.Reflection.Metadata.dll, type System.Reflection.AssemblyMetadataAttribute
28. Can't find custom attr constructor image: F:\CaelDominis\github_1\Assets\Roslyn\System.Reflection.Metadata.dll mtoken: 0x0a00001f
29. Missing method .ctor in assembly F:\CaelDominis\github_1\Assets\Roslyn\Mono.Cecil.dll, type System.Runtime.CompilerServices.ExtensionAttribute
30. Can't find custom attr constructor image: F:\CaelDominis\github_1\Assets\Roslyn\Mono.Cecil.dll mtoken: 0x0a00009e
31. The following assembly referenced from F:\CaelDominis\github_1\Assets\Roslyn\Microsoft.CodeAnalysis.CSharp.dll could not be loaded:
32.      Assembly:   System.Runtime    (assemblyref_index=0)
33.      Version:    4.0.0.0
34.      Public Key: b03f5f7f11d50a3a
35. The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (F:\CaelDominis\github_1\Assets\Roslyn\).
36.  
37. Missing method .ctor in assembly F:\CaelDominis\github_1\Assets\Roslyn\Microsoft.CodeAnalysis.CSharp.dll, type System.Reflection.AssemblyInformationalVersionAttribute
38. Can't find custom attr constructor image: F:\CaelDominis\github_1\Assets\Roslyn\Microsoft.CodeAnalysis.CSharp.dll mtoken: 0x0a00000a
39. The following assembly referenced from F:\CaelDominis\github_1\Assets\Roslyn\System.Collections.Immutable.dll could not be loaded:
40.     Assembly:   System.Runtime    (assemblyref_index=0)
41.     Version:    4.0.0.0
42.     Public Key: b03f5f7f11d50a3a
43. The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (F:\CaelDominis\github_1\Assets\Roslyn\).
44.  
45. Missing method .ctor in assembly F:\CaelDominis\github_1\Assets\Roslyn\System.Collections.Immutable.dll, type System.CLSCompliantAttribute
46. Can't find custom attr constructor image: F:\CaelDominis\github_1\Assets\Roslyn\System.Collections.Immutable.dll mtoken: 0x0a000078
47. The following assembly referenced from F:\CaelDominis\github_1\Assets\Roslyn\Microsoft.CodeAnalysis.dll could not be loaded:
48.      Assembly:   System.Runtime    (assemblyref_index=0)
49.      Version:    4.0.0.0
50.      Public Key: b03f5f7f11d50a3a
51. The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (F:\CaelDominis\github_1\Assets\Roslyn\).
52.  
53. Missing method .ctor in assembly F:\CaelDominis\github_1\Assets\Roslyn\Microsoft.CodeAnalysis.dll, type System.Reflection.AssemblyInformationalVersionAttribute
54. Can't find custom attr constructor image: F:\CaelDominis\github_1\Assets\Roslyn\Microsoft.CodeAnalysis.dll mtoken: 0x0a00000a
55.  

 

Move Roslyn folder out of Assets and put it to your project's root.

 

Thanks alexzzzz for your work on this!

Question: no chance code contracts work with this, because they require a later CLR version, right?

 

Hi. Thanks for amazing tool

How can I write something like this?

Code (CSharp):

1. public async void Start()
2.     {
3.         //Do something in MainThread
4.         await AsyncTools.GoToWorker();
5.  
6.         //Do something in worker thread
7.  
8.         await AsyncTools.GoToMain();
9.  
10.         //Do sometihng in Main Thread
11.     }

 

I'm not sure they require CLR4, but have no idea how to make them work.

Right now you can't. I have to think about it.

 

Anyone else having issues with using this in 5.3?

 

@Thomas Mountainborn you have your build target set to Unity Web Player, switch it back to Windows/OSX/Linux

 

I just accidentally installed WebPlayer support instead of Windows support and got the same error.

It looks like Unity runs the compiler process under the same Mono profile that the current target platform uses. In case of WebPlayer it means that the compiler has no access to many file IO functions.

 

Check the latest commit from the experimental branch. There are two new methods in AsyncTools: ToMainThread() and ToThreadPool().

ThreadPingPong scene has two new buttons that demonstrate this way of switching threads.

Code (CSharp):

1.     private static async Task TestContextSwitch()
2.     {
3.         AsyncTools.WhereAmI("1");
4.  
5.         await AsyncTools.ToThreadPool();
6.         AsyncTools.WhereAmI("2");
7.  
8.         await AsyncTools.ToMainThread();
9.         AsyncTools.WhereAmI("3");
10.  
11.         await AsyncTools.ToThreadPool();
12.         AsyncTools.WhereAmI("4");
13.  
14.         await AsyncTools.ToMainThread();
15.         AsyncTools.WhereAmI("5");
16.  
17.         await 1;
18.  
19.         await AsyncTools.ToMainThread();
20.         AsyncTools.WhereAmI("6");
21.     }
22.  

If TestContextSwitch() is called from the main thread it works as expected:

Code (csharp):

1. Launched from the main thread...
2. 1: main thread, frame 15061
3. 2: background thread #2
4. 3: main thread, frame 15062
5. 4: background thread #3
6. 5: main thread, frame 15063
7. 6: main thread, frame 15124
8. done

But if it's called from a background thread like this

Code (CSharp):

1.         Debug.Log("Launched from a background thread...");
2.         var task = new Task(async () => await TestContextSwitch());
3.         task.Start(UnityScheduler.ThreadPoolScheduler);
4.         await task;
5.         Debug.Log("done");
6.  

it prints "done" way too early. I don't know why yet.

Code (csharp):

1. Launched from a background thread...
2. 1: background thread #4
3. 2: background thread #4
4. 3: main thread, frame 55
5. 4: background thread #2
6. done
7. 5: main thread, frame 55
8. 6: main thread, frame 117

 

Well, now I know why. I have two embedded tasks and I have to use double await:

Code (CSharp):

1.         Debug.Log("Launched from a background thread...");
2.         var task = new Task<Task>(async () => await TestContextSwitch());
3.         task.Start(UnityScheduler.ThreadPoolScheduler);
4.         await await task;
5.         Debug.Log("done");
6.  

Works fine now.

 

Recently I tried to add F# support to the editor, just for no reason other than curiosity. I failed. As far as I understand, the compilation process works as follows:

1. The editor takes all the MonoScript assets it can find inside the project and groups them by their extensions: .cs, .js, .boo.
2. Then it iterates through its list of registered compilers, checks what extensions they support, and feeds them the groups of script files according to the extensions.

I can add a new F#/VB/whatever compiler to the list, but I have no idea how to convert .fs/.vb files into MonoScript assets. There's no way we can manually create an instance of MonoScript type.

 

As a huge VB fan, I'm quite interested in this, I'd like to help if I can. Can you explain the challenge a bit more @alexzzzz ?

Merry Christmas!

 

Cool

Thanks

 

Right now I'm already not sure I need MonoScripts at all and not sure I clearly understand what preparations Unity does before launching the compiler. It looks like a half of the actions is done on native side, and in managed code there are many places where cs, js and boo extensions are hardcoded.

 

Another challenge for VB (that you can't fix) is that Unity isn't CLS compliant in their naming conventions. This requires some workarounds in VB code when accessing certain methods.

 

I can modify execution context switch this way:

Code (CSharp):

1.         await AsyncTools.ToThreadPool();
2.  
3.         await AsyncTools.ToUpdate();
4.  
5.         await AsyncTools.ToLateUpdate();
6.  
7.         await AsyncTools.ToFixedUpdate();

Will it be useful?

 

I Think Yes.

We often need to wait until LateUpdate to do something
So other must be useful too

 

Hmm... While AsyncTools.ToUpdate() and others were easy to implement, but their usage in the current state may cause counterintuitive effects. Consider the following:

Code (CSharp):

1. async void Foo()
2. {
3.     await AsyncTools.ToThreadPool();
4.     // We are in some background thread.
5.  
6.     await 1; // Wait for one second.
7.     // We are still in a background thread, not necessary the same one but that's ok.
8.  
9.     await AsyncTools.ToUpdate();
10.     // We are in the main thread in the Update queue/fiber/subthread/don't know
11.     // how to call it.
12.  
13.     await 1; // Wait for one second.
14.     // Since the main thread has SynchronizationContext set, after the await we are back
15.     // where we were (in the main thread), but who knows in which queue, it can be any.
16.     // In my tests I tend to land in LateUpdate.
17.  
18.     await AsyncTools.ToUpdate();
19.     // We are in the main thread, but this time it's the Update queue indeed.
20. }

In order to fix this nonintuitive behavior, I'll have to introduce three different synchronization contexts (for Update, LateUpdate and FixedUpdate) instead of a single one just for the main thread.

 

Thank you for this! I'm guessing I can use stuff like thread parallel library using this?

Also a quick question alexzzzz. Do you plan on continuing with your minecraft-like engine? It was so cool.

 

Would a VB project (DLL) that works in Unity be helpful to you?

When I open the C# Solution in VS 2015 from Unity, I add a VB project to that solution from a special template that is specially configured to work with Unity. There are tweaks that have to be done to such projects that control compilation to a DLL that Unity can swallow.

 

@alexzzzz,
This is totally neat, and I'm loving C#6.

However, if I put a `using static ` in any `MonoBehaviour`-derived script, the Editor then erroneously considers it to be a runtime script, and I can't attach it to any `GameObject`s in my scene.

Thoughts?

 

Done!

AsyncTools.ToMainThread() behaves as ToUpdate() but marked obsolete.

@IASEnvy
Can you show an example script?

 

Yep, you can use Tasks, Concurrent collections and Parallel LINQ. But since I use an ancient version of Task Parallel Library, the API is a bit different from what it is now in the .Net world. For example, you have to write task.Start() instead of task.Run(), or TaskEx.Delay(...) instead of Task.Delay(...).

I doubt it. It became overcomplicated and I lost my understanding of how things work there.

 

Awesome!

If you don't plan on continuing it could you put it on your bitbucket or something. I would love to play around with it.

 

1. I've reorganized the folders once more to reduce the mess and to simplify installation. All the parts, scattered around the project's root, moved to root/CSharp60Support/ folder.

2. smcs.exe has been renamed to CSharpCompilerWrapper.exe. It no longer makes sense to keep its original name.

3. Its Visual Studio project has been refactored since it looked like a mess. Looks a bit cleaner now.

4. Since AsyncTools.ToMainThread() was split into ToUpdate(), ToLateUpdate() and ToFixedUpdate(), I have also split UnityScheduler.MainThreadScheduler into

- UpdateScheduler
- LateUpdateScheduler
- FixedUpdateScheduler

So, now it's possible to run tasks in whatever context you need.

Code (CSharp):

1. AsyncTools.WhereAmI("inside Update");
2.  
3. var task = new Task(() => AsyncTools.WhereAmI("inside LateUpdate"));
4. task.Start(UnityScheduler.LateUpdateScheduler);
5.  
6. await task.ContinueWith(prevTask => AsyncTools.WhereAmI("inside FixedUpdate"),
7.                         UnityScheduler.FixedUpdateScheduler);
8.  
9. AsyncTools.WhereAmI("inside Update");
10.  

 

Have there been any updates on the debugging issue? The docs mention an issue with crashes, but I was wondering if it's an occasional crash, or certain scripts just breaking it altogether

 

It's an occasional Unity crash while you are debugging in Visual Studio. Everything may work fine until the editor suddenly crashes.

I don't know how to reproduce this issue for sure. I just tried and Unity crashed. Then I tried again and it didn't. Then a couple more times and it also didn't crash. Maybe, the first crash was unrelated, I'm not sure.

 

The problem is, I can't make a seamless integration, so the users could just place .vb scripts in Assets and they would be automatically compiled like .cs or .js scripts. Even with all the possible hacks VB won't become a first-class citizen in Unity, and the workflow won't be any better than just having a separate VB project and compiling it to a .dll directly inside Assets folder.

 

Would you be able to articulate what Unity would need to do to make VB a "first-class citizen"?

 

@alexzzzz,

If I have a class with some static methods that I want to use, but it's in some faraway namespace:

Code (CSharp):

1.  
2. namespace MyEngine.StuffThatLogs.StuffThatLogsGeneric {
3.     public class Logger {
4.         public static void Log(string s) =>
5.             Debug.Log(s);
6.     }
7. }
8.  

then the `using static MyEngine....Logger;` syntax works great, and in my code, I can simply call `Log(s)`.

Code (CSharp):

1.  
2. using static MyEngine.StuffThatLogs.StuffThatLogsGeneric.Logger;
3.  
4. public class MyScript : MonoBehaviour {
5.    
6.     public string myName => "Jerry"; // fancy readonly property, thanks C#6!
7.  
8.     void Awake() => Log(myName);
9. }
10.  

And this works fine, complies, etc., however, if I have that `using static` anywhere, something goes wrong somewhere, and the Editor no longer considers it eligible to be dragged onto GameObjects as a component.

I have a more complicated inheritance tree, and at first I wondered if I broke something, and that my classes were in fact not inheriting from MonoBehaviour. I checked: they are, and when I remove the `using static`, it works fine (I just then have to type out the full namespace, which is icky).

The two cases the Editor gives me are "It doesn't inherit from MonoBehaviour", or "The name of the file isn't the same as the class's name". Neither of which are true, of course, but nevertheless, Unity thinks that any C# source file which has a `using static ...;` in it is a runtime script that cannot be attached.

 

1. Unity should import .vb files as MonoScript assets. Otherwise, no drag-n-drop.

2. It should automatically trigger recompilation when .vb files change. It should be done by Unity, so that it would know that some compilation is in progress and wouldn't let user to play the scene.

3. It should add VB references to C# and UnityScript projects and vice versa. It can be done only by the editor itself. See the attached dependency scheme and imagine there are 4 more rectangles there for VB (and 4 more for Boo).

 

@IASEnvy
I can't reproduce the issue. Could you try to make a simple repro project?

 

@alexzzzz, this is about as simple as my example, and causes the issue.
I'm running on OS X, El Capitan, and the error occurs using the unity package you provided on a fresh project, with these two in it.

The image shows the editor message.

If you still don't get the error, maybe it's platform specific?

 

I thought that probably Mono compiler caused it, but with the files you've provided, I see the same problem on Windows using Roslyn.

 

It seems that 'using static' is not compatible with namespaces. It's a Unity "bug". The shortest repro script:

Code (CSharp):

1. using UnityEngine;
2. using static UnityEngine.Mathf;
3.  
4. namespace Foo
5. {
6.     public class Bar : MonoBehaviour
7.     {
8.     }
9. }

 

Ok, good! (Well, not good, but it's a place to start!)

So, another example:

If I derive a class (called... `MyDerivedClass`) from `MyClass`, and `MyDerivedClass` doesn't have any `using static` declarations, it's just fine, even if it's in a namespace.

I don't really know how this works behind the scenes, but I'd imagine that some internal representation is being mangled somehow, e.g., the editor expects the name to match some nonsense string, and MyClass.cs doesn't match it?

Edit: out of sheer curiosity, I just pasted the fully qualified name of the type into the filename, to no avail. *shrugs* worth a shot.

 

A probable explanation:

1. Unity parses each .cs file looking for a class named exactly as the file, and derived from MonoBehaviour or ScriptableObject. If it founds one, it uses it later when you drag-n-drop.

2. For parsing C# sources Unity uses an old version of NRefactory that doesn't understand C# 6 syntax and fails to correctly parse 'using static' pattern.

 

@alexzzzz, scripts which use other uniquely C#6 syntax features work fine, so I'm not sure, but IDK how it works.

If I were truly desperate to use this syntax, I could name things "_MyClass" and then derive an empty class with the correct name such that the `using static` was in the other file...

but that would be awful. (=

Thanks!

 

The issue is not limited to 'using static':

Code (CSharp):

1. using UnityEngine;
2.  
3. namespace Foo
4. {
5.     class Bar : MonoBehaviour { } // Ok
6.  
7.     class Baz
8.     {
9.         object Qux1 => null;
10.         object Qux2 { get; } = null;
11.     }
12. }

Code (CSharp):

1. using UnityEngine;
2.  
3. namespace Foo
4. {
5.     class Baz
6.     {
7.         object Qux1 => null;
8.         object Qux2 { get; } = null;
9.     }
10.  
11.     class Bar : MonoBehaviour { } // No MonoBehaviour scripts in the file...
12. }

Code (CSharp):

1. using UnityEngine;
2.  
3. class Baz
4. {
5.         object Qux1 => null;
6.         object Qux2 { get; } = null;
7. }
8.  
9. class Bar : MonoBehaviour { } // Ok

I guess, the rule should be "If namespaces are used, don't use any C# 6 syntax before MonoBehaviour declarations".

 

I see. It terminates once it finds the eponymous class definition.

I presume this is why `using static` is the only one which causes this, as it must be at the top of a file.

 

Hi! Thanks for the great tool.

I'm having noticeably longer compile times when using your wrapper -- most noticeable when I press "Play" in the editor and have to wait. Is this a known issue? Is there a way to fix it?

 

Does the "compilation in progress" icon continues to roll all that time?


Usually Roslyn is a bit slower than the Mono's compiler. On my project (3 assemblies, ~35000 raw lines of code) it's like 8 seconds vs 5 seconds.

However, sometimes the compilation icon rolls for too long, ~30 seconds or more. And it looks like nothing is happening and Unity is just waiting for something.
- I don't remember whether this happened before using the alternative compiler.
- I don't know how to reproduce it for sure to start looking for a solution. It just happens from time to time.

 

i tries understanding the whole thread, but i have one basic question...

will this functionality, just allow recognition of code base, or enable me in using class library compiled with support only for say .net 4.0+??

there i quite a few 3rd party library that we miss out on, because unity does not support libraries compiled with anything above .net 3.5

 

No, libraries compiled for .net 4.0+ still can't be used.