CEF3: Upgrade to latest CEF3 version (Chromium 31)

[perlun]

This link has it. The CEF3 1650-version, i.e. Chromium 31, will give us some more "latest & greatest" functionality. We should definitely upgrade to it; it's a few hours worth of work, but it should be worthwhile.

[jornh]

@perlun I would like to give this one a try. So far I'm able to build the pristine Win32 version of libcef_dll_wrapper.lib from your link above with /MD and /MDd when I disable the 4275 warning with VS2010 + SP1.

I think I have understood from your post and the wiki build info combined with a bit of digging around in git history what changes are needed in the /CEF folder of the CefSharp3 branch.

Any suggestions on how to test it apart from the obvious of trying to run the WPF and WinForms example apps? edit: ... and running Test code of course ;-) https://github.com/cefsharp/CefSharp/tree/CefSharp3/CefSharp.Test

[perlun]

Yeah, the tests are quite lame at the moment... 😄
Very cool to see your interest in this! We could really need some help from a couple of good, hardworking people.

Like you say, it's roughly that:

1. Fork the repo where we host this stuff.
2. Copy in the sources from upstream (note: both the 32-bit and the 64-bit one, since we must support both of them in CefSharp3).
3. Make the minor changes in the .csproj files, like enabling /MD or /MDd, disabling some warnings etc.
4. Build! Here, this part could definitely be improved. I've experimented a bit with setting CefSharp up on TeamCity, but it has failed thus far. Could check it again. The awkward part is that you have to build it in a plethora of different configurations: VS2010 x86 Debug, VS2010 x86 Release, VS2010 x64 Debug, VS2010 x64 Release, VS2012 x86 Debug, VS2012 x86 Release, VS2012 x64 Debug, VS2012 x64 Release... Quite a pain in the neck unfortunately. We could definitely write a bunch of scripts/etc. to simplify this. I suggest doing a Rakefile which does it all in a one-liner, that's probably a good idea. You still have to have both VS2010 and 2012 installed but there's not really any way around that from how I see it. (I would like for us to support VS2013 also, but it unfortunately means 4 new binaries as well to support... 😃)
5. Copy over the stuff into the /CEF folder. Also important is to copy over the #include files! Structures may have changed, new fields may have been added etc.
6. As you say - run the sample apps to see if it is working. Checking the user-agent using some public web site may be one way to verify that you're actually on Chromium 31.

I'll be very happy to cooperate with you on this one. Just let me know if you need any help/feedback and we can take a look at it. I'll also happily accept pull requests in this direction.

[jornh]

Thank you for the warm welcome & the detailed recipe!

Yes, I noticed the potential explosion in configurations. I will start by focusing on doing it manually starting with a few combinations. Then focus on testing with them. Currently I have VS 2010 SP1 and VS 2013 installed locally.

Longer term I'm wondering if something like coapp on top of NuGet native support and maybe a .NET/open source friendly cloud based build service like myget.org would be a way to go. But let's not get too sidetracked by that now. As you noted in the Google groups post that I mentioned above new official CEF builds are not that frequent. So a few well documented manual steps are OK for now.

I'd better stop ranting here now and get building and learning about CefSharp. I'll probably need a few days for that ...

[jornh]

Progressing slowly (but steadily - i hope!) on this. So far I have managed to build and run only the Win32/Debug/VS2010 variant of both the WinForms and WPF example apps with Chromium 31.

I'm new to actually contributing code with this whole GitHub thing. So @perlun how would you like the commits on my fork; small commits folder by folder within the /CEF folder or as few as possible?

[perlun]

@jornh Very nice to see you're doing some great progress! 😃 Regarding the commits and such, here are some general principles:

1. Use space, not tabs. Since this is not the default in VS for C++ code, I suggest you either reconfigure it to use spaces, or if this is not an option, enable the Edit -> Advanced -> View white space option in Visual Studio.
2. Regarding commits: something like "Added VS2010 .libs" as one commit, "Added include files for CEF3 version foo" as a separate one, and similar seems like an idea. Note: remember to include all VS2010 libs in that first one (i.e. both Debug x86, Debug x64, Release x86 and Release x64). If you don't have VS2012, that's OK, I can fix the lib files for that one.
3. Please also commit a separate PR for the cef-binary repo, so I (or anone else) can easily build for VS2012. As suggested in CEF3: Support VS2013 #250, it would also be cool to test it if we can now build CEF3 with VS2013 so that also makes it important to have the relevant code in the cef-binary repo. As far as the commits goes there, you can just make it two commits like "Added x86 CEF3 files for CEF3 version foo" and "Added x64 CEF3 files for CEF3 version foo", or something like that.

Feel free to ask if you're wondering about anything else.

[perlun]

[removed long comment on a now resolved GitHub problem that wasn't related to this issue] -- jornh

[jornh]

... continuation of discussion regarding a missing libcef.lib at https://groups.google.com/d/msg/cefsharp/CC1O66JPM4E/Rwn0WJ0f6XUJ

And I do have problems with my current copy of the CefSharp3 branch. ;-)
I can compile, link and run all 4 combinations of Win32/x64 x Debug/Release with CEF updated to the binary drop of 3.1650 with VS2010 SP1 BUT when I just let any of the CefSharp Example programs run idle for a few minutes I get a vshost.exe crash with "An unhandled win32 exception occurred in CefSharp.Wpf.Example.vshost.exe [11988]"

I have a few areas I suspect - but so far haven't been able to nail it down:

1. I'm not sure my SDK setup with paths etc is completely sane. An indication is that I can compile the CEF - but fail to compile the cefclient.exe. I get errors related to winfamily.h etc. as mentioned by someone recently on the CEF forum. I suspect starting from the opposite end than most others with installing VS2013 first, then VC2010 Express which I uninstalled again then VS2010 with SP1 have gotten me into less known parts of the woods.
2. General uncertainty about how it's valid to mix and match .DLLs and .libs from the CEF binary drop with the /MD(d) compiled across architectures, VStudio/SDK generations, Debug/Release. My current guess is that you can:
   • cheat with the .lib's as long as you stay on the same compiler version and architecture because it's just a collection of .objs (so after compile but before link)
   • and that because we compile the wrapper .lib with /MD(d) that linking dynamically to libcef**.dll** across CRT versions etc. is OK
3. One final thing I don't understand is where you got the libcef.lib for VS2012 from? The CEF binary drop doesn't supply these across VStudio generations and I assume the ones supplied are compiled with VS2010. (But this is not something I'm struggling with now. So far I have issues enough with straightening things completely out on VS2010 alone while trying to not confuse myself too much)

My plan is to backtrack a bit towards CefSharp 3.29 over the weekend and see if I can get to a point where I have something worth committing. As long as what I have isn't able to run without crashing I guess it's worse than the current 3.29 based CefSharp3 branch.

Ideas are more than welcome :-)

[jornh]

Status update: Have been thinking - and learning about NuGet + git submodules etc. a bit more.

As a followup to the cefsharp/cef-binary#1 PR what I plan to do is this:

• A PR#3 over on https://github.com/cefsharp/cef-binary to create new CEF native repackaging Nuget(s?) as a deliverable from there with .dlls and .pak files. This is basically extending on thoughts from #137 - but with the twist that we make a more clear split between repackaging of upstream CEF and CefSharp (separation of concerns is a GoodThing).
  • Well, the PR is not in yet - need to be verified by following steps - but I have a branch https://github.com/jornh/cef-binary/commits/native-nuget
  • adjustments - more content - like HTML5 video .dlls etc. + naming/license etc
    • [ ]FIX needed - in CEF.redist. - rename Cef.targets to cef.redist must match pkg name for NuGet install into msbuild magic to work
• A PR that adjusts the current CefSharp.Core Nuget and other MSBuild cleverness to build on the new naivenative NuGet(s) layer
  • The MSBuild cleverness to use cef.redist is actually in the CefSharp.Xxx.Example projects (nothing in the build for CefSharp.Core change - only it's .nuspec - less content + maybe a dependency)
  • ...
• Probably still copy over into CEF/include compared to packaging it up as a nativepackage. Because GitHub search/grep etc. then gives a nice cross-section of the 🍰 ...ahh ... I mean layers
• decide on copy/package delivery of /CEF/***/.libs (in fact both can be maintained in parallel for this and some of the other points)
• ....
• close CEF3: Upgrade to latest CEF3 version (Chromium 31) #237
• doc bopping (graphics etc)! then announce NuGet over on CEForum
• ....
• consider moving build info related to CEF over to the CEF-binary repo (keep it lean no wiki just README - and just link from CefSharp wiki

I know this is progressing a bit slower compared to just copying over into /CEF but:

• I don't see any super-urgent reasons for moving to 3.31 - better to make things more right than faster.
• Less .bat or Rakefile stuff to copy binaries over, just rely on files in ../packages
• the new native Nuget(s) can potentially be used elsewhere
• With the recent addition of x64 the weight increase in MiB of the CefSharp repo will now grow with around 40-50MB for each new CEF drop (based on the .nupkg size). For comparison we are currently at ~200MB for a full clone of CefSharp3.

Any thoughts, ideas, showstoppers on this?

[perlun]

Cool ideas, really! And as you say, the new packages can be of use elsewhere (both for our "competitors" 😉 at Xilium.CefGlue, and perhaps also for other C++ projects that just wants a stable version of CEF).

I do think that the include files should be in the native package though. It's part of the "contract" in a way. Yes, it does mean that it will not be as easily searchable on GitHub in the CefSharp repo, but remember that the header files will still be in the cef-binary repo so it's still possible to get them there.

One question though. How will you handle the different VS versions? One NuGet package for VS2010, one for VS2012 and another for VS2013? That's just an idea, but I don't think that will work; I think we will have to package them all (VS2010, VS2012 and VS2013) in one single NuGet package, but in separate subfolders.

All of that VS2010/VS2012/VS2013-specificity (what a wonderful word indeed) is really quite awful, but it's impossible to come around with C++/CLR unfortunately... so we need to maintain separate .lib files for each VS version we want to support. And I think it's all of these three for the moment, unfortunately. 😃

(When I joined the project, it only supported VS2008...)

[jornh]

I do think that the include files should be in the native package though

OK, lets try to aim for the "all in on NuGet" approach then. I think the packages should be split into:

• binary "redist" bits for consumers (e.g. people building an app using CefSharp - where CefSharp.MinimalExample is the arch-example)
• "SDK" additions - just all of the the libs + headers (depending on "redist"??) in one big pile across VS201x versions to add on top if you want to build CefSharp.dll the C++/CLR as illustrated by the yellow Core project layer here: http://codepen.io/jornh/full/Iyebk

[JanEggers]

i think the idea of building a nuget for the upstream cef build is a great one.

i just dont see why we should add the content of the package to the cefsharp repo at all.
A package reference is all we need.

http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages

that way we dont bloat the source control with binary files that can be obtained elsewere

[perlun]

@JanEggers, absolutely, that's what we were thinking about. 😄

[jornh]

I'm inching forward with this in branch 3.31-and-native-nugets-wip on my fork

It doesn't look very impressive - but for 3.31 alone it should mean that we don't need to pollute the repo with /CEF binary content that weighs in at ~51 MiB for the Win32 and common parts alone if packaged up as a .zip
I hope this can help save a few Octo-kittens from dying 😄 ... or at least save some money for their milk...

So far it still relies on some 3.31 stuff living in /CEF/ so for now you need to rip out the /CEF folder contents and drop in the 3.31 parts from the .zip here. Update: use the code in PR #288 now (until it goes into master)

Also it only works for the VS2010, (and since #288 VS2013 😄) Win32, CefSharp.Wpf.Example case at the moment.
To have it working for VS2013 - needed for #250 (and VS2012 + the missing VS2010 x64) "pivots" do this:

• make a compile in the cef-binary repo of libcef_dll_wrapper.libs
• the libcef_dll_wrapper.libs plus the libcef.libs already there for x64 must then be dropped on top of /CEF from my .zip

[jornh]

With #288 in Chromium 31 is there - closing