Unity Future .NET Development Status

I don't think they will update to it because it is not an LTS version. I assume Unity will directly go to .NET 8 in November 2023. See here: https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/#net-7-is-supported

 

I think you're massively misinformed. .net 7 is just as much supported as a .net lts version would be, just not for as long. So it wouldn't make sense not to use upgrade to .net 7, or any other current (non-lts) version. And as Unity have said already, they are looking to always update to the new .net version shortly after a new one's been released each year.
Also see: https://youtube.com/watch?v=55UdBNRuQ7k

 

@JoshPeterson
With the migration to MSBuild or at some other point during the .NET migration, will it also be possible to write, compile, run & debug games completely without the editor?

 

Well without the source ( or the enterprise license from Unity ) you're probably as an Indie not going to be able to do that. ( Maybe circumvent with an engine dll? )

Otherwise... That might work...

 

Will il2cpp benefit somehow from CoreCLR in the future or is it completely unrelated as il2cpp has it's own runtime?

 

They stated in the past that they want to bring IL2CPP and NativeAOT closer together

 

If the above is a big fat image going "ohno cookies", the link is GAH UNITY FORUMS

Click here

If I actually write the url in cleartext, the forums puts a MEDIA tag around it, and then the forum software replaces it with a big box saying that things inside MEDIA boxes won't work because of cookies. Thanks, forums!

But uh like great work on .NET!

 

Great presentation Josh! I am very excited about all of the fun new .NET things coming!!

 

I had no idea you could use Burst in an unsafe context and get the same performance benefits! That’s really interesting!

 

About time we got .NET in Unity!

 

I've been playing around with the alpha and Awaitable a bit, and I've noticed that the job system might need an Awaitable sopport. I wrote my own extension:

Code (CSharp):

1. public static class JonHandleExtensions
2. {
3.     public static async Awaitable CompleteAsync(this JobHandle handle, int maxFrames, CancellationToken cancellationToken = default)
4.     {
5.         for (int i = 0; i < maxFrames; i++)
6.         {
7.             if(handle.IsCompleted) break;
8.             await Awaitable.NextFrameAsync(cancellationToken);
9.         }
10.         handle.Complete();
11.     }
12. }

And in a MonoBehaviour:

Code (CSharp):

1. async Awaitable Start()
2. {
3.     var myArray= new NativeArray<int>(10, Allocator.TempJob);
4.     var handle = new MyJob
5.     {
6.         Data= myArray
7.     }.Schedule();
8.  
9.     await handle.CompleteAsync(4, destroyCancellationToken);
10.  
11.     // to something with the data
12.  
13.     myArray.Dispose();
14. }

 

I have a case where I'm instating a few hundred of MonoBehavors, even if the individual jobs don't take long, the total number of jobs takes several seconds. However, not much would change with the 4 frame limit.

Another thing that makes me wonder, is there a struct based Awaitable too and will async await be bust compatible someday? E.g. for ECS ISystem.

if Awaitable.BackgroundThreadAsync() and Awaitable.MainThreadAsync(); new? Is not in the current Alpha 18

 

May be an issue especially when calling these methods from sync code. Not very difficult to fix with a custom runner that awaits them but I'd expect it be implemented in the engine instead. I guess Forget() (or FireForget()) extension method would be a good place as it's a standard way to get exceptions from non awaited Task, UniTask also uses that name to get rid of compiler warnings about missing await.

Code (CSharp):

1. void MySyncMethod()
2. {
3.   MyAwaitableMethod().Forget();
4. }
5.  
6. ...
7.  
8. static void Forget(this Awaitable a)
9. {
10.   AwaitableRunner.I.Add(a);
11. }
12.  
13. ...
14.  
15. class AwaitableRunner : MonoBehaviour //singleton
16. {
17.   //list or something thread-safe?
18.   List<Awaitable> list = new();
19.  
20.   public void Add(Awaitable a) => list.Add(a);
21.  
22.   async Awaitable Update()
23.   {
24.     foreach(var a in list)
25.       await a;
26.     list.Clear();
27.   }
28. }

 

May be more clear name like:
SwitchToBackgroundThreadAsync
SwitchToMainThreadAsync
or
ContinueOnBackgroundThreadAsync
ContinueOnMainThreadAsync

 

Add a "to" so it reads as a more or less proper sentence?

await Awaitable.ToContinueOnBackgroundThread();
...
await Awaitable.ToContinueOnMainThread();

 

no

 

These sound nice. The current names kind of go against typical convention (start with a verb). Still, after a using static directive, "await BackgroundThreadAsync()" kind of has a ring to it as well.

 

I've been reading thread about future of text in unity and I see that Unity will move TextMeshPro directly to engine source instead of being a package. This will also happen to GraphToolsFoundation and something tells me, same will happen to many other packages.

So I have a bit of a naive question maybe, but would it be possible to distibute Unity using source csharp files instead of compiled dlls? I mean, you already provide reference source on github. So maybe Unity could compile engine libraries on startup only (because I'm not sure if it's possible to recompile them on fly?)

Or at least provide a way to compile your own dlls from reference code. I know it might be too much to ask considering it'll also involve licensing questions, but I would like to know if it is a possibility, considering that people will only get more annoyed as number of closed-source packages will, probably, grow

 

Please make sure that this makes its way into the documentation for the Awaitable class. This information is crucial.

 

Hi @JoshPeterson,

I am currently working on a source generator.

Is there currently a way to use Source Generators in a package?
Unfortunatly Assets in a package can not be labeled ... :/

 

This is a bit of a dumb workaround, but if you have your source generator as a dll file, move it into your assets folder, assign the labels there, and then move it back to the package.

 

Or build it outside of unity, publish on nuget and distribute using xoofx's unity nuget https://github.com/xoofx/UnityNuGet

 

It's only the UI that's missing. For write-enabled packages (local or embedded ones), you can use AssetDatabase.SetLabels to add labels anyway.

This is probably an oversight and the UI should be visible for write-enabled packages (and only disable editing for read-only packages). If you're affected by this, I'd try submitting a bug report.

 

Okay thanks to @Adrian , @Huszky , @RealMTG
That works

But now I am stumbling upon the issue that no files are generated.
My usecase is that I want to iterate through another C# Library and to generate a Unity integration like MonoBehaviours and Menu entries. The Library is a subject to change and therefore it has to generate it automatically again if changed.
Is there a way to archive this

 

If nothing is generated, the most likely cause is that you're using a yet unsupported (in unity) SourceGenerator api version.

 

Being able to mark assembly definition as Source Generator would be a great workflow improvement. I'd hope it could be added if asmdef-to-csproj won't land in Unity 2023

 

How is C# 11 progress so far. Especially about generic math, have you include that into unity type like Vector3 and float3 ?

ps generic math also imply many feature like static interface member
ps2. Generic Attribute also great for unity to adopt in C# 11

 

I only said that no files are generated. It works but Source Generator by default dont generate files but let them be part of the compilation and the end product.
This is a problem if you want to generate code for Unity because Unity does generate *.meta files and does referencing by those. So Scripts as a Asset file on your disk are necessary and not only during compilation.

 

Classes can be marked as partial, which can be created in Unity to generate .meta files. Source Generator works fine.

 

Are there any plan to bridge dotnet native for mobile and wasm or move the compiler to use dotnet build for mobile and wasm instead? I wish I could use dotnet interop system directly in unity

 

Maybe if we have unity that moved to csproj build system. Unity might not need .meta for cs files that not a monobehavior in the project anymore. And might need only one meta for csproj instead (there was mention about making cs file to not be an asset, I don't know how much would it imply)

 

Hold the phone stop the presses:


I opened the cupboard and accidentally found our Christmas gift. @JoshPeterson will we need to do some setup or will source generators just work? And which Unity versions does this include?

Now that I'm here anyway, kudos on Burst 1.8.1, great stuff to the whole team!

 

You were able to use SourceGenerators (at least v1 ones) and c# 9 for months already.

 

That's pretty neat, but I was always disappointed that source generators only allow adding new source files, rather than modifying existing code. Makes IL weaving the only way to actually modify the outputted code, and it's a pretty in depth topic to get into if you just want to do some simple things (transforming properties a bit etc).

 

That was a design choice and not a limitation.
Although you could always use direct roslyn api's to unsafely modify existing code and not deal with IL weaving.

But almost any use case can be solved with source generators. It just requires a bit of tinkering and thinking outside the box for some niche advanced use cases.

 

Relax, kid. That's extremely far from news by this point. com.unity.roslyn added support by way of external compiler toolchain for 2020.1. 2021.2 and above have built-in support. There's been documentation on this for a while as well.

 

Please consider adding

Awaitable.WaitUntil

.

 

Doesn't make sense? What would it even do?
There's already Awaitable.WaitForSecondsAsync()

 

It waits until something becomes true and we don't know when that will happen.

 

I assume

WaitUntil

is the function that take predicate callback

Awaitable.WaitUntil(() => somethingIsTrue)