Mono Upgrade Future plans for the Mono runtime upgrade

According to Unity Docs and some discussions I found: nope.

 

Please make safe! Please wake up and hit their backs! Ow! Please make carefully! Hackers are very clever because they are lucky to hack Unity's Editor.

Because Github user Harry ( Cra0zy ) blames me about consternation of Mono mkbundle - If they use hxE, Hex Editor or Reserve engineering can unpack bundled mono applications. How do you protect Unity's Editor executable?
I don't like they're commenced. I feel scared if hackers can read our built games.... I am very shocked because it is not safer than assemblies. I wish we have high-protected bundle executable of Unity's Editor and We wish we have built-in mkbundle-like GUI builder for Game files with embedded managed built game launcher... Thanks!

PS: Who delete my post from Google+ - Because it is really important. I am sad you hurt me. Thanks! I don't want help you now. And Bye I don't buy Unity3D Pro

 

What generational GC are you guys going with?

In my experience the lack of fine grained tuning in most .NET GC's is the main issue. Not sure what the latest is in the .NET world here. But as of a couple years back it was still not good. With the MS approaching being that it's all automatic for the most part. Which works fine for web apps, no so much for low latency/high throughput applications.

Java generally took the opposite approach, exposed all the knobs.

The difference is often not minor. An average example would be say a 20ms pause twice a minute or more, compared to a 3ms-5ms pause every 3-4 minutes. That was my experience working on high throughput realtime game servers under load. If you can't control promotion rates and generation size manually, you are basically hosed.

Unity probably has the talent to mess with the GC internals and expose that kind of thing. Or maybe there are generational GC's that expose more knobs now. I know the default GC still doesn't, but I've heard there are more options out there now.

 

I have the opposite experience. Even the crash mentioned in the docs is not reproduceable.

 

I suppose the note there means accessing a [threadstatic] field from the unity javascript thing from non-mainthread? If you've tested that or if there's no threading in unity script, I have no clue to be honest, feel free to ignore this.

But mainly, I agree with you: I haven't found any issues using [ThreadStatic] in pure C# code. I've since removed all my uses of it though for other reasons (it doesn't work well with the threadpool but that's not a bug), and I haven't found a reduction in getthreadcontext crashes or something.

 

I tested it on a MonoBehaviour field, works as expected.

Code (CSharp):

1. using System;
2. using System.Collections;
3. using System.Threading;
4. using UnityEngine;
5.  
6. public class Foo
7. {
8.     private int x;
9.  
10.     public Foo(int x)
11.     {
12.         this.x = x;
13.     }
14.  
15.     public override string ToString()
16.     {
17.         return x.ToString();
18.     }
19. }
20.  
21. public class Test : MonoBehaviour
22. {
23.     [ThreadStatic] public static Foo foo;
24.  
25.     private IEnumerator Start()
26.     {
27.         foo = new Foo(0);
28.  
29.         var thread = new Thread(() =>
30.         {
31.             foo = new Foo(10);
32.             GC.Collect();
33.             Thread.Sleep(1000);
34.             GC.Collect();
35.             GC.Collect();
36.             Debug.Log(foo);
37.         });
38.         thread.Start();
39.  
40.         yield return new WaitForSeconds(.5f);
41.         GC.Collect();
42.         GC.Collect();
43.         GC.Collect();
44.         Debug.Log(foo);
45.     }
46. }

Since UnityScript is a walking dead, I tested ThreadStatic in C# only.

 

Hm, interesting. Would wish a dev from Unity would respond on this topic though, as we can't just "hope" that it works all the time and not just in simple tests. Issues coming from using this would be a bitch to debug with users

 

Hi Josh,

Cool, thanks for the feedback. Maybe the docs should be updated accordingly?

Regarding .NET 4.5: Is there a list of things that currently don't work or general reasonings it's still considered experimental? I'd love to see our game switch but of course relying on a core element like the runtime that's officially marked as experimental doesn't feel right for a public release

Regards,
Chris

 

I've got a bunch of stuff from nuget that targets 4.6 and haven't had any issues yet. .Net Standard support will be nice though because so many packages are moving to it, I already have a couple that I'm a major release behind on due to .Net Standard dependencies.

 

Yeah, at the end of this page: https://docs.unity3d.com/Manual/Attributes.html
Reading that again though I think "added to a Unity script." might refer to Unity's JS. In my opinion not very precise though as the language is indeed referred to as JavaScript in a lot of the docs too and even if it is talking only about the JS I think that's normally called "UnityScript"? Anyway, something like "the ThreadStatic attribute defined in the .NET library should not be used in JavaScript as it will cause a crash." might be more precise there

And thank you for the info regarding the experimental state

 

Could you update the documentation to reflect that? The term "Unity script" is very unfortunate what with that almost being the name of a scripting language. Knowing that's there's a good reason for not allowing ThreadStatic and what exactly the consequences of using it anyway could be would also be nice.

 

So if I understand this correctly, it should just not be used in conjunction with any UnityEngine.Object derriving object? Plain C# classes without any references to any assets should just work fine?

 

@JoshPeterson
Is this wording correct?

 

The [ThreadStatic] issue repro:

Code (CSharp):

1. using System;
2. using System.Threading;
3. using System.Threading.Tasks;
4. using UnityEngine;
5.  
6. public class Test : MonoBehaviour
7. {
8.     [ThreadStatic]
9.     private static Texture field;
10.  
11.     private void Start()
12.     {
13.         Debug.Log($"Main thread id = {Thread.CurrentThread.ManagedThreadId}");
14.  
15.         var mainThreadContext = SynchronizationContext.Current;
16.         var asset = new Texture2D(64, 64);
17.  
18.         Task.Run(() =>
19.         {
20.             field = asset;
21.             Debug.Log($"Assigned to the field, thread id = {Thread.CurrentThread.ManagedThreadId}");
22.  
23.             using (var waitHandle = new ManualResetEvent(false))
24.             {
25.                 mainThreadContext.Send(_ =>
26.                 {
27.                     Resources.UnloadUnusedAssets().completed += asyncOp => VerifyAsset(asset, waitHandle);
28.                 }, null);
29.  
30.                 waitHandle.WaitOne();
31.             }
32.             Debug.Log($"Task on thread {Thread.CurrentThread.ManagedThreadId} has just completed");
33.         });
34.     }
35.  
36.     private static void VerifyAsset(Texture2D asset, EventWaitHandle waitHandle)
37.     {
38.         if (asset != null)
39.         {
40.             Debug.Log("<color=green>Asset is still alive</color>");
41.         }
42.         else
43.         {
44.             Debug.Log("<color=red>Asset has been cleaned up</color>");
45.         }
46.         waitHandle.Set();
47.     }
48. }

 

It now nearly half a year. Do we able to use C#7 anytime soon?

 

If you're on a newer Unity, you can try the official Incremental Compiler. It brings C#7+ features to the table and might give you much shorter compile times.

 

What's the relation between that and the incremental compiler? Is the incremental compiler simply using the features that are meant for .3 earlier`than the standard compiler, or does it bundle it's own copy of Roslyn?

 

Glory on the great unity

 

@JoshPeterson , do you will upgrade to mono 5.14 or mono 5.12 ? Or is another solution ?

 

Are you guys any closer to picking a 2018.x release for switching to the new .NET runtime by default for new projects? A colleague of mine made a good point in saying that this would be the ideal time for us to also switch over as it would demonstrate confidence of the stability of the new runtime. I'd hope it'll be 2018.2 but perhaps with the Roslyn compiler showing up for 2018.3 it'd be more likely to happen then.

 

Are you making any effort to move toward CLS compliance, and would there be any chance of recognizing VB scripts and using VB's Roslyn compiler? Precompiled managed DLL's already work fine...this would be convenient, though.

 

That's unfortunate on CLS compliance. I raised this issue almost 3 years ago. It would've cost you nothing if you'd just updated code standards and let it come over time as various modules and systems were updated, replaced, refactored naturally through ongoing development.

 

@JoshPeterson

I would like to use this assembly

Microsoft.CodeAnalysis.CSharp.Scripting

. How would I go about adding that?

The workflow normally would be to create a normal .net core 2.0 application in visual studio, open references and install the package from NuGet.

First of all how would I even get the assemblies, as VS doesn't even put them into the output directory anymore unless you "publish" your project.

I tried the naive way for now, created a new Unity project, changed the player settings to .net 4.x and api version to "net standard 2.0".
Then I published my test project in visual studio, and simply moved all the assemblies into a folder in unity.

Unity then refuses to load anything:


This is 2018.2.0b4
Scripting Runtime Version: .NET 4.x Equivalent
Scripting Backend: Mono
Api Compatibility: .NET Standard 2.0
Allow unsafe code checked!
Installed the incremental compiler from the package manager window.

How can this be done?

edit:
When trying to run it, a new error appears:

Code (CSharp):

1. TypeLoadException: Could not set up parent class, due to: Could not load type of field 'Microsoft.CodeAnalysis.ParseOptions:_lazyErrors' (0) due to: Could not load file or assembly 'System.Collections.Immutable, Version=1.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:System.Collections.Immutable, Version=1.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a type:<unknown type> member:(null) signature:<none> assembly:*****\Assets\PublishedFromVisualStudio\Microsoft.CodeAnalysis.dll type:ParseOptions member:(null) signature:<none>
2. SyntaxParseTest.Start () (at Assets/SyntaxParseTest.cs:15)

Moving in the assembly it wants doesn't do anything.

Should I prepare a repro case, and should I add the separate (<100kb) .net core project as well (the one where the assemblies are actually coming from)?

If this has to do with code-generation at runtime and stuff like that: I would even be ok with it crashing when attempting to generate code. All I need is the SyntaxParser, SyntaxWalker and Visitor.

 

It's Roslyn, the c# compiler, some other team (I guess?) at unity uses it to make the "Incremental Compiler" that you guys are working on.

https://www.nuget.org/packages/Microsoft.CodeAnalysis.CSharp.Scripting/
https://github.com/dotnet/roslyn/wiki/NuGet-packages

Yeah, I guess so, that's the one I was using. Any idea why that wouldn't work then?
There is a version for .NET 4.6 available as well. So I'll try that one then and hope it works.

edit: The 4.6 version works! The unity gods (that is you Josh, and whoever else is working on this fundamental stuff ) be praised! This just unlocked so many things for me!

But there are still some strange errors. I'm not sure if you'd like to look at them, or if they are not relevant.



Is that something I should be concerned about?
Maybe it will screw things up when creating a full build of the game?

Here's a larger image that shows all the assemblies. The whole project is just this folder + one .cs file for testing directly in /Assets/

https://i.imgur.com/buuwzrY.png

edit2: wow, it even compiles stuff, producing working

Action<>s

and

Func<>

s. Cool stuff, I wonder if that also works when building for Mac or Android.

 

I'll have a bug report ready for you in 5minutes or so. Will edit my post here then.
Uploaded the whole project with the built in bug reporter, but didn't receive the usual email yet that contains the id.

 

Got the email now.

Case 1045941

 

@JoshPeterson If you guys aren't following this thread, please have a look and weigh in on it:
https://github.com/dotnet/standard/issues/682

It's essentially about the existential status of netstandard 2.0, and specifically, that there is no timeline or indication that Span (heavily relevant to our interests!) will ever become part of that standard (or perhaps, any standard...).

Essentially, it appears that microsoft is planning on abandoning netstandard as a 'api surface interface' and replacing it with .net core as 'the reference implementation' as net full framework was previously.

Obviously this is very irritating to a lot of people, but for unity in general is feel like this is particularly relevant and if you guys haven't been involved in that conversation, you really should be.

 

@JoshPeterson Any news on those error messages? Have you been able to figure out what's going on here?

 

@JoshPeterson is there an ETA for the first public beta of 2018.3 with C# 7 support? Also, what minor version are you planning to target? v7.2+ would be great, as that should be enough for the Span<> and Memory<> packages.

 

Sadly at the end of august 2081.3 still not released