Conversation
|
This looks great, thanks for putting this together. I'll try to find time to look it over properly tomorrow. |
Source/Directory.Build.targets
Outdated
| <PackageProjectUrl>https://oxyplot.github.io/</PackageProjectUrl> | ||
| <PackageIcon>OxyPlot_128.png</PackageIcon> | ||
| </PropertyGroup> | ||
| </Project> No newline at end of file |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
|
@VisualMelon no rush! Thanks for taking a look. |
|
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. |
Jonarw
left a comment
There was a problem hiding this comment.
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.
Source/Directory.Build.props
Outdated
| @@ -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" /> | |||
There was a problem hiding this comment.
@Jonarw from what I understand the ReferenceAssemblies included in this NuGet package mean that we don't need to have any targeting packs installed.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
|
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 |
| { | ||
| Directory.CreateDirectory(BaselineDirectory); | ||
| Directory.CreateDirectory(DestinationDirectory); | ||
| Directory.CreateDirectory(DiffDirectory); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Baseline should be left alone; the others could be deleted, but it's not a problem I don't think.
|
Hi @mattico! |
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.
|
@Jonarw no worries! Rebased. The merge conflicts were only from the changelog. Feel free to update the PR in the future if necessary. |
- Update github actions versions - Add .NET 7.0 targets - Don't overwrite NoWarn
|
Thank you very much for the quick changes. |
Source/OxyPlot/OxyPlot.csproj
Outdated
| <TreatWarningsAsErrors>true</TreatWarningsAsErrors> | ||
| <LangVersion>8</LangVersion> | ||
| <NoWarn>618</NoWarn> | ||
| <NoWarn>$(NoWarn);CS0618;CS8767</NoWarn> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
(Sorry for the confusing messages: I've managed to miss both of @Jonarw 's message before sending mine somehow)
|
All looks good to me! |
|
@HavenDV anything else from your side? (And thank you for chiming in) |
I usually add this to Directory.Build.props. |
|
@Jonarw I'm happy for this to be merged if you are |
|
Thanks @mattico for this PR (and for your patience)! |
Checklist
Changes proposed in this pull request:
@oxyplot/admins