Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion AsyncLock/AsyncLock.csproj
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFrameworks>netstandard1.3;netstandard2.1</TargetFrameworks>
<TargetFrameworks>netstandard2.0;netstandard2.1;net8.0;net9.0</TargetFrameworks>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any upside to having net8.0 and net9.0 targets? I wouldn't expect there to be given there are no code changes here to use newer features.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, because there are no dependencies and no conditional compilation, probably not much benefit, but not much drawback either except for a larger nupkg file. I can remove them if you like.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also slower builds when working in the repo, as internally MSBuild invokes itself for all target frameworks.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also slower builds when working in the repo, as internally MSBuild invokes itself for all target frameworks.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a sidenote, the transitive vulnerabilities happen only because I build my test project also for .NET Framework. The best fix were to have a net462 build target.
I think there is a misperception regarding netstandardx.x These were API definition so technically there is no end of life. Problem starts only when .NET Framework starts to pull in netstandard1.x/2.0 libraries, I guess using a compatibility layer.

<RootNamespace>NeoSmart.AsyncLock</RootNamespace>
<PackageId>NeoSmart.AsyncLock</PackageId>
<GeneratePackageOnBuild>True</GeneratePackageOnBuild>
Expand Down
10 changes: 5 additions & 5 deletions UnitTests/UnitTests.csproj
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<TargetFramework>net9.0</TargetFramework>

<IsPackable>false</IsPackable>

<RootNamespace>AsyncLockTests</RootNamespace>
</PropertyGroup>

<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.2.0" />
<PackageReference Include="MSTest.TestAdapter" Version="2.0.0" />
<PackageReference Include="MSTest.TestFramework" Version="2.0.0" />
<PackageReference Include="coverlet.collector" Version="1.0.1" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.13.0" />
<PackageReference Include="MSTest.TestAdapter" Version="3.8.3" />
<PackageReference Include="MSTest.TestFramework" Version="3.8.3" />
<PackageReference Include="coverlet.collector" Version="6.0.4" />
</ItemGroup>

<ItemGroup>
Expand Down