Skip to content

Improve Project Files#1937

Merged
Jonarw merged 20 commits intooxyplot:developfrom
mattico:improve-ci
Jul 14, 2023
Merged

Improve Project Files#1937
Jonarw merged 20 commits intooxyplot:developfrom
mattico:improve-ci

Conversation

@mattico
Copy link
Contributor

@mattico mattico commented Sep 18, 2022

Checklist

  • I have included examples or tests
  • I have updated the change log
  • I am listed in the CONTRIBUTORS file
  • I have cleaned up the commit history (use rebase and squash)

Changes proposed in this pull request:

  • As a follow-up to Add SourceLink support and nuget symbol packages #1930, adds Directory.Build.props to Solution Items folders
  • Add EnableWindowsTargeting to enable building .NET Framework libs from Linux and Mac
  • Factor out common project properties to Directory.Build.props now that we have one of those
  • A drive-by fix to some SkiaSharp deprecated functions
  • Update supported TargetFrameworks to remove EoL versions and default to .NET 6.0 where possible.

@oxyplot/admins

@VisualMelon
Copy link
Contributor

This looks great, thanks for putting this together. I'll try to find time to look it over properly tomorrow.

<PackageProjectUrl>https://oxyplot.github.io/</PackageProjectUrl>
<PackageIcon>OxyPlot_128.png</PackageIcon>
</PropertyGroup>
</Project> No newline at end of file
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The Build.targets file is executed towards the end of the build process, so we can depend on variables set in the individual projects. In here we have common properties for our published packages.

Copy link
Contributor

@HavenDV HavenDV Jul 13, 2023

Choose a reason for hiding this comment

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

Typically properties and Items are added to the Directory.Build.props file. Directory.Build.targets is used for custom targets. But in general, it doesn't matter.

You can also add a README for all libraries:

  <PropertyGroup Label="Nuget">
    <PackageReadmeFile>README.md</PackageReadmeFile>
  </PropertyGroup>

  <ItemGroup Label="Nuget">
    <None Include="$(MSBuildThisFileDirectory)../../README.md" Pack="true" PackagePath="\" Visible="false" />
  </ItemGroup>

I also recommend using $(MSBuildThisFileDirectory) wherever possible instead of $(SolutionDir). $(SolutionDir) is not set when running dotnet build on a specific .csproj file

@mattico
Copy link
Contributor Author

mattico commented Sep 18, 2022

@VisualMelon no rush! Thanks for taking a look.

@mattico mattico changed the title Improve ci Improve Project Files Sep 18, 2022
@VisualMelon
Copy link
Contributor

I think we should include a comment somewhere prominent that we now require .NET 5 or .NET 6 to build the libraries, though they still target .NET Core 3.1 and need it for testing: that could create some real confusion for people trying to get it up and running the first time. To keep thing simple, may make sense to add net6.0 targets to everything now as @HavenDV suggested (not necessarily in this PR) so that basic dev tasks can all be performed with .NET 6.

Copy link
Member

@Jonarw Jonarw left a comment

Choose a reason for hiding this comment

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

We should consider upgrading things like example browser to .NET 6 anyway, as .NET 3.1 runs out of support at the end of this year anyway (if I remember correctly). But this does not need to be part of this PR.

@@ -4,4 +4,10 @@
<PackageReference Include="DotNet.ReproducibleBuilds" Version="1.1.1" PrivateAssets="All"/>
<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.3" PrivateAssets="All" />
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Jonarw from what I understand the ReferenceAssemblies included in this NuGet package mean that we don't need to have any targeting packs installed.

Copy link
Contributor

@VisualMelon VisualMelon Sep 21, 2022

Choose a reason for hiding this comment

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

Certainly seems we don't need them to build the assemblies, but I think we do need to keep the example and tests projects current as they determine the runtime actually used by devs and the CI (and for the framework runtimes you need a targeting pack, I think)

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, that didn't seem to be enough in my case. I was unable to build before installing the targeting pack manually. Of course now that I have installed it I can't reproduce the issue anymore.
In any case, I think upgrading to .NET 4.6.2 makes sense anyway, as the older versions have been out of support since April 2022.

@mattico
Copy link
Contributor Author

mattico commented Nov 6, 2022

Okay, I updated all the targetframeworks so we're only shipping for supported targets: .NET Framework 4.6.2, .NET Standard 2.0, and .NET 6.0. I had to fix a few nullable warnings to work on .NET 6.0.

While running the tests I changed some of the tests to use TestCaseSource so the cases can run in parallel and so you can see which test cases are failing and debug them individually.

{
Directory.CreateDirectory(BaselineDirectory);
Directory.CreateDirectory(DestinationDirectory);
Directory.CreateDirectory(DiffDirectory);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Aside: should this delete the existing dirs? Some of the examples use random data so they error if you run the tests multiple times without clearing out the baseline dir. Could also seed the rng in tests but that's not exposed from the examples currently.

Copy link
Contributor

Choose a reason for hiding this comment

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

Baseline should be left alone; the others could be deleted, but it's not a problem I don't think.

@Jonarw
Copy link
Member

Jonarw commented Jul 11, 2023

Hi @mattico!
First of all, sorry that this PR has been open for so long. We would like to get this merged finally! Would you be interested in rebasing / sorting out the merge conflicts that have accumulated? Alternatively, would it be alright with you if I took care of that?
Thanks for this contribution in any case!

mattico added 14 commits July 11, 2023 12:04
so it's more visible in Visual Studio.
as it's included by DotNet.ReproducibleBuilds
.NET Framework versions updated to 4.6.2 as 4.5.2 is EOL.
.NET Standard versions before 2.0 are no longer supported as
.NET Framework 4.6.2 supports .NET Standard 2.0.
Examples moved to .NET 6.0.
.NET Core 3.1 support removed as it is EOL on December 13, 2022.
Tests changed to run on .NET Framework and .NET 6.0.
Project SDKs updated to new Microsoft.NET.Sdk.
Fix nullable errors from updating to .NET 6.0.
The underlying library is .NET Framework only, and it's deprecated.
It has a bug on .NET 6 related to code pages.
Hopefully this has .NET 6.0
May as well, since we need to build ExampleLibrary for net462 for the tests anyway.
@mattico
Copy link
Contributor Author

mattico commented Jul 11, 2023

@Jonarw no worries!

Rebased. The merge conflicts were only from the changelog. Feel free to update the PR in the future if necessary.

Copy link
Contributor

@VisualMelon VisualMelon left a comment

Choose a reason for hiding this comment

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

Looks like the target framework lines may have gone wrong in the rebase

(Thanks for coming back to this!)

 - Update github actions versions
 - Add .NET 7.0 targets
 - Don't overwrite NoWarn
@HavenDV
Copy link
Contributor

HavenDV commented Jul 13, 2023

Thank you very much for the quick changes.

<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<LangVersion>8</LangVersion>
<NoWarn>618</NoWarn>
<NoWarn>$(NoWarn);CS0618;CS8767</NoWarn>
Copy link
Contributor

Choose a reason for hiding this comment

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

Would prefer we disable CS8767 only in the one place it lights up (CompareHelper) with #pragma warning disable/restore CS8767. Without changing to C#9 (which I don't think is supported on net framework) I can't find a way to make the code happy.

Copy link
Contributor

Choose a reason for hiding this comment

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

Without changing to C#9 (which I don't think is supported on net framework) I can't find a way to make the code happy.

.Net Framework supports C# 9. You can also always use PolySharp - https://github.com/Sergio0694/PolySharp

Copy link
Contributor

@VisualMelon VisualMelon Jul 13, 2023

Choose a reason for hiding this comment

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

@HavenDV do you have a reference for C#9 support in net framework? I searched but could only find comments about net 5.0 and above, which I took to mean not net framework, but keen to hear otherwise.

Copy link
Contributor

Choose a reason for hiding this comment

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

I have many projects that include net451 or net462 TargetFramework and for which I install the latest version of the language. Everything works correctly. But, for example, to support records, you need to add special classes to the project (or use PolySharp, which will do the same)

Copy link
Contributor

Choose a reason for hiding this comment

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

This states it is not supported (in 4.8 at least), but I still can't find a clear definitive reference dotnet/docs#26587 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm tempted to suggest we remove the ComparisonHelper API and rewrite the only usage thereof (which is confusing and depends on implementation details in List<T>.BinarySearch). For the time being, it's probably simplest just to disable the warning locally, which won't create a burden anywhere else.

Copy link
Contributor

Choose a reason for hiding this comment

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

Quoting the MSDN

Choosing a language version newer than the default can cause hard to diagnose compile-time and runtime errors.

Certainly OxyPlot isn't doing anything exciting run-time wise, and I'm not aware of any situations where it actually goes wrong, but I'd still be uneasy using something that isn't officially supported.

Copy link
Member

Choose a reason for hiding this comment

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

With our LangVersion at 8 we are actually already in unsupported territory. I suspect MS writes this as they want a) people to move away from .NET Framework and b) don't want to be held responsible for any misuses.

But I agree, let's keep it simple for now, the LangVersion might be a discussion for another day. Let's disable the warning locally and keep everything else as is.

Copy link
Contributor

Choose a reason for hiding this comment

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

The question for me regarding bumping the language version is really whether it can create silent bugs. Continuing the search, I can't find any evidence that this has occurred, and most discussion is just concerning using newer features.

All that said, it looks like C# 8 isn't strictly supported either, so I should probably stop worrying.

Copy link
Contributor

@VisualMelon VisualMelon Jul 13, 2023

Choose a reason for hiding this comment

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

(Sorry for the confusing messages: I've managed to miss both of @Jonarw 's message before sending mine somehow)

@VisualMelon
Copy link
Contributor

All looks good to me!

@VisualMelon
Copy link
Contributor

@HavenDV anything else from your side? (And thank you for chiming in)

@HavenDV
Copy link
Contributor

HavenDV commented Jul 13, 2023

    <PropertyGroup Label="Analyzers">
        <EnableNETAnalyzers>true</EnableNETAnalyzers>
        <AnalysisLevel>latest</AnalysisLevel>
        <AnalysisMode>All</AnalysisMode>
    </PropertyGroup>

I usually add this to Directory.Build.props.
But in fact, this is likely to generate a lot of warnings and is suitable for a single PR or a series of PRs.

@VisualMelon
Copy link
Contributor

@Jonarw I'm happy for this to be merged if you are

@Jonarw
Copy link
Member

Jonarw commented Jul 14, 2023

Thanks @mattico for this PR (and for your patience)!

@Jonarw Jonarw merged commit f1b3d44 into oxyplot:develop Jul 14, 2023
@Jonarw Jonarw mentioned this pull request Jul 14, 2023
4 tasks
@mattico mattico deleted the improve-ci branch July 14, 2023 15:34
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.

4 participants