dotnet build with multi-targeting #3932
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivations
Since #2820, we have had
Debug_NetCore
andRelease_NetCore
build configurations that compiled the Core and Test projects targeting .NET Core (now ".NET 7"; I'm not going to try to explain the difference between .NET Core/Standard/5/6/7/etc. and .NET Framework here because it drives me batty). These build options were run by our GitHub build workflows, but not used, and it was easy to forget they existed and thus submit a PR that broke them. They worked by setting theBuildFramework
conditionally inside the .csproj files based on theConfiguration
, which is not great because it tightly couples the framework and configuration when in principle these could be independent. It would be nice to integrate this support better into the main build.In addition, see #3929 (review), our .NET 7 builds currently emit about 100 warnings about obsolete code, platform-specific code reachable on all platforms, etc.
https://github.com/KSP-CKAN/CKAN/actions/runs/6916657258?pr=3929
Changes
Debug_NetCore
andRelease_NetCore
configurations are replaced by aNoGUI
configuration that builds everything except GUI and AutoUpdater (because both depend on WinForms), which is independent of the target framework<TargetFramework>
is replaced by<TargetFrameworks>net48;net7.0-windows</TargetFrameworks>
if it uses WinForms (which .NET 7 considers specific to the Windows platform), or<TargetFrameworks>net48;net7.0;net7.0-windows</TargetFrameworks>
otherwise, which will make them always build for both .NET Framework 4.8 and .NET 7.0. Tests and CmdLine use#if
checks to include and exclude code that depends on those projects.build.cake
always builds for both frameworks, and./build test
and.\build.ps1 test
run tests for both frameworksdotnet build
because it can successfully build all projects for all target frameworks, but on Linux it usesdotnet build
for the .NET 7 part of the build and the old Monomsbuild
to build for .NET Framework 4.8, because it is the only way to build WinForms code on Linux. Ideally in the future we would find a way to makedotnet build
work for everything on Linux as well, but that would require finding a way to install non-Mono WinForms support libraries.build.yml
no longer uses the*_NetCore
configurations because the main build covers what they used to doResources.Designer.cs
files are deleted and automatically generated from the .resx files during the build, as VS intended, which will simplify translation maintenanceUri.EscapeUriString
are replaced byUri.EscapeDataString
#if
checks or checkPlatform.IsWindows
, which is now marked with theSupportedOSPlatformGuard
attribute to indicate that it is safe to run platform-specific code if it returnstrue
WebClient
andWebRequest
are switched to the newerHttpClient
PermissionSet
attribute isn't used in .NET 7SHA1.Create()
andSHA256.Create()
instead of calling the constructors ofSHA1CryptoServiceProvider
andSHA256CryptoServiceProvider
RedirectWebClient
was unused and is removedSupportedOSPlatform
attribute so it can use WinForms in .NET 7This addresses all of those .NET 7 build warnings and brings CKAN another step closer to using a more modern framework. With all our projects now able to build on .NET 7, we have the future opportunity to investigate switching over to it fully. There are many obstacles in the way (cross-platform WinForms, packing dependencies into an EXE, etc.), but all of the unnecessary ones that our build system had created are cleared.