Closed mitchcapper closed 5 years ago
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?
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 https://github.com/cefsharp/CefSharp/issues/2628
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 https://github.com/cefsharp/CefSharp/issues/2628 so anyone tracking the issue is aware of the discussion and can participate.
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
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 https://github.com/cefsharp/CefSharp/pull/2924 as it wouldn't work with the official nuget sdks. We can partially get https://github.com/cefsharp/CefSharp/issues/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).
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 https://github.com/cefsharp/cef-binary/issues/70#issuecomment-538662634 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 https://github.com/cefsharp/CefSharp/commit/ee06759c08b9a748720be372bf27964f04875062 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
.
Both VS2017
and VS2019
builds passed locally, merged with minor formatting change and bump of version see https://github.com/cefsharp/cef-binary/commit/915ceca2c766fe5508ce576957db4fa256792fd7
Will see how AppVeyor
goes next time I tag a build and will let you know if there's any problems.
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.