Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove .NET Standard 1.x dependencies and cleanup #6403

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented Apr 17, 2023

  1. Avoid .NET Standard 1.x dependencies in the repository completely. The remaining test package dependency that brings netstandard1.x is FakeItEasy. For that one, upgrade the transitive Castle.Core dependency to 5.x. I also opened an issue in FakeItEasy to discuss upgrading the Castle.Core dependency. This results in the repository not being affected by CVEs / vulnerable packages like System.Private.Uri that are part of the .NET Standard 1.x dependency graph. (cc @MichaelSimons, @mmitche, @ericstj)
  2. Upgrade projects that use "System.Runtime.Loader" from netstandard2.0 to .NETCoreApp as that API is only availble on .NETCoreApp anyway but keep the netstandard2.0 TFM. The package that was used hasn't shipped for years anymore and was never intended to be used on .NET Standard (support for it was later removed). Because of that, new nullable reference type errors were raised by the compiler which I suppressed temporarily by downgrading the Nullable property to "annotations".
  3. Clean-up code files
    • Use consistent indentation
    • Empty lines after Project and before closing tag
    • Empty lines between Property/Item groups
    • Remove unused msbuild properties
    • Delete unused or non-necessary files (i.e. Build.props).
    • Remove unnecessary "<?xml" and "ToolsVersion" tags in files that don't need them (msbuild).
    • Define Newtonsoft.Json package version in Packages.props instead of hardcoding it where it is used.
    • Use the implicitly (by the SDK) defined #if NETFRAMEWORK compiler preprocessor directive instead of a custom "NETFULL" one.
    • Remove one "#nullable enable" statement that wasn't necessary anymore as all projects that included the source file already enabled nullable.
  4. Use floating TFM version that is defined in Arcade: "NetCurrent"
  5. For the .NET Framework TFM msbuild property, use the same nomenclature as in other repos.
  6. Do not define a floating TFM msbuild property for netstandard2.0 as that TFM will never change to a higher version.
  7. Change how the live Microsoft.NETCore.App targeting/runtime pack is upgraded in this repository to allow previous TFMs to be targeted as well (for msbuild tasks).
  8. Remove the "PackSpecific" msbuild property and its conditions as .NET Framework assets can be built and packaged on Unix machines these days with the dynamic reference on .NET Framework targeting packs.

@ViktorHofer ViktorHofer requested a review from a team as a code owner April 17, 2023 09:06
@ViktorHofer ViktorHofer self-assigned this Apr 17, 2023
@ViktorHofer ViktorHofer force-pushed the NetStandard1xDepRemovalAndCodeStyling branch from 4f32c9c to 2c4e447 Compare April 17, 2023 14:39
1. Avoid .NET Standard 1.x dependencies in the repository completely.
   The remaining test package dependency that brings netstandard1.x is
   FakeItEasy. For that one, upgrade the transitive Castle.Core
   dependency to 5.x. I also opened an issue in FakeItEasy to discuss
   upgrading the Castle.Core dependency.
   This results in the repository not being affected by CVEs /
   vulnerable packages like System.Private.Uri that are part of the .NET
   Standard 1.x dependency graph.
2. Upgrade projects that use "System.Runtime.Loader" from netstandard2.0
   to .NETCoreApp as that API is only availble on .NETCoreApp anyway.
   The package that was used hasn't shipped for years anymore and was
   never intended to be used on .NET Standard (support for it was later
   removed). Because of that, new nullable reference type errors were
   raised by the compiler which I suppressed temporarily by downgrading
   the Nullable property to "annotations".
3. Clean-up code files
   - Use consistent indentation
   - Empty lines after Project and before closing tag
   - Empty lines between Property/Item groups
   - Remove unused msbuild properties
   - Delete unused or non-necessary files (i.e. Build.props).
   - Remove unnecessary "<?xml" and "ToolsVersion" tags in files that don't need them
     (msbuild).
   - Define Newtonsoft.Json package version in Packages.props instead of
     hardcoding it where it is used.
   - Use the implicitly (by the SDK) defined #if NETFRAMEWORK compiler
     preprocessor directive instead of a custom "NETFULL" one.
   - Remove one "#nullable enable" statement that wasn't necessary
     anymore as all projects that included the source file already
     enabled nullable.
4. Use floating TFM version that is defined in Arcade: "NetCurrent"
5. For the .NET Framework TFM msbuild property, use the same nomenclature as in other repos.
6. Do not define a floating TFM msbuild property for netstandard2.0 as
   that TFM will never change to a higher version.
7. Change how the live Microsoft.NETCore.App targeting/runtime pack is
   upgraded in this repository to allow previous TFMs to be targeted as
   well (for msbuild tasks).
8. Remove the "PackSpecific" msbuild property and its conditions as .NET
   Framework assets can be built and packaged on Unix machines these
   days with the dynamic reference on .NET Framework targeting packs.
@ViktorHofer ViktorHofer force-pushed the NetStandard1xDepRemovalAndCodeStyling branch from 2c4e447 to afad323 Compare April 17, 2023 15:09
@mmitche
Copy link
Member

mmitche commented Apr 17, 2023

Spring cleaning in .NET! Lovely @ViktorHofer

Copy link
Member

@vlada-shubina vlada-shubina left a comment

Choose a reason for hiding this comment

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

There are couple of change requests inline.

For future, we try to do all formatting changes in separate commit, so they can be ignored when reviewing.

</PropertyGroup>
<PropertyGroup>
<LangVersion>preview</LangVersion>
<NetFrameworkToolCurrent>net472</NetFrameworkToolCurrent>
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure if this change is for better, for this repo full framework is not use as tool. We equally release full framework and .NET version

<TargetFrameworks Condition="'$(PackSpecific)' == 'true'">$(NETStandardTargetFramework)</TargetFrameworks>
<TargetFrameworks>netstandard2.0;$(NetFrameworkToolCurrent)</TargetFrameworks>
Copy link
Member

Choose a reason for hiding this comment

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

Why the decision was made to remove $(NETStandardTargetFramework) in favor of specific reference?
It is much easier to control all the versions in single place?

Comment on lines +9 to +10
<!-- TODO: Change nullable to enable. -->
<Nullable>annotations</Nullable>
Copy link
Member

Choose a reason for hiding this comment

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

TODO left

<PropertyGroup>
<TargetFrameworks Condition="'$(PackSpecific)' != 'true'">$(NETStandardTargetFramework);$(NETFullTargetFramework)</TargetFrameworks>
<TargetFrameworks Condition="'$(PackSpecific)' == 'true'">$(NETStandardTargetFramework)</TargetFrameworks>
<TargetFrameworks>$(NetCurrent);$(NetFrameworkToolCurrent)</TargetFrameworks>
Copy link
Member

Choose a reason for hiding this comment

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

netstandard2.0 should be used here.

Comment on lines -8 to -10
<PackageReference Condition="'$(IsTestProject)' == 'true'" Include="System.Net.Http" Version="4.3.4" />
<PackageReference Condition="'$(IsTestProject)' == 'true'" Include="System.Security.Cryptography.X509Certificates" Version="4.3.0" />
<PackageReference Condition="'$(IsTestProject)' == 'true'" Include="Newtonsoft.Json" Version="13.0.1" />
Copy link
Member

Choose a reason for hiding this comment

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

We had to add other package references to ensure no issues in CG. Has something changed since then?

@@ -5,8 +5,4 @@
<TargetFramework>net7.0</TargetFramework>
</PropertyGroup>

<ItemGroup>
Copy link
Member

Choose a reason for hiding this comment

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

This package reference is expected by tests and should be kept.

@@ -5,8 +5,4 @@
<TargetFramework>net7.0</TargetFramework>
</PropertyGroup>

<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
Copy link
Member

Choose a reason for hiding this comment

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

This package reference is expected by tests and should be kept.

@@ -2,7 +2,7 @@

<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>$(NETCoreTargetFramework)</TargetFramework>
<TargetFramework>$(NetCurrent)</TargetFramework>
Copy link
Member

Choose a reason for hiding this comment

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

legacy tools are not used, and those changes might be skipped.

Comment on lines -8 to -10
<NETCoreTargetFramework>net8.0</NETCoreTargetFramework>
<NETStandardTargetFramework>netstandard2.0</NETStandardTargetFramework>
<NETFullTargetFramework>net472</NETFullTargetFramework>
Copy link
Member

Choose a reason for hiding this comment

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

imo removing those properties is not for good.
They name intention correctly and I prefer to keep them, also for .NET Standard.

They may be changed as

        <NETTargetFramework>$(NetCurrent)</NETTargetFramework>
        <NETStandardTargetFramework>netstandard2.0</NETStandardTargetFramework>
        <NETFullTargetFramework>net472</NETFullTargetFramework>

to remove Core and make use of automatic .NET (core) updates.

@YuliiaKovalova
Copy link
Member

Hi @ViktorHofer,

Do you still plan to deliver these changes?

@ViktorHofer
Copy link
Member Author

Do you still plan to deliver these changes?

Yes, I will get back to in the coming weeks. Changing to draft PR.

@ViktorHofer ViktorHofer marked this pull request as draft June 14, 2023 10:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants