Update to M93 #3781
Update to M93 #3781
Conversation
|
❌ Build CefSharp 93.1.70-CI4190 failed (commit b53ff26c01 by @amaitland) |
|
It seems that the tests are hanging, switching to See https://ci.appveyor.com/project/campersau/cefsharp/builds/40570216 and commit campersau@c229527 which also includes a working matrix build for both solutions. (I disabled the |
|
Thanks. I was thinking we could probably use less resources and build both together. Will keep this as a plan B. I'll switch to dotnet test and see how that goes. |
|
Building both at once also works with a little fix see https://ci.appveyor.com/project/campersau/cefsharp/builds/40586025 and campersau@43d67ab |
|
Thanks, very helpful. |
…4577.15 Compiles but doesn't run as IMPLEMENT_REFCOUNTING implementation uses atomic which forces the VC++ compiler to compile as native which doesn't work for our managed ref classes. Added a dummy ref counting implementation to each class until I can get a new working template. Possibly backport the old ref counting implementation
This is a breaking change. CEF will now automatically download the Widevine CDM component Resolves #3767
… CEF UI Thread Avoid having to use cef_callback.h which was causing problems for x86 builds
Potentially have to backport the implementation from prior to CEF upgrading
Macro isn't yet implemented, basic project compiles now though so it's just a matter of backporting the ref counting implementation
- Use InterlockedIncrement/InterlockedDecrement directly - There's no memory barrier for HasOneRef/HasAtLeastOneRef as the read of a LONG should happen in one operation on 32/64 bit architectures (at least that's my understanding at this point in time). References: https://github.com/chromiumembedded/cef/blob/4472/include/base/internal/cef_atomicops_x86_msvc.h#L125 https://github.com/chromiumembedded/cef/blob/4472/include/base/internal/cef_atomicops_arm64_msvc.h#L107 https://github.com/chromiumembedded/cef/blob/4472/include/base/cef_atomic_ref_count.h#L114 https://github.com/chromiumembedded/cef/blob/4472/include/cef_base.h#L91
Will look at fixing the build matrix later
Now that we require a min of VS2019 to build there's no need for a custom compiler package
amaitland
force-pushed
the
upgrade/93
branch
from
8e9a13a to
7bcde50
Compare
Issues:
Summary:
CEF Now Requires
VS2019to build the wrapper, there are also changes required as the headers have been upgraded.Changes: [specify the structures changed]
.Net 4.5.2projects usingVS2019VC++doesn't like usingatomicWidewineis now downloaded automatically and the methods to load it manually have been removed (Remove Cef.RegisterWidevineCdm #3767)How Has This Been Tested?
Unit tests pass though only for
.Net 4.5.2projects as theNet Core/Net 5projects aren't building yet.Types of changes
Checklist:
TODO:
AppVeyorcurrently isn't building both solutions