Added Visual Studio 2019 support (tools v142) and switched to using the -A flag with cmake for arch (supported since VS 2008/cmake 3.1)

[mitchcapper]

Have to use -A with the newer cmake as it no longer defaults to x86. Assuming you don't see an issue adding vs2019 support i have a similar PR for cefsharp I will submit up.

Does not default to VS2019 build currently.

[mitchcapper]

Also assuming VS2019 support is something you want to add now, for CefSharp given that cef now requires 18362 of the sdk (https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding) are you fine with me bumping the sdk requirements for CefSharp to the same in that PR?

[amaitland]

Great, thanks 👍 I've recently installed VS2019 so will hopefully have a chance to test it out in the next few days.

Also assuming VS2019 support is something you want to add now, for CefSharp given that cef now requires 18362 of the sdk (https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding) are you fine with me bumping the sdk requirements for CefSharp to the same in that PR?

Happy to discuss further on cefsharp/CefSharp#2628

[amaitland]

Assuming you don't see an issue adding vs2019 support i have a similar PR for cefsharp I will submit up.

For clarity, a PR to add support would be welcome 👍

Requirement changes should be discussed on cefsharp/CefSharp#2628 so anyone tracking the issue is aware of the discussion and can participate.

[amaitland]

Looks like cmake 3.14 is required to build with VS2019.

Error CMake Error: Could not create named generator Visual Studio 16 when building with 3.13

[mitchcapper]

If I understand all the components to this:
We could merge this PR which would add VS2019 options to the build script however we can't make it the default build option even if we upgraded the appveyor to a VS2019 environment due to bug #70 which would be required to be solved as only newer cmake versions support VS2019. The best resolution to #70 would be the actual cef cmake changes, although that might not happen any time soon.

This causes further complications as if we can't generate a v142 binary officially (only the v141 and v140) then we can't merge cefsharp/CefSharp#2924 as it wouldn't work with the official nuget sdks. We can partially get cefsharp/CefSharp#2628 support by targeting v141 for the VS2019 builds but it requires the user having the 2017 build tools installed a well (only minorly confusing).

[amaitland]

We could merge this PR which would add VS2019 options to the build script however we can't make it the default build option even if we upgraded the appveyor to a VS2019 environment due to bug #70 which would be required to be solved as only newer cmake versions support VS2019

It's complicated more so by AppVeyor only having certain versions in their build images. We use the VS2017 image currently which allows us to build with VS2015 and VS2017. We'd need to move to the VS2019 image, and it's not clear that it would support building with VS2015. https://www.appveyor.com/docs/windows-images-software/ lists the pre installed software per image.

The best resolution to #70 would be the actual cef cmake changes, although that might not happen any time soon.

Waiting for any changes to be merged into CEF is unrealistic, so your suggestion in #70 (comment) is likely the way forward if we do choose to go ahead there.

This causes further complications as if we can't generate a v142 binary officially (only the v141 and v140) then we can't merge cefsharp/CefSharp#2924 as it wouldn't work with the official nuget sdks

Unfortunately yes.

We can partially get cefsharp/CefSharp#2628 support by targeting v141 for the VS2019 builds but it requires the user having the 2017 build tools installed a well (only minorly confusing).

The v142 build tools are backwards compatible, so we can use v142 to consume a v141 library. So no special tools are required. From within VS2019 the .vsconfig added in cefsharp/CefSharp@ee06759 should hopefully ensure all the required build tools are installed.

The .vcxproj files need a reference to libcef_dll_wrapper.lib, currently the CefSharp.props file maps the VS version number to the directory within the cef.sdk package. The setup is based on when the project targeted VS2012/VS2013, where each version could only link against a .lib file built with that particular version.

One hacky workaround would be cef-binary/build.ps1 to copy the VS2017(debug/release) libs into the VS2019 folders, perhaps with a special command line flag. The Nupkg(zip) file shouldn't increase in size as the compression should see it as being the same files, just the extracted size on disk would grow by ~100mb.

[amaitland]

Both VS2017 and VS2019 builds passed locally, merged with minor formatting change and bump of version see 915ceca

Will see how AppVeyor goes next time I tag a build and will let you know if there's any problems.