Add new projects targeting .NET Core 3.1

[kpreisser]

Contributes to #2796

Summary:
This is a draft PR for adding new .NET Core 3.1 projects in addition to the .NET Framework 4.5.2 projects, using a ".netcore" suffix like in the minimal example (support for C++/CLI projects was added with .NET Core 3.1 and VS 2019 (16.5)).
Adding proper .NET Core 3.1 projects will have the following benefits:

• It ensures that the binaries that will be consumed in .NET Core projects don't accidentally use APIs that are available in .NET Framework but not in .NET Core (e.g. WCF).
• Once .NET 5.0 is released (which includes support for Windows ARM64) and CEF provides Windows ARM64 builds, the .NET Core projects should allow to add support for ARM64 to CefSharp (Feature Request - ARM64 support #2944).
• The C++/CLI DLLs (CefSharp.Core.dll and CefSharp.BrowserSubprocess.Core.dll) no longer depend on mscoree.dll, which can be missing on the system if the .NET Framework was uninstalled (e.g. on Windows Server).

Changes:

• I created a new solution CefSharp3.netcore.sln along with new projects (CefSharp.netcore.csproj, CefSharp.Core.netcore.vcxproj, CefSharp.BrowserSubprocess.Core.netcore.vcxproj, CefSharp.WinForms.netcore.csproj, CefSharp.Wpf.netcore.csproj, CefSharp.OffScreen.netcore.csproj).
  • The .NET Core projects use obj.netcore and bin.netcore as their [intermediate] output paths, so that it's possible to build them side-by-side with the .NET Framework projects.
  • For the C++/CLI projects, I copied the original project files and applied the changes as described in How to port a C++/CLI project to .NET Core.
  • In CefSharp.Core.netcore.vcxproj, I removed the references to opengl32.lib and glu32.lib as they don't seem to be needed and they are not available for ARM64.
• I added preprocessor directives to exclude WCF types for .NET Core which are not available there (I excluded as much as was necessary to fix the build errors, but haven't looked if there is still more code which can/should be excluded, or if I excluded too much code).

Note, I'm not very familiar with C++ and C++/CLI projects, so I'm not sure if the changes I made are entirely correct.

Later, the NuGet packages could be changed to include the netcoreapp3.1 files for .NET Core 3.1 apps (or maybe wait until .NET 5.0 is released, and increase the target framework to net5.0).

How Has This Been Tested?
I built the solution and then referenced the built DLLs in the CefSharp.MinimalExample.WinForms.netcore and CefSharp.MinimalExample.Wpf.netcore projects (where I previously removed the existing references and increased the target framework to netcoreapp3.1). After adding the CEF redist files, the program run successfully.

Note: When building C++/CLI projects targeting .NET Core, an additional file ijwhost.dll is placed in the bin directory on which the built DLL depends (instead of mscoree.dll). That file must also be copied to the application's bin directory; otherwise, a BadImageFormatException will occur.

What do you think?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Updated documentation

Checklist:

• Tested the code(if applicable)
• Commented my code
• Changed the documentation(if applicable)
• New files have a license disclaimer
• The formatting is consistent with the project (project supports .editorconfig)

[AppVeyorBot]

✅ Build CefSharp 83.4.2-CI3597 completed (commit 00cd22c599 by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 83.4.2-CI3598 completed (commit ba213104eb by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 83.4.2-CI3599 completed (commit a51c39185a by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 83.4.2-CI3600 completed (commit 04e78adafd by @kpreisser)

[amaitland]

Great, thank you 👍

I'll have a look in detail when I have a spare moment.

[andrewmd5]

just want to say thank you for this contribution!

[amaitland]

@kpreisser Are any further changes in the pipeline? I'll probably restructure a few things after merging, I'm thinking of moving all the WCF related classes into a separate folder/namespace so they can be excluded from the csproj files rather than having some ifdefs (at least that's the hope). Just checking if you had anything else planned before I proceed. I'll look at porting the example projects at the same time.

[kpreisser]

@amaitland I also started to port CefSharp.Example and CefSharp.WinForms.Example to .NET Core; I have pushed these changes now. I haven't started to look at the other projects, so you can merge/review the PR if you like.
Thank you!

[AppVeyorBot]

✅ Build CefSharp 83.4.2-CI3604 completed (commit 9055cdfc1f by @kpreisser)

[AppVeyorBot]

✅ Build CefSharp 83.4.2-CI3605 completed (commit bbb11c4c2d by @kpreisser)

[amaitland]

I've added the Wpf/OffScreen example projects and done some refactoring, I've also added a CefSharp.BrowserSubProcess

I squashed the changes from this commit and have created branch https://github.com/amaitland/CefSharp/tree/enhancement/netcore31

There are lots of little things to resolve still.

• Generate PDB's
• Integrate source code
• Check if we need to make the BrowserSubProcess TSAware (it's not a WinExe so not sure that we have to).

Later, the NuGet packages could be changed to include the netcoreapp3.1 files for .NET Core 3.1 apps (or maybe wait until .NET 5.0 is released, and increase the target framework to net5.0).

The reason I haven't progressed with these changes sooner is actually an infastructure one, the current Appveyor build image only has VS2015 installed, so is unable to build the .Net Core 3.1 projects using VS2019. If we switch to the VS2019 build worker image it doesn't have VS2015 installed. If we compile with VS2019 we'll be forcing users to upgrade to VC++2019. Maybe it's possibly to get the a VC++2015 build for the .Net Full dlls from a VS2019 instance with some major hacking.

I'm actually thinking we'll only include the new set of .Net Core dlls in the PackageReference nuget packages (#2795) and move the dependency to VC++2019 for those packages only. Primarily they'll be used for .Net Core 3.x development anyway so it shouldn't be a problem. AppVeyor can be setup to perform a matrix build, I'll look at that soon as I iron out these changes a little more. Hopefully the .Net Core dlls will resolve some of the issues I was having with Nuget/msbuild.

Further details to follow in the next day or so.

[kpreisser]

Hi @amaitland,

I squashed the changes from this commit and have created branch https://github.com/amaitland/CefSharp/tree/enhancement/netcore31

Thanks a lot for your work on this!

I'm actually thinking we'll only include the new set of .Net Core dlls in the PackageReference nuget packages (#2795) and move the dependency to VC++2019 for those packages only. Primarily they'll be used for .Net Core 3.x development anyway so it shouldn't be a problem.

I agree it is reasonable to include the new .NET Core DLLs in the new packages only and require VC++2019 for them.

Thanks!

[amaitland]

Soon as i have the unit tests passing again I'll merge this. I found an unrelated bug in the JavaScript Binding implementation (#3193) whilst debugging which took a little while to track down. I'm hoping to have this done this afternoon.

[amaitland]

Merged with follow up commit e8cf336

I've created #3197 to track a list of outstanding tasks related to actually building/packaging a .Net Core build.

Thanks for the excellent contribution 👍