Unity Future .NET Development Status

Thanks, found a solution, it turned out dlls references by incremental generators have to also be set to analyzers. For ex. I had to add RoslynAnalyzer label to Microsoft.Extensions.ObjectPool.dll and somehow incremental generator started working. No idea why but normal generator worked without that label.

 

I was thinking about what @xoofx said about supporting nuget packages with Unity

So, I was thinking about this, and I might see a solution. Using Content files https://devblogs.microsoft.com/nuget/nuget-contentfiles-demystified/ . What if Unity would support packages which have content files, and compile them with the appropriate symbols? It might even be possible to implement this process using a custom msbuild SDK similar to https://github.com/novotnyllc/MSBuildSdkExtras . Also using this, it might be possible to automatically convert existing UPM packages to this format using the nuget cli tools (some generated nuspec files maybe?)

Which ones of you points would I think it would solve?

This is not an issue. If a project is referencing a UPM package the consumer should not be able to modify the package's content, unless they are referencing it through the "file://" approach, but that already means that the consumer manually manages that package.

This is solved with this. If the content files are compiled to DLLs by unity, it can controll the compilation switches as much as now

The same as before. Since content files do not need to be compiled before distributing, they can support any unity version.

I am not really sure about this one.

This can be solved by additional content files. Just include everything that might be used by unity, the same way as done by UPM now. Native code distributed this way can be compiled by unity the same way as now.

That is not really an issue. NuGet.org already has a lot of packages not usable in some projects. For example, using packages which are built for WPF inside Xamarin/Maui/BlazorWasm will result in problems already, and the microsoft teams are fine with this.

If I am right these issues can be solved with this approach

You might even require to pack a mandatory manifest file with the content files which specifies metadata about the packages - for example minimum Unity version, the same way as done by package.json files currently.

This way even though Unity would still have its own twist on NuGet packages, from a consumer view it would not be any different from using any other NuGet package.

For package publishers they would have the flexibility to either distribute dlls (+ asset files if needed) if they don't need any special compilation symbols, or distribute everything via content files and let the consumers Unity instance compile everything.

 

Have unity shared anything on how they will solve hot reloading of assemblies on code change? Since .NET 6 does not have AppDomains?

 

Some people has mention that dotnet6 itself has its own reloading mechanism and it most likely be made possible if there are no issue moving unity to main dotnet ecosystem

 

This is amazing, I think we could discuss about this more in this thread https://forum.unity.com/threads/built-in-nuget-package-manager-support.504016/

 

For source code I prefer unity packages over NuGet as they can be installed directly from git link. Another way is cloning to "Project/Packages" folder to get git submodule with full history. That's not possible with NuGet.

Relaying purely on package system made by Microsoft for Microsoft isn't the best idea.

Main thing I dislike about packages provided by Unity is that in most cases they don't provide additional git source - making custom changes very difficult to maintain. On the other hand because of Nuget souceless nature packages very often have github links.

 

They talk about AssemblyLoadContext? It's not as powerful as appdomains. And comes we a large set of problem they need to workaround if they want to use it.

 

I think the main problems with having its own package managing system are 2.
1st, u don't really want segmentation in such a thing (look at the mess other languages have..)
2nd, and probably more important. Unity, as anyone else, has to select what to maintain and what to discard, and imho, putting effort in it's own package manager for little benefit is not worth it. (Specially when u consider all the things and features unity discards in general, like the newish build system that was developed by/for dots and then discarded leaving us with the old one which well, is crap. Or how they deprecated the mini "launcher" that had screen/key binding configuration and was extremely useful for small projects/prototyping/early stages of regular project.)

 

Well, no you can already do that. Just clone/download the library and reference it.

 

Well, no, that's not installing with a link. Not to mention that Nuget packages have complex structure, can't just unzip it and throw whole folder to Unity.

 

The people who right now share source with UPM would probably share the repo the same way if the produced a nuget package. If they use the solution I proposed (content files for the source and the assets) then the content files can just be extracted with a simple tool. The nuget package is just a zip file and extracting every content file into your assets/packages/etc folder can be done by a simple tool which can be used from the editor or through a cli tool.

The idea is to treat nuget content files the same way as unity right now does with upm packages - just a bunch of files.

Also to expand on this: if a special metadata file is present with the package that information could be displayed on nuget.org. The nuget team seemed open to displaying unity compatibility data on nuget.org https://github.com/nuget/Home/issues/9347 . This way we could even see the supported unity versions and platforms when searching for packages.

 

Again, if Unity would replace UPM with NuGet then installing with git link would stop working. Additionally more work would be required to create nuget package. Creating unity package for github repo is as easy as making package.json file. It can even be placed in any folder then installed with:

https://github.com/Cysharp/UniTask.git?path=src/UniTask/Assets/Plugins/UniTask

 

Yes, it makes publishing packages a bit more complicated and you lose the ability to install through github links but Unity will only have to care about one package manager instead of two.

Furthermore, installing packages from github repositories directly using git is a disaster waiting to happen. If it is a project with good reputation and if the people who maintain it don't mess things up then it would probably be safe. But what if the don't? Packages hosted on nuget cannot change and making a package inaccessible for the public is a slow and tedious process, and they might not even allow it. If you reference a upm package with git then the author can just simply remove a tag, do a force push, delete branches, delete their project or delete their account. You can't (or at least it is unpractically hard to) pull packages from nuget.org.

 

Fork like always, the same can be said about pulling any public repo or source code of all nuget packages.

 

Yeah so now you are maintaining your own fork of every dependency you have instead of just using a package manager which prevents the problem

 

we just use our own git repo for internal studio packages
And it will not be possible without git package support

 

For internal packages you can use any nuget feed and publish there. Github has it's own nuget feed and so does Azure Devops and TeamCity. Also, for internal packages you can just add your internal repos as submodules and reference them locally

 

It is absolutely not usable comparing to git repo
we don't what to have to publish every minor change in module while in development
we actually work on different project for few years not publish anything nor having any sense to do this unnecessary overhead.

Most used modules attached just as git submodules into project and stable ones just with direct link, access rights just work without any additional work from our side because it is the same right as entire git server has.

How this compares with some another side tool like nuget?

 

If you are actively developing a shared internal dependency, then you use git submodules - as you do now.

If that dependency needs a stable release -> release a new nuget package.

That package release does not even have to be manual. Setting up a CI pipeline to automatically publish a new nuget package to an internal or external nuget feed takes like a few hours max, and then you can just forget about it. If you use something like Azure Devops your pipelines can be shared company wide - just create a pipeline which can be configured per project and every project uses the same pipeline which releases the correct version on every push/pull request/tag or anything you like.

 

Not having to worry about CI in the first place is a virtue.

I just think there isn't anything dire that NuGet will definitely solve that UPM doesn't. The proposal to use NuGet in place of UPM only leverage NuGet as a packaging format, as far as I can see, and I can't see why it is more beneficial than what UPM does today.

 

The benefit is that you don't have to manage two very different package manager either as a consumer or a package publisher

 

I don't think that is a problem to begin with. Right now, NuGet support is not even a thing, so the packages we see are all in UPM format, as it is the only option. When Unity has proper support for NuGet, I'd wager that package publisher can just choose whatever format is most convenient to them. Because the consumer will be using the package in Unity anyway, and both of them would be natively supported, I can see no issue if some packages are exclusively UPM or NuGet. It would be hard to imagine that using UPM would lock out using NuGet, unless Unity deliberately design things that way.

Of course, with proper tooling, NuGet can be as easy to use as UPM in existing and future use cases, but those tools don't exist yet, so I would not preemptively choose one over the other.

 

Plz remember there are literally millions of frameworks and libraries available though nuget. If a project isn't using any then I really believe it is more the exception than the rule. My project in only medium sized (a 1 man effort) and I have around 10 libraries that I have to download manually from nuget, unzip, look for the proper files and copy them to plugings folder...
(Yes, I know there are 3rd party tools to use nuget in unity and I also know they break every time unity changes things...)

And I strongly second the statement that if u want to include code that is expected to change quickly, u should use git sub modules not a package distribution system. Mixing the tools is a problem waiting to happen.

 

You can simplify this:
1) Create a C# library project
2) Set NetStandard to 2.0/2.1 depending on the version you are using in Unity.
3) Add Nuget packages to .csproj.
3) Publish it (yep, publish the library) to some folder
4) You will have a folder with resolved DLLs.
5) Copy them to Plugin folder (unfortunately it's still a manual process).

It's a good idea to add this library to git.

 

Just publish to Plugins/published folder.

 

When can we expect to see Awaitable released?

 

It's planned for 2023.1.

 

AwaitableCoroutine was added in 2023.1a16.

@simon-ferquel-unity What happened to the name 'Awaitable'? Why are they called AwaitableCoroutine in the new alpha? Will they be renamed?

 

This is an argument in favor of Nuget. Git is terrible; everything about it is terrible. In particular, Nuget is versioned quite nicely and keeps track of its own dependencies; Git has neither of these properties, which makes it a decidedly subpar dependency-package system.

 

The main problem I see with NuGet is that you can't use the preprocessor. You can't put things behind #if UNITY_EDITOR, use Version Defines, or use Assert.
As a person who maintains a couple of open-source libraries for unity, I really appreciate version defines. I can add support for third-party libraries at multiple versions, without depending on them. This is not doable with a binary package like NuGet.

 

They are different things. Git isn't designed for package management. UPM supports different protocols to download packages like file and git. Most packages on UPM are source code, but you could theoretically provide a pre-built DLL, e.g. from Nuget.

 

That is why i had the idea for Unity to support compiling content files in nuget packages.

 

Also I liked what @TheZombieKiller was saying. Did you guys still look into it? Extra functionality at 0 performance cost when you don't use it... now that I can get behind.

If not now, maybe to revisit it when Unity is on .NET 7?

 

Can you provide the steps you have taken? I have tried to get incremental generators to work for weeks now, but without any luck.

 

First make sure it's working outside Unity without any dependencies then in Unity then the same with dependencies. I'm using newest Roslyn in 2021 lts that could be a bit newer than what's in UN 2022. My source generator lib is targeting netstandard2.1 (not recommended but works for me). There's also a lot of Microsoft.CodeAnalysis dlls in my project for something else no idea if they also help source generators.

 

I wonder, is anyone simply compiling all game code outside of Unity and just use dlls? Given the mess caused by removing "Recompile After Finished Playing" feature in LTS version I'm thinking of doing that to not rely on Unity compilation pipeline.

#Update
Just tried, it takes good 10 minutes to recompile when DLL contains MonoBehaviours and UnityEngine references . DLL in Unity doesn't even have auto-referenced checked.

 

Moving to dll's mid-project is a major pain, because MonoBehaviours and other UnityEngine.Object types inside a dll are referenced with dll GUID+FileID, while outside the dll they're just GUID. So all of your MonoBehaviour references will be lost.

So probably nobody tried to do that

 

https://forum.unity.com/threads/incremental-source-generator-csproj-template-2022-2-b13.1358720/

 

Can we see it online? Could you please share the video link once its available, Thanks

 

Just go to the dotnetconf home page you can watch the streaming on Youtube.

 

Thank you very much

 

Will the talk be recorded and made available later?

 

AFAIK Yes

 

I stand corrected. Somehow day 3 record is unavailable.

 

Great!

Hope there are no audio issues like in the previous video

 

.Net7 is released, hope that unity would catch up later.