I don't have .NET 7.0 SDK installed anymore, since I've moved my projects off to .NET 8.0. CSharpier_FrameworkVersion sometimes incorrectly resolves to .NET 7.0 due to unreliable heuristics:
|
<CSharpier_FrameworkVersion Condition="'$(CSharpier_FrameworkVersion)' == ''">$(TargetFramework)</CSharpier_FrameworkVersion> |
|
<CSharpier_FrameworkVersion Condition="'$(CSharpier_FrameworkVersion)' != 'net6.0' and '$(CSharpier_FrameworkVersion)' != 'net7.0' and '$(CSharpier_FrameworkVersion)' != 'net8.0'">net7.0</CSharpier_FrameworkVersion> |
The two most common scenarios are:
- The project is a library that targets .NET Standard 2.1, but .NET 8.0 SDK is used to build it.
- The project is targeting a superset of .NET 8.0, for example
net8.0-windows.
In either of these cases, CSharpier resolves to the .NET 7.0 version of the tool, which may not be able to execute (as in my case).
My suggestion is to not rely on the TargetFramework property for this, but instead use the current SDK version, which can be extracted from the NETCoreSdkVersion property, as defined by one of the built-in imports.

I don't have .NET 7.0 SDK installed anymore, since I've moved my projects off to .NET 8.0.
CSharpier_FrameworkVersionsometimes incorrectly resolves to .NET 7.0 due to unreliable heuristics:csharpier/Src/CSharpier.MsBuild/build/CSharpier.MsBuild.targets
Lines 3 to 4 in ef79538
The two most common scenarios are:
net8.0-windows.In either of these cases, CSharpier resolves to the .NET 7.0 version of the tool, which may not be able to execute (as in my case).
My suggestion is to not rely on the
TargetFrameworkproperty for this, but instead use the current SDK version, which can be extracted from theNETCoreSdkVersionproperty, as defined by one of the built-in imports.