Mono Upgrade Future plans for the Mono runtime upgrade

I have filed an issue #901443 on this.

Is there any quick workaround how to suppress referencing `nunit.framework.dll`, which redefines `System.Lazy<T>`?

 

Will the CoRoutine would be switched to async/await?

 

What exact version of .Net is supported: .Net 4.6, 4.6.1 or 4.6.2?
In case of 4.6.2 support, i think it should be possible to use C#7 in VS2017, compile dll and use it in Unity 2017.1?

EDIT: Just checked, it's working fine. Compiled DLL using C#7 features working fine in editor.

 

@JoshPeterson I was running into this issue in 5.6, this thread has more info on a possible workaround: https://forum.unity3d.com/threads/d...ts-with-system-collections-concurrent.464168/

 

I guess we are talking about different things, which maybe add to the confusion. I am trying to create a class library in Visual Studio that I intend to consume in a Unity project.

In the Unity 2017.1 editor, I can set the scripting runtime version to 4.6:



In Visual Studio 2015, with VS Tools for Unity 3.1 installed, I can however only create a class library using any of the Unity .NET 3.5 based frameworks:



This is still true even if I create a new C# project in VS and/or opening the Unity project as a C# project from the Unity editor.

Instead of setting the Target Framework of my class library e.g. to "Unity 3.5 .net full Base Class Libraries", will it work "flawlessly" with the experimental Unity engine if I set it e.g. to ".NET Framework 4.6"?

 

Sorry, still a forum novice Now they should be visible, I hope.

 

@JoshPeterson OK, thanks! I will try it out and let you know how it goes. Eventually, will you ship something like "Unity 4.6 .net full Base Class Libraries" for Visual Studio?

 

Where is the best place to report problems concerning this? I have one Mono 4.5 class library which references two Portable Class Libraries (profile 111, .NET Framework 4.5, Windows 8+, Windows Phone 8.1, Xamarin), and I get this error when trying to run a behavior script consuming these libraries:

TypeLoadException: Error Loading class
System.RuntimeType.GetMethodsByName (System.String name, System.Reflection.BindingFlags bindingAttr, System.Boolean ignoreCase, System.RuntimeType reflectedType) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/ReferenceSources/RuntimeType.cs:481)
System.RuntimeType.GetMethodCandidates (System.String name, System.Reflection.BindingFlags bindingAttr, System.Reflection.CallingConventions callConv, System.Type[] types, System.Boolean allowPrefixLookup) (at /Users/builduser/buildslave/mono/build/mcs/class/referencesource/mscorlib/system/rttype.cs:2825)
System.RuntimeType.GetMethods (System.Reflection.BindingFlags bindingAttr) (at /Users/builduser/buildslave/mono/build/mcs/class/referencesource/mscorlib/system/rttype.cs:3078)
UnityEditor.Build.BuildPipelineInterfaces.InitializeBuildCallbacks (UnityEditor.Build.BuildPipelineInterfaces+BuildCallbacks findFlags) (at C:/buildslave/unity/build/Editor/Mono/BuildPipeline/BuildPipelineInterfaces.cs:182)​

 

@JoshPeterson Thanks again. I have filed a bug report, it has ID 902662.

 

Thanks! I'd rather even placed it to another namespace. There is no point in mimicing existence of class from higher version of Framework in lower version. If you redefine it as `SomeInternalPseudoSystem.Lazy<T>` it will still be unbroken when compiling for higher Framework, since there still will not be any name clashes between “true” `System.Lazy<T>` and reimplemented “back-port” `SomeInternalPseudoSystem.Lazy<T>`.

 

I know you guys have talked about this on another thread, but I can't wait for an upgraded garbage collector, lol. (it's going to come after the .net upgrade right?)

 

@JoshPeterson will Bug #716908 ever be addressed?

 

I think we could just upbringing StartCoroutine into await pattern. Wherever it's yield return then it could became await

 

@JoshPeterson Also, since we have taste 2017 beta for such time. Did we could ensure that unity 2017 actual release be supported .net 4.6?

If so I could start writing my code in C#6 in beta while waiting for 2017 release

 

@JoshPeterson

So with the annoncement of .Net Standard 2.0 preview for .net core at Build, it looks like the standard is pretty close to being finalized. Are the plans still limited to .net 4.6 + C#6 for the Unity 2017.1 release or is an upgrade already being worked on? Quite curious to see when we can be using bleeding edge C# 7 in our development workflow

 

What would an AOT-friendly implementation entail?

I code that won't work on AOT platforms would not compile rather than crash consoles, that would be a major upgrade!

 

Thanks for the in-depth explanation, love this openness about the progress!

If I understand correctly, C#7 is currently not supported by the latest official Mono runtime/compiler yet? Is the plan to wait until Mono implements support for it? You mention Roslyn, does that mean you will switch to the Roslyn compiler as a next step instead of waiting for the mono compiler support?

 

Thanks for the detailed clarification again! Love it that you guys are working on this

 

For now I just hope that C#6 would be sure tobe a next non-beta release

 

@JoshPeterson
Can I have installed Unity beta version side by side with stable?

 

I usually rename the ProgramFilesFolder property in the installer to Unity5.X.XfX or Unity5.X.XpX or whatever it is the installer title says about the version.

 

Please don't remove coroutines. They're very useful for temporary jobs that need to operate in sync with the frame rate without having to spawn an entire behaviour with an update function. (I often use them for controlling visual movement in a turn based game, for example.)

 

@salmelo Task and async/await is a standardized way C# do the coroutine. It actually the same concept but better. Just unity don't update C# version too long so we can't use that great feature of C# 5

 

Indeed. It would be better to just use Tasks and async/await. You can share existing code for a problem with non-Unity applications/libs without going to the trouble of porting it as close as possible for Unity(if that's possible at all). It's more cohesive/consistent that way.

Also like Thaina mentioned, they are standardized, which means they are more robust and by now a more powerful tool,considering the variety of frameworks that use it.

 

Task and async/await are not the same thing as coroutines tho. Task is for asynchronous operations, something currently very difficult to achieve in Unity without Task and async/await. Coroutines are a way of running code in lock-step with the frame rate, the same way that you would in a behaviours Update() method. While they can be used as a sort of psuedo asynchronous operation, that's not what they're actually for (imo) and the fact that there now exists a better way to do asynchronous operations is no reason to get rid of them. That's like saying "now that we have an amazing new screwdriver, we can get rid of hammers entirely."

As an example; I often use them for components who need to do something, such as move to a specific point, but won't be doing it all of the time. The component will have a public function to tell it that it needs to go to a new location wherein it will start a coroutine to handle the frame-by-frame movement. When it gets there the coroutine ends. Without coroutines you'd have to handle the movement in Update or LateUpdate, which would work, but now every moving piece is having Update called every frame, even when 90% of the time it won't be doing anything. I realize superfluous updates aren't the greatest performance hit without very large numbers, but even so I'd rather avoid them. I also like to compartmentalize the motion into a single function.

I'm sure there's a way you could achieve that behavior with async/await but frankly that would be a bit overkill. I don't need multithreading to do the job of a coroutine. And that's my real point: I'm very excited to be getting a new screwdriver, but I still like my hammer too.

 

Tasks are not multithreading. they can be scheduled in another thread, but they are just a better syntax to do the same thing a Coroutine does.

i.e. one could do "await new WaitForSeconds(x)" in an async method instead of "yield return new WaitForSeconds(x)" in a coroutine, and Unity could make the two statements behave exactly the same (they need to have the yield instructions implement the "Awaiter pattern" for them to be awaitable)

what Tasks can do better than Coroutines are:
1) returning values: "var result = await InnerTask()" - with coroutines, you have to either pass a lambda or use a field
2) handling exceptions:
- if a Task throws an exception, it gets catched and retrown when you await - then you can handle it
- if a Coroutine throws an exception, Unity and prints it, but there is no propagation - any other coroutine that is waiting for it is never resumed
- you can put a try-catch block around an await, but not around a yield (you can yield in a try-finally, but Unity doesn't call the finally block if it gets interrupted someway - e.g. StopCoroutine)

 

@salmelo The lockstep part isn't something Coroutines can do inherently. It's just something that Unity devs created on top of the base for you to use in tandem with the rest of Unity's code.Doesn't mean they won't provide the same with Tasks and async/await.

@JoshPeterson can enlighten us more on this issue.

 

We don't pretend that tomorrow Unity removes Coroutines.

But I think that Unity should encourage and teach people on using async/await instead so we can make a better transition supported by Unity.

Also many developers like me want to be able to reuse class libraries outside of Unity that aren't tied to Unity API.

That's why on other threads I asked if Unity would replace part of it's API with System.Numerics namespace.