Upgraded to Chromium 31 and changed CEF dependency to use native NuGet packages

[jornh]

This should be a good step towards closing both #237 and #250
#237: move to the CEF release based on Chromium 31
#250: Support building CefSharp with VS2013

NOTE: Merging this PR means that building of a CefSharp git clone from now on relies on a working NuGet setup on your machine - which IMHO you should have anyway :-) The big benefit of this approach is that we can stop polluting the CefSharp repo with binaries in /CEF.

The cef.sdk NuGet is still missing some libs - I need someone with VS2012 to help build those.

But I thinks it's ready for review by someone with VS2010/VS2013 - and for now only the Win32 "pivot" (or should we say specificity 😄)

I'll start expanding the cef.sdk NuGet with the VS2010/VS2013 x64 libs now

[perlun]

Nice one! I will try this now as soon as I can find some time.

[brock8503]

@jornh nice work, I just tested on my machine and it is building with vs2013 and running!

[jornh]

@brock8503 thanks for testing thus far and I'm really glad it "just worked". Then, I guess your excuse for not being able to hack away on CefSharp is gone now 😉

Please provide feedback if you come across something that looks broken.

[perlun]

@jornh, tried this now w/ VS2012 but I get this error when compiling:

2>\\psf\home\git\cefsharp.perlun.cef3\cefsharp.core\Stdafx.h(13): fatal error C1083: Cannot open include file: 'include/cef_base.h': No such file or directory

Do you need anything special to get the CefSharp.Core building? I couldn't find a packages.config file for that project either, but is this because NuGet for C++/unmanaged projects work differently than NuGet for C# projects?

[jornh]

Aha, VS2012 - see the note at the top of the page. Try VS2010 first if you have it. I don't have VS2012 installed so it's libs are not in the cef.sdk NuGet .... Yet!

The packages.config is where VStudio integrated GUI NuGet wanted to put it: .nuget/packages.config for the whole solution.

[perlun]

Alright. Thanks for the file location, I saw it now. Apparently the package is installed as a "solution package" instead of a "project package" (which is normally the case for C# stuff).

I can compile cef.sdk for VS2012. Tell me the steps involved and I'll help out. (perhaps make a separate cef-binary issue for it, if it doesn't already exist)

[jornh]

Compile using build.bat in both cef_binary_3.y.z_windows32 and 64 collect the four libcef_dll_wrapper.lib's and drop them in /packages/cef.sdk.xxxxx.yyy./CEF/. tree NuGet should have given you. Seems it didn't do a proper Install-Package because you don't have the include

For added bonus email the wrapper-libs to me and they will be in next CEF.sdk NuGet 😄

[jornh]

@perlun are you stuck or progressing here? Anything I can do on this now? Write a "proper" guide on something on either the cef-binary or CefSharp side of the "NuGet wall" - or fix some "code"/scripting? (BTW I just looove the refactoring support the is in the <MSBuild> language - not! 😉)

Also regarding "solution level" vs "project level" NuGet dependency - I'm not familiar with preferred conventions and pro/con + tool limitations on this. Maybe something we need to discuss - when you got some 3.31 running - because whatever we choose I guess it will come and haunt us from now on muhahaha when we take the plunge on native nugets.

update: a pro "solution" level argument http://blog.spinthemoose.com/2013/04/21/nuget-tip-3-manage-packages-at-the-solution-level/ and a pro "project level" http://nuget.codeplex.com/workitem/2251

[perlun]

I started looking at creating a Rakefile for this, but it's not done yet. It might be that I won't have time for completing it until next week.

My idea is to provide vs2010, vs2012 and vs2013 targets, which will then launch the vsvars32.bat file for the proper VS version, and run msbuild. That way, you won't have to start up the right Developer Command Prompt; you can just make all of the targets at once using one single Rake command.

I know you might not be a big Ruby fan (yet 😉) but I feel it will be very convenient that way. Yes, people might have to do cinst ruby but that's something that they should be doing anyway... 😉 Besides, the number of people hacking on cef-binary is very low anyway so a slightly higher requirement in terms of tooling is quite OK as far as I'm concerned. (AFAIC?)

[perlun]

(we moved that discussion to cefsharp/cef-binary#5, where it better belongs - good point, @jornh)

[jornh]

And vice versa - redirecting from cefsharp/cef-binary#4 (comment) to here:

As a slight side note, I couldn't get the .sln to automatically restore the package (cef.sdk) for me; I don't know why it didn't work. Could you try re-cloning CefSharp and see if it works for you? I mean, from a clean slate...

Now this is something I feel we should be focusing on immediately - because that's the actual blocker for #288 being able to land as it stands right now (unless you want to focus on getting a non -pre 3.29 out the door before that?).

I already did the "clean slate thing" in both VS2010 and VS2013 - with success. We also have @brock8503 confirming above that it "just works" ... I have NuGet 2.8 - could it be that I have relied on something in that? Try upgrading if you are on 2.7 or less? Or try dropping to either NuGet PM> console or even NuGet.exe

Duuh just realizing the package doesn't contain any VS2012 libs - still you should be able to auto-restore ....

[perlun]

I already did the "clean slate thing" in both VS2010 and VS2013 - with success. We also have @brock8503 confirming above that it "just works" ... I have NuGet 2.8 - could it be that I have relied on something in that? Try upgrading if you are on 2.7 or less? Or try dropping to either NuGet PM> console or even NuGet.exe

Duh. You know what? I was having NuGet version 2.2. Of course it won't work with that kind of ancient version! 😃

I tried upgrading now to 2.8, but unfortunately it doesn't seem to make one tiny bit of a difference. 😢

I grepped the code, and I just cannot see how it fits together. Normally, in my world view, there are one or more lines added to the .csproj file to refer to the NuGet stuff. But in this case, there's nothing:

grep .nuget * -R

...does not give me anything valuable at all. And it doesn't restore the cef.sdk package on build. This is with VS2012, as previously stated, using the d18d41b commit from your fork.

What am I doing wrong? 😛

[jornh]

Duh. You know what? I was having NuGet version 2.2

Ahh! Well, you might have been the first trying that with the new native nugets but sure you won't be the last trying to use something "exotic" so I'm actually thinking it's OK to have a few teething problems now compared to just being lucky now and then run into a lot of unforeseen stuff after we let it out of the bag. 😸

I just cannot see how it fits together. Normally, in my world view, there are one or more lines added to the .csproj file to refer to the NuGet stuff.

Oh, I think you are revealing enough about "normal NuGet user expectations" now that I can see where the ends doesn't meet:

• Yes, it's not hooked into the MSBuild files - yet - so hence your understandable confusion on how the heck it fits together. (The dirty little secret - it still runs on Jan's newly added Cefsharp.native.propsin the root folder - so there is still room for drying stuff up. .targets and .props should of course be supplied by the cef.* packages so CefSharp don't need to know anything about that part. It has had that knowledge about contents in /CEF until now - and still does - it has just moved to /packages)
• Still with what is there now with both VS2010 and VS2013 when I open the Package Manager Console Window I'm greeted by an Update button that when pushed just fetches the packages and I can then build (This - or maybe another route? - was enough for @brock8503 to not stumble across any issues, without any guide, but for you it clearly wasn't)

Let's see if we can get it running on your machine with a little hand holding (maybe even some force feeding). We might need this as a sort of stepwise troubleshooting guide anyhow:

1. First step is to make sure NuGet fetches the packages. My expectations for this is it looks in /.nuget/packages.config and sees it doesn't have what's needed in /packages so when switching to the PM> console you should be prompted to install. If not try forcing it with PM> Install-Package cef.sdk -Pre
2. update: not needed any more A temporary workaround for VS2012 users: As I have mentioned previously - both here in the initial Upgraded to Chromium 31 and changed CEF dependency to use native NuGet packages #288 comment - and today in Release binary packages using NuGet #137 - cef.sdk currently has no VS2012 support. Either use VS2010/2013 or build at least the one of the Win32 libcef_dll_wrapper.libs you want to use and drop it in a freshly made VS2012/ folder along the 2010/13 ones inside cef.sdk
3. A cautious attempt at "Clean" followed by "Build only CefSharp.Core" should now hopefully give you a CefSharp.Core.dll - celebrate a bit - or report your findings if it fails.
4. If the previous step worked we are over the C++/CLI binding part and the rest is pure C# land.- where the only change compared to before is that copying .dll/.paks from /CEF now happens out of /packages/cef.redist.3.1650.zzz/something. So attempt a courageous "F5" with the Wpf Example as startup project.

[perlun]

Thanks Jørn! I now managed to use the Restore button and got a lot further with the build. Of course it failed, but now because of LINK : fatal error LNK1181: cannot open input file 'libcef_dll_wrapper.lib', which is much more predictable given that we don't have any provided binary for VS2012 yet. So, good!

The dirty little secret - it still runs on Jan's newly added Cefsharp.native.propsin the root folder - so there is still room for drying stuff up. .targets and .props should of course be supplied by the cef.* packages so CefSharp don't need to know anything about that part

Ahhh... I see. 😃 Yes, we should definitely clean that part up before we're really ready. I don't know if it's possible to add .props and .targets to .vcxproj files though? I know it works for .csproj, but they are a slightly different beast...

Anyway. I'll send you a vs2012.zip with some .lib files in a minute, by email. You can then make a new (pre)release of cef.sdk so we can compile with VS2012 also.

[jornh]

There is now a new cef.sdk version -pre2 currently at http://staging.nuget.org supporting all 12 pivot dimensions including VS2012 with cefsharp_dll_wrapper.libs supplied by @perlun - tak ven! 😄 -

A fresh zip download (or git clone I assume) from https://github.com/jornh/CefSharp/tree/a7590937ccda3c4506827a91d81bd8093b672ec4 needed a push on the NuGet "Update" button - apart from that all it needed was setting CefSharp.Wpf.Example as startup project and then a "F5"

[perlun]

There is now a new cef.sdk version -pre2 currently at http://staging.nuget.org supporting all 12 pivot dimensions including VS2012 with cefsharp_dll_wrapper.libs supplied by @perlun - tak ven! -

Most excellent, buddy! 😃 Currently downloading the package.

I can clearly see that splitting cef.sdk based on VS version will make things a lot smoother; I mean, the package is around 43 megs right now. We just need to add some clever tricks to make the packages.config depend on the "right" version depending on VS version...

Since that might not be trivial, I think we go with the monolithic approach for now. (I mean, isn't the Linux kernel a massive success after all...? 😉) Merging in a few minutes.

[perlun]

The compilation worked fine for me with VS2012 now. Just a few suggestions now:

• You can move the packages from staging to the "real" NuGet server.
• You could also add a little section to the FAQ about "how to build CefSharp", since it might be a bit non-trivial for people now that you have to manually do a package restore and all of that.