net10.0 only for 20.1.2.2+ ?

[xoofx]

Hey,
I tried to update ClangSharp dependency to latest 20.1.2.3 for CppAst and it is breaking my build as it is now requiring net10.0 while prior version were fine with net8.0:

• 20.1.2.2+: net10.0
• 20.1.2.1: net8.0

It is also a bit unfortunate that such a breaking change is happening on a patch version.

I see that issue #632 is mentioning this, but this is a different issue. I'm using the ClangSharp low level library, not the pinvoke generator.

Could the library be reverted to net8.0?

[tannergooding]

It is also a bit unfortunate that such a breaking change is happening on a patch version.

There were no breaking changes to the ClangSharp API surface. It was, for its own purposes, a patch update and simply updating its own dependencies to their latest versions. .NET 10 remains compatible with .NET 8 libraries and projects.

ClangSharp likewise doesn't follow "semver" or anything like that. It simply matches the underlying version of libClang (which likewise doesn't really follow semver) and increments the last version for each incremental update to its functionality.

There really is no "good way" to version libraries in a way that correctly conveys dependency changes like this. With modern .NET and the longstanding high compat bar it has, moving from version to version is meant to be "trivial" and essentially error free. You can essentially view it as just a patch for many apps/libraries.

Could the library be reverted to net8.0?

.NET 8 doesn't have the required tooling features that are necessary to deploy correct RID dependent packages. The support ClangSharp had been using was hacky and error prone. There have been dozens of issues with users reporting pain from this, particularly on Linux.

.NET 10 rectified this and so moving forward allowed fixing several longstanding issues. However, it fundamentally requires the .NET 10 SDK for the new package options to work.

Adding back .NET 8 would bring back the broken and error prone experience for users.

[xoofx]

.NET 10 remains compatible with .NET 8 libraries and projects.

I'm not sure to follow. When I reference ClangSharp now from a .NET 8 library, it fails to install the NuGet package because it only provides .NET 10 assemblies (even if the API surface hasn't changed). The confusing part was that everything was compiling fine with 20.1.2.1 and then suddenly it failed on following versions. Maybe the NuGet should have been marked in preview...

But ok, fair enough. I will wait for .NET 10 to be fully final before making an upgrade.

.NET 10 rectified this and so moving forward allowed fixing several longstanding issues. However, it fundamentally requires the .NET 10 SDK for the new package options to work.

Do you have a link to what is fixed and how NuGet packaging is affected with runtime assemblies? I would like to understand if I can start to use them as well.

[tannergooding]

I'm not sure to follow.

It's the other way. .NET 8 libraries can roll forward and be consumed from .NET 10 projects.

The statement was one that .NET 10 isn't some "from the ground up rewrite" or anything. It's the same overall product and codebase that's been maintained for 25 years now and .NET 10 is largely incremental fixes and improvements on top of the prior release.

You can, outside of subtle dependence on behavioral bugs, generally expect that upgrading to .NET 10 should be quick and painless. Typically providing better performance, stability, and additional features for use.

Maybe the NuGet should have been marked in preview...

There's nothing preview about it. .NET 10 is considered "go live" and supported for use in production, as is typical for .NET RCs and for quite a lot of other software across the industry (not just .NET and not just Microsoft).

There's unfortunately not a good way to version this and normally I wouldn't have dropped .NET 8 support, I'd have added .NET 10 support and multi-targeted. However, the longstanding tooling issues for RID specific deployment ClangSharp has had for nearly 10 years were finally fixable and require the .NET 10 SDK. Dropping .NET 8 was required to avoid another year of user reports of the problems.

Do you have a link to what is fixed and how NuGet packaging is affected with runtime assemblies? I would like to understand if I can start to use them as well.

The relevant docs are being worked on, but the example repo is: https://github.com/baronfel/multi-rid-tool. It shows how you can take advantage of the new features to create RID specific .NET tools so that you can deploy them for NAOT compilation or with RID specific dependencies.

[xoofx]

The statement was one that .NET 10 isn't some "from the ground up rewrite" or anything. It's the same overall product and codebase that's been maintained for 25 years now and .NET 10 is largely incremental fixes and improvements on top of the prior release.
You can, outside of subtle dependence on behavioral bugs, generally expect that upgrading to .NET 10 should be quick and painless. Typically providing better performance, stability, and additional features for use.

Oh, yeah, didn't imply that. But when a library you depend on bump there minimum .NET framework version, it has a cascading effect for all NuGet dependencies.

For example, in my case, an upgrade of Clangsharp to .NET 10 requires me to update dozens of projects transitively:

ClangSharp <- CppAst <- CppAst.CodeGen <- Dozens+ of projects using it.

I know it's not your problem, but I would not qualify this is as "painless" ☺️

The relevant docs are being worked on, but the example repo is: https://github.com/baronfel/multi-rid-tool. It shows how you can take advantage of the new features to create RID specific .NET tools so that you can deploy them for NAOT compilation or with RID specific dependencies.

Hm, I'm confused. I'm not using the tool and my problem here is the change in the Clangsharp library. But do you mean that in order for the Clangsharp NuGet package to be compatible with multi-RID .NET tools you had to bump it as well? What are the RID features there that you rely on that are only accessible from .NET 10?

[tannergooding]

Hm, I'm confused. I'm not using the tool and my problem here is the change in the Clangsharp library.

Ah sorry, I see. I read this in the first post and guess my brain just didn't fully process it yet. Too much going on across all the repos 😅

I think I could still have the libraries (ClangSharp and ClangSharp.Interop) multi-target .NET 8, yes. The command line tool (ClangSharpPInvokeGenerator) must target .NET 10, however.

What are the RID features there that you rely on that are only accessible from .NET 10?

ClangSharp.Interop depends on libClangSharp which uses the undocumented RID specific package feature. There isn't an officially documented way to do RID specific packages for libraries yet, just the new way for tools added in .NET 10.

[xoofx]

I think I could still have the libraries (ClangSharp and ClangSharp.Interop) multi-target .NET 8, yes. The command line tool (ClangSharpPInvokeGenerator) must target .NET 10, however.

Ah, cool, that would be great! Thank you!

[tannergooding]

Published v20.1.2.4