Add a TFM for Unity's DOTS profile

[joshpeterson]

At Unity, we would like to explore the possibility of having a new target framework moniker for a very small base class library profile that Unity will use for some of its products.

This profile will focus on a few principles:

• Small code size
• No support for reflection
• Focus on value types
• Limited GC allocations
• Limited use of exceptions
• Limited use of virtual methods

We would like to make this profile available on NuGet so that it can be used in .csproj files to allow good IDE integration and to allow developers to write libraries using it.

This profile will be a proper subset for .NET Standard 2.0, and later a proper subset of .NET 5.

Initially, I'll propose the name "unity2.0-dots", to indicate that it is a proper subset of .NET Standard 2.0.

Let's discuss whether or not this is a good idea, and if it something that can be implemented.

[joshpeterson]

cc @rrelyea @mhutch @terrajobst

[terrajobst]

Thanks for filing this after our discussion. To add some more points we discussed:

1. For now, you'd like a one-way compatibility rule, that is unity2.0-dots can install into netstandard2.0 (and by extension any .NET that implements netstandard2.0), but not the other way around.
2. Moving forward, you'd want a one-way compatibility rule, that is unityX.Y-dots can install into net5.0 (and by extension any .NET that sits on top, such as net5.0-windows), but not the other way around.
3. We concluded that the "full Unity" shouldn't get a separate TFM in the .NET 5 world and (just like ASP.NET Core & Xamarin Forms) it would be in net5.0.

In order to make (2) easy to reason about I propose that Unity DOTS will version in lock step with .NET 5 and later, that is, that unityX.Y-dots is considered compatible with netX.Y, when X >= 5. This avoids us having to coordinate changes to NuGet every time a release comes out. The downside is that Unity DOTs cannot version independently.

Does this make sense?

[joshpeterson]

In order to make (2) easy to reason about I propose that Unity DOTS will version in lock step with .NET 5 and later, that is, that unityX.Y-dots is considered compatible with netX.Y, when X >= 5. This avoids us having to coordinate changes to NuGet every time a release comes out. The downside is that Unity DOTs cannot version independently.

This might be difficult. Is there some way to name the TFM so that Unity can make non-breaking changed (e.g. add APIs) without the need to tell NuGet about a new version?

So maybe unity5.0-dots is a proper subset of net5.0. Then we want to add a new method to unity5.0-dots which is already in net5.0. Could we add an additional version number, like unity5.0-dots-1.0. Then the next version with the new method exposed would be unity5.0-dots-2.0?

[joshpeterson]

Does this make sense?

Points (1) and (3) do make sense based on our discussion. Thanks!

[terrajobst]

This might be difficult. Is there some way to name the TFM so that Unity can make non-breaking changed (e.g. add APIs) without the need to tell NuGet about a new version?

We could have a rule like that:

• unityX.Y-dots is considered compatible with netX.0, when X >= 5

But that means the only allowed additions to the Unity DOTS profile are APIs that already are in the corresponding .NET X.0 release. But while we don't have plans to ship minor versions moving forward, I wouldn't bet my architecture on it, so I'm not sure how to feel about this.

So maybe unity5.0-dots is a proper subset of net5.0. Then we want to add a new method to unity5.0-dots which is already in net5.0. Could we add an additional version number, like unity5.0-dots-1.0. Then the next version with the new method exposed would be unity5.0-dots-2.0?

I'm not sure I like that because it introduces a new concept into the TFM that is separate from both the existing system and the .NET 5 TFMs. @rrelyea can correct but this feels like a very heavy hammer. Before we go there, we should explore other options.

[joshpeterson]

We could have a rule like that:

• unityX.Y-dots is considered compatible with netX.0, when X >= 5

But that means the only allowed additions to the Unity DOTS profile are APIs that already are in the corresponding .NET X.0 release.

This is pretty much exactly the behavior we want. Let me try to make it more concrete with an example:

Suppose the unity5.0-dots profile ships with System.Collections.Generic.List, but the Count property is not included in that release. Then later on we realize "Oh no, we forgot about Count! Some users need that." So then we would like to ship an update to the TFM which includes the Count property.

This is the kind of thing we would like to be able to do. What is the best way to allow this to be possible?

[lucasmeijer]

I doubt the TFM names discussed in this issue are good choices. In Unity each assembly will be able to make a choice if it wants to 1) "target normal .net", or 2) "the unity specific super tiny dotnet".

for 1), I'm thinking we should use normal "net5.0", for maximum ecosystem compatibility.
for 2), I'm thinking we should use "unitytiny1.0". the C# BCL api exposed by this "TFM" is 30x smaller than netstandard2. We've dropped most methods on System.String. There is almost nothing there, and there will be 0 ecosystem code out in the wild (today) that is accidentally compatible with it.

very curious to hear if @terrajobst thinks is makes sense, or I am misunderstanding this doc: https://github.com/dotnet/designs/blob/master/accepted/2020/net5/net5.md

[nkolev92]

@zkat
Would you mind following up on this and figure out if there is any work required for .NET 5.

[zkat]

hey @lucasmeijer @terrajobst @joshpeterson!

I'd like to follow up with this (thanks Nikolche), to make sure we have a good answer while we're in the process of finalizing net5.0 TFMs in NuGet itself (what I'm working on right now!).

If anyone cares for my opinion, I like Lucas' suggestion to use net5.0 and unitytiny, because I think that would be a nicer overall experience for the ecosystem. I've spoken to some customers that seem really relieved that .NET is converging on a "single" TFM and I think Unity might want to benefit from that. :)

Anyway, we can keep hashing it out in this thread, or we can set up a meeting so we can actually talk it through. Let me know what y'all would like!

[joshpeterson]

@zkat:

Thanks for picking this up! I think we have two outstanding issues to address.

First, how to can we ensure that Unity can make additive-only changes to the TFM? The idea is encapsulated in my question above:

Suppose the unity5.0-dots profile ships with System.Collections.Generic.List, but the Count property is not included in that release. Then later on we realize "Oh no, we forgot about Count! Some users need that." So then we would like to ship an update to the TFM which includes the Count property.

This is the kind of thing we would like to be able to do. What is the best way to allow this to be possible?

Second, can or should we name the TFM to indicate what it is a proper subset of? At the moment, our unitytiny profile is a proper subset of .NET Standard 2.0. Once Unity supports .NET 5, it will be a proper subset of .NET 5. Is this relationship something we should indicate in the name of the TFM?

I'd prefer to continue the discussion here, as it might be difficult to get everyone on a call at the same time. :)

[wackoisgod]

So wanting to pick this back up as mentioned in #9999 right now we have a working TFM for the Unity DOTS profile that followes the recommended naming scheme provided here and works fine when all the projects are using this TFM, builds with no issues etc.. the issue we are running into is compatiblity with .netstandard which causes issues within the tooling.

I have the following:

LibA (netstandard 2.0) depends on LibB (Unity DOTS Profile) and the tooling complains about .netstandard 2.0 is not compatible with unitytiny2.0 and this is because of the hardcoded values as mentioned in #9999

It's not clear to me what the resolution is for us to resolve this issue, I did look into the artical mentioned in #9999 but that doesn't seem to really cover what we are trying to accomplish.

(cc @dominoFire)

[zkat]

@JonDouglas can you check that this is still planned, and if not, remove from the net 6 epic?

[wackoisgod]

@zkat I would like this to still be a thing and we are still wanting to use a custom TFM. I do think that the major blocking issue at the moment is the Issue I mentioned above which as far as I know has not been resolved (cc: @dominoFire )

[ecuzzillo]

We (Unity) would still like to do this, and we're currently blocked on shipping our Tiny targets to run on .NET Core / .NET 5 instead of mono/.NET Framework for local iteration, because we can't provide correct intellisense for Tiny in SDK-style project files. For versions bundled with a locally-installed .NET 5 SDK, we've been able to get correct Tiny intellisense by setting NetCoreTargetingPackRoot in our .csproj before importing the Sdk, but this does not work for versions that aren't bundled, and we'd like not to depend on an exact installed SDK version.

Is there any work we can contribute that would make this possible in a robust way that will keep working in successive releases?

[JonDouglas]

We recently shipped the Xamarin model for .NET 6.0 TFMs. In a previous .NET 5 spec, it was mentioned that Unity would follow the Xamarin model.

With this in mind and knowing that Unity would like to commit to this, we may need a separate proposal to include Unity moving forward for .NET 7+.

This might be something that looks like net7.0-unity or similar, but I would defer to @terrajobst on that front given the various comments above about the DOTS profile. We will need to ensure the design for precedence makes sense for the requirements above.

We have a useful tool to help understand precedence here: https://nugettools.azurewebsites.net/6.0.0-preview.3/framework-precedence

Could someone from the Unity end collaborate with us to understand these requirements further and we can work together to throw a design on https://github.com/dotnet/designs for feedback?

[xoofx]

Could someone from the Unity end collaborate with us to understand these requirements further and we can work together to throw a design on https://github.com/dotnet/designs for feedback?

We will come back to you here once we have clarified a few things on our side at Unity.

[joshpeterson]

At the moment we don't need a Unity, as things have changed on our side. We'll come back if we do need a TFM though. Thanks!