[Feature] - Support .NET 10 now that is is out

[smaillet]

Attempts to test a Roslyn generator using this that was updated to .NET 10 is not testable as there is not .NET 10 assemblies.

[jjonescz]

reference assemblies for .net 10 are already included - https://www.nuget.org/packages/Basic.Reference.Assemblies.Net100

[matkoch]

Is it intended though that they're not part of the Basic.Reference.Assemblies package?

[jjonescz]

Ah, I don't know, that might indeed be a bug. @jaredpar?

[jaredpar]

Yes that was an oversight. I should have moved net10 into the main assembly and removed the previous lowest TFM.

Now that I'm thinking about it though, I wonder if I should be incrementing major versions when I do that. It's intended but it is a breaking change (easily fixed by just installing the TFM specific package).

[smaillet]

The biggest problem with Basic.Reference.Assemblies.Net100 is that it is NOT JUST an UBER package, it contains generally useful support of enums and extensions that DEPEND on the specific runtime packages. In particular .NET [9/10] has no corresponding value in Basic.ReferenceAssemblies.ReferenceAssemblyKind meaning we have to essentially replicate that. 😞. Both are valid and supported. I'd argue that this package should include support for ANY runtime that is still under support. ANY removal of a runtime that is no longer supported is a major version bump, and that is a point worth documenting to ensure the greatest chance of clarity.

I would NOT suggest removing the lowest TFM though as it, currently, only includes:

• .NET Standard 2.0
• .NET 4.72
• .NET 8.0

MAYBE the .NET 4.72 could be bumped to latest supported version (I avoid dependency on the old framework like the plague. If I have to, I target .NET standard 2.0 but tests can't target that as it isn't an actual runtime) But .NET8.0 is a valid runtime and still under LTS. Dropping anything from that enum is definitely a breaking change (I'd argue that adding anything is also a breaking change in most cases but is OK in this specific case)¹.

No matter what you go with there's a problem of binary compat though. The enum is defined such that Net80 has a VALUE of 0 when it should have the highest numeric value. That is, once released, the semantics of any numeric value NEVER changes, even across a breaking change major version bump. The values are immutable. It is OK to obsolete and no longer define the old value. But causes problems at the binary compat level as soon as you re-assign the value. (That is, an underlying value of 10 always means the same thing, even if it is no longer supported. The numeric value of 10 is NEVER re-used to mean anything other than what it meant when first released)²

---

¹ I recently had to deal with the problem of added enums and downlevel TFMs when using a utility library for a Roslyn analyzer. StringSplitOptions.TrimEntries does NOT exist in lower runtimes but there ARE APIs that do accept that enum. Those APIs will throw an exception at runtime if the value is not known. Using a newer SDK/Target it is known, but older runtimes it isn't. It is a HUGE PITA to have to effectively clone the full enum and then polyfill the behavior needed for older runtimes. (The fact that we have to do that at all for Roslyn analyzers, fixers and generators is a different matter but is increasingly becoming VERY painful)

² Yeah, before retiring, I used to be on the API review board for Windows [Yes, dear reader, there is such a thing and we still missed things. 🫤 ]. The immutability of symbols published was a big pain point for a LOT of teams. However, with the requirement to support MANY different SDKs and runtimes given the versioning model for the OS, it was needed.

[jaredpar]

I'd argue that this package should include support for ANY runtime that is still under support.

The initial problem I had is that I was adding every runtime to the uber package. The resulting DLL was getting quite large to the point it was making a measurable impact on a few projects build output size. Hence I went with the current approach of keeping only a subset of the runtimes.

I'd argue that this package should include support for ANY runtime that is still under support.

It's a trade off problem. Every runtime increases the size of the DLL by ~2MB. Given that there are times, like now, where three runtimes are in active support it's about a 25% increase in size. Probably not the end of the world. If size is the constraint then you can always grab the TFM specific packages.

No matter what you go with there's a problem of binary compat though. The enum is defined such that Net80 has a VALUE of 0 when it should have the highest numeric value.

I agree there are a few binary compat problems here. Much of this project grew up organically based on need. It was solving some dotnet/roslyn problems plus a few other repos we worked on. I never really sat down and thought about long term binary compat issues cause I didn't really expect there to be as much uptake as there has been in the project.

I will probably sit down and think about this for a 2.0 style release at some point in the near future.

[FS-FrankLakmann]

Hello,
first of all thank you for your work. Without the Basic.Reference.Assemblies package our roslyn shenanigans would be a lot harder. But now we need to be able to target the dotnet 8 or dotnet 10 runtime for our DLL generator.
I made the adjustments locally and rebuild the package. The size went up from 16362 KB to 17898 KB, so just 9%.
Please reconsider and include dotnet10.

[jjonescz]

@FS-FrankLakmann have you considered using https://www.nuget.org/packages/Basic.Reference.Assemblies.Net80 and https://www.nuget.org/packages/Basic.Reference.Assemblies.Net100 directly?

[FS-FrankLakmann]

We would like to have just a constant name for the reference includes with just the version changing between branches in the one central Directory.package.props file. CPM is really great if you have to maintain legacy servicing branches. Your suggestion would break that. But having a few conditional Itemgroups in there is ok I guess.