Suggestion: modernize the project files and generate the package with dotnet pack

[lahma]

Nobody asked for this — it came out of dogfooding the repo's build while working on something else. Offering it as a suggestion rather than a fix: each piece stands alone, and I'd rather have the argument for why out in the open than just hand over a diff. Happy for any part to be dropped.

Suggestion 1: let dotnet pack generate the package instead of the hand-written nuspec

Why. src/AngleSharp.Js.nuspec has quietly drifted from what the project builds. It declares dependency groups for net6.0 and net7.0, which aren't built, and has no group for net10.0, which is shipped. Nothing is visibly broken — net10.0 consumers fall back to the net8.0 group — but the file has to be hand-edited every time TargetFrameworks changes, and it hasn't been.

The benefit is that this class of drift stops being possible. The dependency groups get generated from TargetFrameworks, so adding or removing a target updates the package automatically. Versions stop being duplicated between the csproj and the nuspec. And the .pdb files move out of lib/ and into the .snupkg, which is where symbols are meant to live.

Evidence, since swapping the packaging of a published library deserves more than assurances. I built the package on devel and on this branch and diffed them. Identical file listings. The only nuspec differences are the intended ones: net10.0 added, dead net6.0/net7.0 removed, repository now carrying branch and commit, and owners / requireLicenseAcceptance dropped (both deprecated; requireLicenseAcceptance defaults to the same value). Dependency ranges are preserved exactly — AngleSharp [1.5.0, 2.0.0), Jint [4.15.3, 5.0.0) — as is assembly identity: Version=1.0.0.0, PublicKeyToken=e83494dcdc6d31ea, same FileVersion, InformationalVersion, InternalsVisibleTo key and ComVisible.

One sharp edge worth flagging, because I walked into it. Pack publishes the reference version verbatim, so expressing AngleSharp as a float (1.*) silently turned the published range into an unbounded >= 1.6.0 and lost the 2.0 ceiling. AngleSharpVersion is now the floor, with Directory.Packages.props building [$(AngleSharpVersion),2.0.0) around it — so the ceiling holds even when CI overrides the floor, and ci.yml needed no change (it's GitBase-synced, so leaving it alone seemed right).

Suggestion 2: drop Microsoft.SourceLink.GitHub

Why. SourceLink has shipped in the .NET SDK since 8.0.100; the 8.0.0 package is a no-op there.

The benefit is one less dependency to track for zero behaviour change — the repository metadata still lands in the package, which the diff above confirms.

Suggestion 3: move the test project to net10.0, and untangle what it actually tests

Why. net8.0 goes out of support in November 2026. But the more interesting find: the ProjectReference to the library was pinned to <TargetFramework>netstandard2.0</TargetFramework>, so every test ran against the netstandard2.0 build regardless of which framework the tests targeted. The net8.0 and net10.0 library builds were compiled and never executed.

The benefit is that tests now exercise the build they ship against, which is the whole point of multi-targeting. 243 tests pass on all three test targets.

The trade-off, stated plainly: the library still ships a net8.0 target, and with the test project on net10.0 only, that target is compiled but not tested. It wasn't tested before either, so this is not a regression — but if you'd prefer net8.0;net10.0 on the test project, that's a one-line change and I'll make it.

Suggestion 4: smaller consistency cleanups

Each of these is independent, and the benefit in every case is "one source of truth instead of two":

• Central Package Management (src/Directory.Packages.props). Versions were spread across two csproj files and the nuspec — which is how the nuspec drifted in the first place.
• Four orphaned ProjectConfiguration blocks removed from the .sln, for project GUIDs that aren't declared in the solution. (This started as a .slnx conversion; reverted in ce2bb37 per review — the format change wasn't worth narrowing the tooling contributors can use, so only the dead blocks go.)
• Both AssemblyInfo.cs files folded into the csproj. They claimed Copyright © AngleSharp, 2013-2019 while the nuspec said 2017-2026; the assembly and package now agree.
• CHANGELOG.md becomes the single version authority. It was already parsed for the package version; it is now also passed to the build as -p:Version, so <Version> in Directory.Build.props is just the fallback for builds that bypass the NUKE script. (I first pinned AssemblyVersion to 1.0.0.0 here to protect the strong-name identity — dropped in f6fbd93 after checking that published AngleSharp bumps it every minor, so the pin would have had the two packages following opposite policies. The built assembly is 1.0.0.0 either way.)
• ContinuousIntegrationBuild in CI, via .SetContinuousIntegrationBuild(IsServerBuild) in nuke/Build.cs — the mechanism the core repo already uses. Without it the published symbols carry the build agent's absolute paths, which is why nuget.info flags beta.137 as non-deterministic.
• DelaySign=false removed. Conditioned on Windows, and false is the default everywhere — it never did anything.
• global.json added. Withdrawn in c9db87e — the absence is deliberate and the repo should not restrict the SDK version. AGENTS.md now says so explicitly, since the line I read as describing a gap was actually describing a decision.
• NUKE 10.0.0 → 10.1.0, and the NuGet.CommandLine download dropped now that pack and push both go through dotnet.
• AGENTS.md updated where it describes things this changes.

Verification

Clean Package end to end with CI's exact invocation (-AngleSharpVersion 1.5.0): 243 tests pass on net10.0, net462 and net472, package and symbol package produced, zero warnings with TreatWarningsAsErrors on.

Deliberately not done

• NUnit stays on 3.14.0. NUnit 4 moves the classic asserts to ClassicAssert, touching all 28 test files. That's a separate PR, if it's wanted at all.
• ci.yml still uses echo "::set-output name=...", which GitHub has disabled. It looks broken, but it's in the GitBase-synced set, so the fix belongs upstream rather than here.

---

🤖 Generated with Claude Code

[FlorianRappl]

Suggestion 1 is a contradiction. On the one hand it claims that the generated NuGet package had the right version range, on the other hand it brought up "1.*" which should not be there at all if the right variable would have been introduced.

As it stands both ways (directly via dotnet and from a nuspec via nuget) are, unfortunately, not equivalent. I wish the .NET team gets their stuff together and allow to specify all items of a nuspec within the csproj.

[FlorianRappl]

Some of the changes are fine - even though I would not love to see them in isolation. Either we update all repositories or none. The last thing I want is inconsistency.

However, in general any change that does not bring a clear benefit and has drawbacks (e.g., migration to slnx - this is certainly the right step but I don't see a clear benefit to just change it) is not desired.

[lahma]

Thanks — both fair hits. Taking them in order.

The 1.* contradiction

You're right, and it's my write-up that was contradictory rather than the change. Two different states got described as though both were in the PR.

1.* was already in devel's csproj as <AngleSharpVersion>1.*</AngleSharpVersion>. It was harmless there precisely because the nuspec hardcoded [1.5.0,2.0.0) independently — the float never reached the package. The moment pack derives the range from the reference, that float becomes load-bearing and silently publishes >= 1.6.0. I hit that, fixed it, and then narrated the discovery in the description, which made it read as if the float were still in the proposal. It isn't.

What's actually in the branch: AngleSharpVersion is the floor (1.5.0), and Directory.Packages.props builds the range around it, so the ceiling can't be lost even when CI overrides the floor:

<PackageVersion Include="AngleSharp" Version="[$(AngleSharpVersion),2.0.0)" />

On the two routes not being equivalent

Agreed as a general statement — pack genuinely cannot express everything a nuspec can, and I'm not going to argue otherwise. What I can offer is the measured delta for this package, since that's the only part that decides whether it matters here.

I built Package on devel and on this branch with CI's exact invocation (-AngleSharpVersion 1.5.0) and diffed the two generated nuspecs. devel on the left (CopyFiles + NuGetPack over the checked-in nuspec), this branch on the right (dotnet pack):

     <id>AngleSharp.Js</id>
     <version>1.0.0</version>
     <authors>AngleSharp</authors>
-    <owners>Florian Rappl</owners>
-    <requireLicenseAcceptance>false</requireLicenseAcceptance>
     <license type="expression">MIT</license>
     <licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
     <icon>logo.png</icon>
@@
     <releaseNotes>https://github.com/AngleSharp/AngleSharp.Js/blob/master/CHANGELOG.md</releaseNotes>
     <copyright>Copyright 2017-2026, AngleSharp</copyright>
     <tags>html html5 css css3 dom javascript scripting library js scripts runtime jint anglesharp angle</tags>
-    <repository type="git" url="https://github.com/AngleSharp/AngleSharp.Js" />
+    <repository type="git" url="https://github.com/AngleSharp/AngleSharp.Js" branch="refs/heads/modern-csproj" commit="130af450a762ebb77d5dfd4b4bcf141d431c9fb5" />
     <dependencies>
-      <group targetFramework=".NETStandard2.0">
-        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" />
-        <dependency id="Jint" version="[4.15.3, 5.0.0)" />
+      <group targetFramework="net10.0">
+        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" exclude="Build,Analyzers" />
+        <dependency id="Jint" version="[4.15.3, 5.0.0)" exclude="Build,Analyzers" />
       </group>
       <group targetFramework=".NETFramework4.6.2">
-        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" />
-        <dependency id="Jint" version="[4.15.3, 5.0.0)" />
+        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" exclude="Build,Analyzers" />
+        <dependency id="Jint" version="[4.15.3, 5.0.0)" exclude="Build,Analyzers" />
       </group>
       <group targetFramework=".NETFramework4.7.2">
-        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" />
-        <dependency id="Jint" version="[4.15.3, 5.0.0)" />
-      </group>
-      <group targetFramework="net6.0">
-        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" />
-        <dependency id="Jint" version="[4.15.3, 5.0.0)" />
-      </group>
-      <group targetFramework="net7.0">
-        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" />
-        <dependency id="Jint" version="[4.15.3, 5.0.0)" />
+        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" exclude="Build,Analyzers" />
+        <dependency id="Jint" version="[4.15.3, 5.0.0)" exclude="Build,Analyzers" />
       </group>
       <group targetFramework="net8.0">
-        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" />
-        <dependency id="Jint" version="[4.15.3, 5.0.0)" />
+        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" exclude="Build,Analyzers" />
+        <dependency id="Jint" version="[4.15.3, 5.0.0)" exclude="Build,Analyzers" />
+      </group>
+      <group targetFramework=".NETStandard2.0">
+        <dependency id="AngleSharp" version="[1.5.0, 2.0.0)" exclude="Build,Analyzers" />
+        <dependency id="Jint" version="[4.15.3, 5.0.0)" exclude="Build,Analyzers" />
       </group>
     </dependencies>

So the entire non-equivalence, for this package, is four things:

Difference	Assessment
owners dropped	Deprecated by NuGet; nuget.org ignores it in favour of account ownership. Your call whether that's a loss.
requireLicenseAcceptance dropped	Omission and false are the same thing to NuGet.
repository gains branch + commit	Gain — this is SourceLink working without the package.
exclude="Build,Analyzers" added	Standard pack output; it spells out the default PackageReference asset behaviour rather than changing it.

And the substantive part: the checked-in nuspec declares net6.0 and net7.0, which aren't built, and no net10.0, which is shipped. That's the drift I'd want to fix; net10.0 consumers currently resolve against the net8.0 group.

Dependency ranges come out byte-identical — [1.5.0, 2.0.0) and [4.15.3, 5.0.0). So does everything else in the package:

$ diff <(cd devel-pkg && find . -type f | sort) <(cd dotnet-pack-pkg && find . -type f | sort)
16c16
< ./package/services/metadata/core-properties/8ea1fcb73d824bff8dbd66c842f651d2.psmdcp
---
> ./package/services/metadata/core-properties/9295664c72984b799687dd3d31f835cf.psmdcp

That's the per-pack random OPC metadata name — every lib/ entry, logo.png, and README.md matches. Assembly identity is also unchanged, which was the thing I most wanted to be sure of given the strong naming:

devel      AngleSharp.Js, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea
this PR    AngleSharp.Js, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea

FileVersion, InformationalVersion, the InternalsVisibleTo public key and ComVisible all match too. The one deliberate difference is AssemblyCopyright, which read Copyright © AngleSharp, 2013-2019 in AssemblyInfo.cs while the nuspec said 2017-2026; they now agree on the latter.

If owners or any other nuspec-only field is something you want to keep, then the nuspec route is the right call and Suggestion 1 should just be dropped — the rest of the PR doesn't depend on it.

slnx

Reverted in ce2bb37 — you're the one who has to live with the contributor surface, and "not much benefit right now" is hard to argue with when the only concrete gain was four dead config blocks.

Those I kept, as a plain .sln edit. They were ProjectConfiguration entries for four project GUIDs that aren't declared in the solution at all, so the diff against devel is just their removal and nothing else.

[lahma]

On a bit parallel note, I dropped NUKE in my own projects already in favor of https://fallout.build/ . Pretty easy migration and fixed the pain that I had about the old GitHub Actions versions and also vulnerable dependencies.

[FlorianRappl]

The four dead blocks we can also remove right now - it does not justify a transition (and removing those dead blocks would be appreciated anyway).

The other thing is all fine to me - thanks for the showing the diff. Now the only thing to stands between merging this is consistency. I think this way would work for all (exceptions apply) AngleSharp repositories (Css, Io, Xml, Renderer) - we only would need to check the core repository (AngleSharp). My guess is that it would work there, too - but here we need to be a bit more cautious to achieve alignment.

Regarding Fallout: Yes, we can migrate (sounds fine to me as NUKE is unfortunately dead) but here again I'd prefer a consistent solution (i.e., must be applied to the other repositories in the AngleSharp organization, too). The old mechanism with the GitBase repo (https://github.com/AngleSharp/AngleSharp.Infrastructure.GitBase) is anyway dead; so this one can be ignored.

[lahma]

Maybe I'll try a run for a draft PR against main AngleSharp repo and we can check the package diffs. The ContinuousIntegrationBuild = true should for example fix the warning on NuGet package explorer: https://nuget.info/packages/AngleSharp.Js/1.0.0-beta.137 .

Fallout migration is not that complex, I even developed a Claude skill for that purpose. But I guess that would be a separate PR, if wanted.

[FlorianRappl]

Yes, let's keep it separate. I think the migrate script should be enough (as its a hard-fork I only expect namespaces + package names to change; code can remain as-is).

[lahma]

Did the core repository run: AngleSharp/AngleSharp#1272 (draft, with the package diff).

It works there, and the delta is smaller than here — the nuspec's only drift was two dead groups (net6.0, net7.0); net10.0 was already declared. System.Text.Encoding.CodePages comes out on exactly the three TFMs whose condition selects it, generated from the csproj rather than restated by hand. Identical file listing, unchanged assembly identity at 1.7.0.0, 3741 tests green on net10.0/net462/net472 in both prefetched modes.

Two things the core repo does better than what I had here, both now fixed in f6fbd93:

1. AssemblyVersion. I had pinned it to 1.0.0.0 here, reasoning that a CHANGELOG-driven version would otherwise shift the strong-name identity every minor. Then I checked what AngleSharp actually publishes:

published 1.5.0 -> AngleSharp, Version=1.5.0.0, PublicKeyToken=e83494dcdc6d31ea
published 1.6.0 -> AngleSharp, Version=1.6.0.0, PublicKeyToken=e83494dcdc6d31ea

So the house policy is the opposite of my pin, and keeping it would have left the two packages following contradictory rules. Pin dropped; <Version> is back as the fallback for builds that bypass the NUKE script, matching the core layout. The built assembly is 1.0.0.0 either way, so nothing changes for this release.

2. Determinism. You had this right already in the core repo — nuke/Build.cs there does .SetContinuousIntegrationBuild(IsServerBuild) on Compile. I had gated it on the GITHUB_ACTIONS environment variable in Directory.Build.props instead. The core repo's approach is better: NUKE's host detection is not tied to one CI provider, and it keeps the decision in the build script rather than in MSBuild.

The published symbols show it working. AngleSharp 1.6.0:

total documents      : 703
mapped '/_/'         : 692
mapped '/_1/'        : 11     (the Nullable package's contentFiles, a second source root)
ABSOLUTE (has ':\')  : 0

AngleSharp.Js 1.0.0-beta.137, which has no such call:

total documents      : 53
ABSOLUTE             : 53
sample: D:\a\AngleSharp.Js\AngleSharp.Js\src\AngleSharp.Js\Cache\CreatorCache.cs
SourceLink: {"documents":{"D:\\a\\AngleSharp.Js\\AngleSharp.Js\\*":"https://raw.githubusercontent.com/..."}}

That D:\a\<repo>\<repo> is the Actions Windows runner workspace. Note SourceLink is present and working in that package — it just anchors the substitution on the absolute runner prefix, which is why source stepping works while nuget.info still reports it as non-deterministic. Two independent checks; only the path normalisation was missing.

This branch now uses the core repo's mechanism, verified by building with the Actions host detected:

netstandard2.0 : mapped=52/52  absolute=0
net10.0        : mapped=52/52  absolute=0
net462         : mapped=52/52  absolute=0

Package metadata and dependency ranges are byte-identical to the previous state of this branch apart from the SourceLink commit hash, so neither change moves the package.

Dead solution blocks — already done in ce2bb37, as a plain .sln edit with the .slnx conversion reverted. Diff against devel is just those 16 lines.

On the remaining repositories (Css, Io, Xml, Renderer): happy to do them, but I would rather land these two first so there is an agreed shape to copy, and only one review of the argument. One thing that will recur — moving a test project to net10.0 raises it to the .NET 10 AnalysisLevel, and in the core repo that surfaced CA2022 in two places that ignored a Stream.Read return value. Fixed rather than suppressed there, but it means each repo may need a small code fix alongside the build change rather than being purely mechanical.

Fallout: agreed it is a separate change, and agreed it should go across the organisation at once. Not touched here.

[FlorianRappl]

Great 🚀 !