-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
8e9a13a
to
7bcde50
Compare
Issues:
Summary:
CEF Now Requires
VS2019
to build the wrapper, there are also changes required as the headers have been upgraded.Changes: [specify the structures changed]
.Net 4.5.2
projects usingVS2019
VC++
doesn't like usingatomic
Widewine
is 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.2
projects as theNet Core/Net 5
projects aren't building yet.Types of changes
Checklist:
TODO:
AppVeyor
currently isn't building both solutions