Add netstandard2.0 target framework to eliminate NU1701 fallback to net48

[jmbryan4]

Problem

StrongGrid 0.114.0 ships with two target frameworks: net48 and netstandard2.1. When a netstandard2.0 consumer references StrongGrid, NuGet cannot find a compatible TFM and falls back to the net48 build. This produces:

• NU1701 warning: "Package 'StrongGrid 0.114.0' was restored using '.NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project."
• The net48 build pulls in System.Net.Http 4.2.0.0 (.NET Framework), which conflicts with the netstandard2.0 reference assembly version (4.1.2.0), potentially causing MSB3277 assembly conflicts at build time or runtime issues.

The problem is compounded by StrongGrid's transitive dependency on HttpMultipartParser 9.1.0, which also only ships net48 + netstandard2.1. This means netstandard2.0 consumers see two NU1701 warnings — one for StrongGrid itself and one for HttpMultipartParser pulled in transitively.

Real-world scenario

I use StrongGrid in a shared netstandard2.0 class library that is consumed by both a .NET Framework 4.8 application and a .NET 8 application. Because StrongGrid lacks a netstandard2.0 TFM, NuGet falls back to the net48 build in that shared library, producing warnings and pulling in incompatible assembly versions.

Repro

# 1. Published 0.114.0 only has net48 + netstandard2.1
curl -sL https://api.nuget.org/v3-flatcontainer/stronggrid/0.114.0/stronggrid.0.114.0.nupkg -o /tmp/sg.nupkg
unzip -l /tmp/sg.nupkg | grep "lib/"
#   lib/net48/StrongGrid.dll
#   lib/netstandard2.1/StrongGrid.dll
# → No netstandard2.0

# 2. Create a minimal netstandard2.0 consumer
mkdir /tmp/sg-test && cd /tmp/sg-test
dotnet new classlib -f netstandard2.0
dotnet add package StrongGrid --version 0.114.0
dotnet build
# → warning NU1701: Package 'StrongGrid 0.114.0' was restored using
#   '.NETFramework,Version=v4.8' instead of '.NETStandard,Version=v2.0'
# → warning NU1701: Package 'HttpMultipartParser 9.1.0' was restored using
#   '.NETFramework,Version=v4.8' instead of '.NETStandard,Version=v2.0'

If you have dotnet-inspect installed, you can also confirm the TFM gap and the problematic assembly reference:

dotnet-inspect library --package StrongGrid@0.114.0 --tfm netstandard2.0 --references
# Error: No library found for TFM 'netstandard2.0'. Available TFMs: netstandard2.1, net48

dotnet-inspect library --package StrongGrid@0.114.0 --tfm net48 --references
# → System.Net.Http | 4.2.0.0  (conflicts with ns2.0's 4.1.2.0)

A full self-contained repro script is included in the linked PR.

Proposed fix

Add netstandard2.0 to TargetFrameworks in StrongGrid.csproj. The required changes are minimal:

1. StrongGrid.csproj: Add netstandard2.0 to <TargetFrameworks>. Suppress the transitive NU1701 from HttpMultipartParser on the netstandard2.0 TFM (since HttpMultipartParser itself only ships net48 + netstandard2.1, but its net48 fallback is safe).
2. WebhookParser.cs: Widen #if NETSTANDARD2_1 to #if NETSTANDARD2_0_OR_GREATER for the CodePagesEncodingProvider registration (needed on netstandard2.0 too).
3. Public.cs: Widen #elif NET48_OR_GREATER || NETSTANDARD2_1 to #elif NET48_OR_GREATER || NETSTANDARD2_0_OR_GREATER for the ECDSA signature verification path.

After the fix, netstandard2.0 consumers get the proper netstandard2.0 build — the StrongGrid NU1701 is eliminated entirely. The HttpMultipartParser NU1701 remains (that's a separate upstream issue), but it's suppressed within StrongGrid's own build so consumers only see it if they reference HttpMultipartParser directly.

[Jericho]

Thanks for the detailed description of the scenario. I definitely want to avoid assembly conflicts/confusion so adding netstandard2.0 sounds like a reasonable solution if it indeed solves this problem.

Adding this new target means developers could use this library with net 4.6.1+ (instead of only 4.8). I previously was resistant to do this because I didn't want to be on the hook for supporting older framework version which I don't even have installed on my machine anymore. If/when your PR is merged, I'll have to be ready to install older frameworks if a support scenario comes in and we suspect it might be specific to one of those older frameworks.

[Jericho]

The problem is compounded by StrongGrid's transitive dependency on HttpMultipartParser 9.1.0, which also only ships net48 + netstandard2.1.

I maintain the HttpMultipartParser library. I can make the same changes in that project so the targeted frameworks are in line with the targets in this project and therefore eliminating this problem.

[jmbryan4]

I did not realize that. That would be ideal. It would eliminate the transitive NU1701 entirely and remove the need for the NoWarn workaround.

I suggest netstandard2.0 and net8.0 for HttpMultipartParser as well, same as this project. netstandard2.0 replacing the explicit net48 target for legacy or .NET Framework, and net8.0 for modern target and optimized code paths.

That keeps both libraries on the same target matrix and cleans up the dependency chain.

[Jericho]

Give me 24hrs to update and publish HttpMultipartParser. Following that, you'll be able to update your PR to target the new parser version and get rid of the nowarn.