.NET Core 3 Port #7
Conversation
Pull latest changes.
Pull from the 'develop' branch
|
@acemod13 Thanks for updating the PR. The changes look a lot more manageable now. I'll give you some feedback throughout this week and hoping to get this merged soon. |
|
Aye. Looking forward to it. I've also done some editing in the project files so it can compile both .NET 4.5 and .NET Core 3.1 libraries (mainly since the sample app wouldn't compile unless I re-wrote the entire project file). |
| <file src="bin\$configuration$\Ookii.Dialogs.Wpf.dll" target="lib\net45\" /> | ||
| <file src="bin\$configuration$\Ookii.Dialogs.Wpf.pdb" target="lib\net45\" /> | ||
| <file src="bin\$configuration$\Ookii.Dialogs.Wpf.xml" target="lib\net45\" /> | ||
| <file src="bin\$configuration$\net45\Ookii.Dialogs.Wpf.dll" target="lib\net45\" /> |
There was a problem hiding this comment.
This looks good assuming we'll continue to create the NuGet package using the NuGet CLI. I'm just wondering if we shouldn't move to dotnet pack on the .csproj now that we are going to the new SDK project format. What do you think?
| <Pack>True</Pack> | ||
| <PackagePath></PackagePath> | ||
| </None> | ||
| <None Include="..\..\LICENSE"> |
There was a problem hiding this comment.
This relates to my other question on NuGet CLI w/ .nuspec vs. dotnet pack w/ .csproj - if we are going with the latter, then let's use PackageLicenseExpression with a valid SPDX license identifier here instead of embedding a custom license file
| <OutputType>Library</OutputType> | ||
| <AppDesignerFolder>Properties</AppDesignerFolder> | ||
| <RootNamespace>Ookii.Dialogs.Wpf</RootNamespace> | ||
| <TargetFrameworks>netcoreapp3.1;net45</TargetFrameworks> |
There was a problem hiding this comment.
Does this work fine for you with VS 2019 in this order? I remember having issues with this in some projects where it was necessary to declare net45 first, and netcoreapp3.1 after. i.e.
<TargetFrameworks>net45;netcoreapp3.1</TargetFrameworks>There was a problem hiding this comment.
It works on my side. Although, I have .NET Core 3.1 SDK already installed. It is possible to specify which version to compile in Visual Studio. But, as a failsafe, it would be a good idea.
| //[assembly: NeutralResourcesLanguage("en-US", UltimateResourceFallbackLocation.Satellite)] | ||
|
|
||
|
|
||
| [assembly: ThemeInfo( |
There was a problem hiding this comment.
Is ThemeInfo being automatically generated now through the new SDK project?
| [assembly: AssemblyCopyright("Copyright (c) Sven Groot (Ookii.org) 2009")] | ||
| [assembly: AssemblyTrademark("")] | ||
| [assembly: AssemblyCulture("")] | ||
| [assembly: System.CLSCompliant(true)] |
There was a problem hiding this comment.
Is CLSCompliant being automatically generated now through the new SDK project?
| [assembly: AssemblyTrademark("")] | ||
| [assembly: AssemblyCulture("")] | ||
| [assembly: System.CLSCompliant(true)] | ||
| [assembly: System.Resources.NeutralResourcesLanguage("en-US")] |
There was a problem hiding this comment.
Is NeutralResourcesLanguage being automatically generated now through the new SDK project?
There was a problem hiding this comment.
Yes. Pretty much everything that was covered under the AssemblyInfo.cs is generated through the new SDK project.
|
Looks great. Thanks @acemod13 for the PR and the patience. I've just released Ookii.Dialogs.Wpf v1.2.0 and I think we can get going on the .NET Core migration now, especially with the imminent .NET 5 release. |
Fixes #5 .
At the moment, the new projects have a copy of the code (to avoid bringing braking changes to the original) but if there are no breaking changes, it should be possible to simply edit the projects to pull the files from the originals.