28e3f79 drops support for net9 breaking the build for those who didn't upgrade yet

[Baklap4]

28e3f79 drops support for net9.
This breaks builts using net9 which did not yet upgrade to net10 or downgraded to net8

It'd be nice to revert this change up until net9 is actually EOL which should be around: November 10, 2026 -> https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle

[stefanloerwald]

Hi @Baklap4

This is infeasible due to size restrictions of the nuget package. Please either upgrade to .net10, or pin the latest version of webcompiler to stay on a .net9 compatible release.

[Baklap4]

For people running into this problem:

Automation

For people using automation tools like Gitlab Pipelines or Github:
dotnet tool update Excubo.WebCompiler --version 4.0.33

Pinning version

For people wanting to pin the version provide a file .config/dotnet-tools.json
and pin the correct version in there:

{
  "version": 1,
  "isRoot": true,
  "tools": {
    "excubo.webcompiler": {
      "version": "4.0.33",
      "commands": [
        "webcompiler"
      ],
      "rollForward": false
    }
  }
}

With dotnet tool restore this version will now be restored.

If you have nested dotnet-tools.json files in your repository update them all accordingly

thanks for the quick response @stefanloerwald i'll close this item.

Other Notes

I'm not that familiar with how the project is bundled up in nuget, but it might be good to look into how to compress/decrease the size of the package to allow for more frameworks to support.
As far as i can see all the runtimes per .net version are added within the package for:

• linux-arm
• linux-arm64
• linux-x64
• osx-arm64
• osx-x64
• win-arm64
• win-x64
• win-x86

Since every runtime is bundled with the ClearScript.V8.Native binary dependency this adds up quite a bit eventually reaching the 500MB limit on nuget.

A couple of ways to counter this could be:

• Split the project into platform specific packages
  • excubo.webcompiler.core
  • excubo.webcompiler.win
  • excubo.webcompiler.osx
  • excubo.webcompiler.linux
• Multi-RID packaging -> but this will have as side effect multiple packages: 1 package per RID
• Externally download the ClearScript binary during runtime. This is how PuppeteerSharp handled it

Might be good to pick this up in another issue if this is what you'll want for the future of this package.

[stefanloerwald]

Thank you for the detailed write-up. I agree that it's suboptimal to ship such a large package, but several packages that are platform specific also have the downside of then tying a project to a platform.

I'm not planning any changes on this for now, as supporting two LTS releases is a decent setup in my opinion and lands just below the threshold for package size so far.