Unity Future .NET Development Status

I don't think it's fully featured right now anyways, but could definitely be something Unity could contribute to as it is the .NET AOT solution going forward

 

this has already been answered in this thread (like last page even, just please read through those before asking)

 

Care to link it directly because the only mention of CoreRT I have seen is in regards to being able to benchmark it and nothing to do with Unity possibly switching to it? And none of it was in even the past 5 pages so not sure where you're getting that from?

 

Awesome thanks!

 

System.Reactive in net50 seem to work fine in every platform dotnet support (linux and xamarin mobile). I think there would be platform specific dll provided and so it should have one that fit for unity usage

 

There's a chance that dll I've build works the the same as net50 one. At least I can't find any difference, every platform specific change is tied to net5.0-windows:

 

I think this is true of pretty much any Microsoft package these days, all the DLL's are essentially the same with platform/compatibility issues handled. I think if there's no framework specific differences they will only give a netstandard version.

This should also be true of anything maintained by Microsoft or the .NET Foundation.

 

Sorry I dont check here often but on the comment of "we should get a layer on top of system.reactive for unity" someone already started on that (a few have tried before as well).

https://github.com/Cosmic-Shores/Rx.Unity

 

That repo was modding his own version of System.Reactive and making it a bit incompatible with actual dotnet version. It also has some bug if using in unconventional way

Still a fantastic repo and I think it usable in the meantime

 

Yeah I know he was in talks with some of the people over in the rx world to see if they could potentially make a couple of changes to make unity integration a bit easier, but its been fruitless so far, maybe there are work arounds, but not many others are really trying at the moment to my knowledge.

There was also an attempt a while back to try and work out what specific parts of rx wouldnt work on Unity (https://github.com/grofit/unity-rx-test) but I cant remember how far we got with it, but it seemed like most bits worked.

 

This is a follow-up report on using gRPC with Unity.
gRPC .NET is not available due to a problem with HTTP/2, which is not supported by Unity.
To continue using gRPC C # core-library, I posted information to avoid the mac IL2CPP build in gRPC C# core-library issues.

Build script for gRPC C# core-library for Apple M1 #29815
grpc/grpc#29815

How to avoid Unity IL2CPP build errors on macOS #29817
grpc/grpc#29817

 

With all this genius going around, I feel kinda small asking this question, but here we go!

I’m learning a bit of async now and I’m really enjoying it! Nothing I write right now I would use in production but I’m getting there.

One thing I’m curious about is “asyncing” existing code. Consider:

Code (CSharp):

1. void DoStuff()
2. {
3.     // Does stuff.
4. }
5.  
6. async Task DoStuffAsync()
7. {
8.     DoStuff();
9. }

The only thing the async method does is “make the sync method awaitable”, but it still only runs synchronous code. I figure, however, that it does so on a different thread. Say that DoStuff here is a method that takes 3 seconds to complete, will await DoStuffAsync allow me to run that without blocking the main thread?

 

It run synchronously on the same thread.

You can do something like:

Code (CSharp):

1.  
2.     void DoStuff()
3.     {
4.        //do some stuff
5.     }
6.  
7.     public Task DoStuffAsync()
8.     {
9.         return Task.Run(DoStuff);
10.     }

 

1. In general you don't want to write it like that as any exception will be hidden. In can be somewhat mitigated with (UniTask does that by default for UniTasks):

Code (CSharp):

1. TaskScheduler.UnobservedTaskException += (sender, args) => Debug.LogException(args.Exception);

2. Another problem is that stack traces of these exceptions will be pretty bad. To get better ones:

Code (CSharp):

1.  
2.     async void Start()
3.     {
4.         await DoStuffAsync();
5.     }
6.     void DoStuff()
7.     {
8.         throw new Exception("error");
9.     }
10.     public async Task DoStuffAsync()
11.     {
12.         return await Task.Run(DoStuff);
13.     }

3. If you are writing library don't try to force sync code being async with Task.Run and let consumer do it. Too many thread pool tasks may lead to "thread starvation".

 

I actually had performance in mind

Code (CSharp):

1. // using 1 Thread from Threadpool
2. public Task DoStuffAsync()
3. {
4.      return Task.Run(DoStuff);
5. }
6.  
7. // using 2 Thread from Threadpool,
8. public async Task DoStuffAsync()
9. {
10.      return await Task.Run(DoStuff);
11. }

Personally, I wouldn't do it that way either, unless I have an old library that receives asyn support.

 

Also you can use .ConfigureAwait(false) on the awaited Task so that the thread scheduling the Task doesn't need to wait for the completion of the Task to continue execution (fire and forget). The compiler automatically puts .ConfigureAwait(true) by default so worth knowing if you're new to async/await.

 

I don't think that's how it works. ConfigureAwait(false) won't switch back to Main-Unity Context, good for performance if you don't have to use anything from Unity. It still awaits.

Anyway this is a wrong thread for this topic.

 

My wording was a bit wrong, the rest of your execution after an await will run on the thread pool thread that the await happened on, instead of being returned to the context it was all started from.

To be clear, this is best used to stop deadlocks when something async is called synchronously. Without using ConfigureAwait(false), a synchronous blocking call using .Wait() or .Result on an async method with an await would never be able to return.

See https://devblogs.microsoft.com/dotnet/configureawait-faq/ and

 

would be interesting to see how it compares to unity 2018 test? is performance fixed finally?

 

The last test I did was https://forum.unity.com/threads/unity-2021-1-performance-overview.993186/#post-6614383, I don't know whether performance improved since then in any Unity version. I'm also not interested in it anymore to be honest.

 

Not sure if it was already mentioned but I'd like to add on to this that you _can_ use gRPC Web in Unity as that uses standard HTTP under the hood. It has some limitations, such as client side streaming not working but if you have a gRPC API its still a good enough workaround until HTTP/2 comes around.

 

He was talking about default/standard gRPC NET package in Unity, which, as it was mentioned few times in this thread, does not work due to HTTP2 limitations. Obviously if you rewrite it to use HTTP1 it will but then it defeats the whole point of using a package to solve issue/dependency.

 

I know personally gRPC-Web is not fit for purpose as I have a requirement for duplex streaming which cannot be achieved. I have looked into other alternatives as workarounds that do a better job here. https://github.com/protobuf-net/protobuf-net.GrpcLite for example which provides gRPC over TCP. This is still early in development and will depend on demand but I think if you're looking for something in Unity today that supports duplex streaming, this is pretty much your only option.

 

thanks that explains a lot, what do you see in profiler is it others or scripts? and how much ms is difference, is it 1 ms? that's huge

 

We gotta get that C#11 now hehe:

 

Also, when will we get Roslyn a.k.a. Microsoft.CodeAnalysis.CSharp 4.0+ support for source generator? I just recently run into this issue with the MVVM source generator of Community Toolkit where their next major version will target 4.0.1 instead of 3.11.

 

looks like Unity 2022.2.0a13 has an updated compiler version. I did not find any announcements about it, but

#error version

prints this

Code (csharp):

1. error CS8304: Compiler version: '4.1.0-5.22116.13 (dbffaa4a)'. Language version: 9.0.

So in theory incremental generators should work in 2022.2

 

It does though. You don't need to rewrite it, you just replace the request handler with the GRPC Web one. See this:
https://docs.microsoft.com/en-us/as...0#configure-grpc-web-with-the-net-grpc-client

 

Yeah in this case gRPC-Web will not fit your use case. Duplex streaming is one of the use cases where you're going to have to fall back to different solutions like the one you mentioned. I hope that .NET 6 comes sooner rather than later, then this will all be a problem of the past.

 

Could you plesae update your docs concerning .Net Standard 2.1 conditional compilation? https://docs.unity3d.com/Manual/PlatformDependentCompilation.html

 

JoshPeterson, When will it be possible to test the earliest version with .netCore ? Maybe you have an unstable branch where there are already innovations. There is a desire to test before the release of the alpha, is it possible and possible to provide ?

 

I went ahead and tested this in alpha 16 and I can confirm incremental generators work when using Microsoft.CodeAnalysis.CSharp 4.1.0.

 

Found pretty easy and stable way to use Nuget with Unity. Simply make C# library project and publish to folder in Unity project.

SatelliteResourceLanguages=en

won't generate duplicate dlls. Does anyone have an idea how to include analyzers/generators without specifying roslyn version?

Code (CSharp):

1.  
2. <Project Sdk="Microsoft.NET.Sdk">
3.  
4.     <PropertyGroup>
5.         <TargetFramework>netstandard2.1</TargetFramework>
6.         <SatelliteResourceLanguages>en</SatelliteResourceLanguages>
7.     </PropertyGroup>
8.  
9.     <ItemGroup>
10.       <PackageReference Include="System.Text.Json" Version="6.0.4" GeneratePathProperty="true"/>
11.     </ItemGroup>
12.     <ItemGroup>
13.         <Content Include="$(PkgSystem_Text_Json)\analyzers\dotnet\roslyn3.11\cs\*.dll">
14.             <CopyToOutputDirectory>Always</CopyToOutputDirectory>
15.             <CopyToPublishDirectory>Always</CopyToPublishDirectory>
16.         </Content>
17.     </ItemGroup>
18. </Project>
19.  

 

The easiest way is to click Build, and all the dependencies will pull up to Unity as it works for me.

 

You get System.Text.Json.SourceGeneration.dll when you build?

 

You could try something like:

Code (CSharp):

1.  
2. <Project Sdk="Microsoft.NET.Sdk">
3.  
4.     <PropertyGroup>
5.         <TargetFramework>netstandard2.0</TargetFramework>
6.         <LangVersion>latest</LangVersion>
7.         <IncludeBuildOutput>false</IncludeBuildOutput>
8.         <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
9.         <CompilerGeneratedFilesOutputPath>$(BaseIntermediateOutputPath)Generated</CompilerGeneratedFilesOutputPath>
10.     </PropertyGroup>
11.  
12.     <ItemGroup>
13.         <PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.3.2">
14.             <PrivateAssets>all</PrivateAssets>
15.             <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
16.         </PackageReference>
17.         <PackageReference Include="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="3.10.0" />
18.     </ItemGroup>
19.  
20.     <ItemGroup>
21.         <None Include="$(OutputPath)\$(AssemblyName).dll" Pack="true" PackagePath="analyzers/dotnet/cs" Visible="false" />
22.     </ItemGroup>
23.  
24. </Project>
25.  

With the following in the project using the generators:

Code (CSharp):

1.  
2. <ItemGroup>
3.     <ProjectReference Include="..\Generators\Generators.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false" />
4. </ItemGroup>
5.  
6. <ItemGroup>
7.     <Generated Include="$(BaseIntermediateOutputPath)Generated\Generators\Generators.FeatureGenerator\*.cs" /> <!-- REPLACE WITH THE GENERATOR NAME -->
8. </ItemGroup>
9.  

Not sure if that will work but it should be something along those lines as this will emit the code into the dependent project.

 

My "project" is Unity so I can't change csproj. I simply want to build all dlls (including generators/analyzers dlls of nuget packages) to folder in Unity project.

 

Why don't you just manually copy the .dll to unity once? Since the source generator dll doesn't really change, that's a 1 time job, or if you want to be completely sure, simply automate copying the source generator .dll with an msbuild task similar to:

Code (CSharp):

1. <Target Name="CopyJsonSourceGenerator" AfterTargets="AfterBuild">
2.         <Copy SourceFiles="C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\7.0.0-preview.4.22229.4\analyzers/dotnet/cs/System.Text.Json.SourceGeneration.dll" DestinationFolder="PATH_TO_UNITY_PROJECT"></Copy>
3. </Target>

 

@JoshPeterson Does Unity 2021.3.4f1 support sending http2 based requests?

 

no

 

It's not when using 10 source generators that are updated and have other dependencies.

That's already what the csproj I've posted does but I'm looking for a better way without specifying path for every source generator. I thought maybe PrivateAssets=none would work but it only exposes analyzers to other csprojs, not in builds.

 

Do you know any kind of external library, using which http2 based requests can be sent?
The server I’m trying to reach only supports http2 based requests.

 

no idea really. they claim to do it, kinda: https://github.com/sp-mario-quesada/HttpTwo-unity

 

specify the 10 paths. really not a lot.
for a better solution wait for csproj support

 

No point in posting if you don't know the answer. You still don't understand that there are more dependencies.

https://assetstore.unity.com/packages/tools/network/best-http-2-155981

 

It's approximately a 3-line code change to add call stacks to coroutines. I've been using this since Unity 2017. It works fine.

I feel there is a vast amount of opinion (not you specifically - I'm talking in general) from people who don't know what you can do with coroutines, or how to use them effectively - mostly because Unity staff never bothered to document them correctly - and sadly that seems to include many (most?) staff internally at Unity. The things we've been doing to write better game code for the last 5+ years seem to still be 'what? that's not possible!' when mentioning them to Unity people informally (at in-person events etc).

NB: 10 years ago, coming from a pure .NET background, I hated coroutines - felt like a crappy attempt to solve a problem that was already better solved. But since then I reverse-engineered the missing docs (by standing on the shoulders of others who'd been using them longer than me) and have found them extremely valuable in game development.

Yes. It's easy. Again - we're talking on the order of 10 lines of code (off the top of my head - it's a while since I had to rewrite it for a project instead of re-use existing) you write once and re-use everywhere.

I agree there are better approaches in general. But for games in particular: coroutines work great.

 

I was forwarded this thread by someone, so word is spreading .

I've just had one of my open bugs on Assembly Definitions closed (for the third time), with an extended writeup along the lines:

'Yeah its a bug, but no - we're not even going to try to fix this until after (someone) has ported everything to MSBuild.'

Which seems wrong. Asmdefs simply don't work correctly - the VersionDefines subsystem (which was used as the excuse not to fix other bugs) is broken. It seems the collective response is "lets wait 4+ years until we don't have to fix this, because we'll already have ported everything to MS by then, and then our own bugs vanish because our code will have been replaced". I understand that response! It's technically accurate, and would save efficiency overall!

But it seems unreasonable to hold all Asset authors over a barrel because no-one wants to fix this.

The strangest part is: I have had builds of the UnityEditor (2019 LTS in particular) where it seemed VersionDefines *did work correctly* across Packages. All I was asking was for this to be fixed, and to work in general. But Unity QA keeps coming back with: "yes we can reproduce the bug", "not possible to fix".

It seems like its possible (although I obviously cannot be 100% sure). Somehow. Because it worked - I have projects that respect VersionDefines in packages. Same projects reopened in current LTS versions of Unity ... stop building. And my attempts to recreate those same projects in new versions of Unity fail - I can't figure out what's different.

But QA is closing the bugs with "requires MSBuild". Which - as far as I can tell from this blog post - means "not for another 3-5 years" (bearing in mind I have to support all LTS versions. Which means if you fix it in 3 years time and don't fix it in the LTS versions then it will be another 4 years before I can use it).

So:
1. Is there a realistic timeline for when this will be included in an LTS release? (ie a date after which people can write AssetStore assets and not have to do vast amounts of hacks to workaround bugs Unity refuses to fix in the core build pipeline)
2. Is there anyone interested in working with me to figure out how/why this seemed to work in 2019 but doesn't any more? (maybe I did something very late one night, sleep deprived, in desperation - like manually inserting a #define in a global C# file that would force it to work - and forgot all about it. Because *it brifely worked*. But I've been through every obvious thing I can think of and can't find anything like that)