Release binary packages using NuGet

[perlun]

This has actually already been sneak-peak started; there is a CefSharp.Wpf package which I made for my own personal needs at work some month ago. However, it's far from finished and probably not really suitable for general public use yet.

The CefSharp.Wpf currently contains all the stuff needed to get a WPF-based CefSharp app running. However, this is wrong. What we should have is basically this:

• CefSharp: core package providing CefSharp.dll and all the CEF DLL:s and .pak files.
• CefSharp.Wpf: WPF-specific package providing CefSharp.Wpf
• CefSharp.WinForms: make a wild guess... ;)

One of the challenges here is the fact that we are providing a bunch of "non-standard" (from a nuget perspective) files, stuff that must exist in bin\Debug (or bin\Release) when running a CefSharp-based app, but stuff that really shouldn't have their master location there. This CodePlex issue has details about how to solve it. Basically:

• Place the libcef.dll et all in some magic folder which we determine ourselves.
• Write a little .csproj snippet to do the copying so that all the CEF dependencies magically gets copied to bin\Debug (or bin\Release, depending on the selected target in Visual Studio) when the project gets built.

All of this isn't so difficult really, but MSBuild isn't really my specialty...

[chillitom]

@perlun - re. copying dependencies I've just used "xcopy /d /i /q source* destination" or similar in a post build action on the proj file when i've needed similar in the past.

[mwisnicki]

I have working nuget support and more build automation (including tests) on mwisnicki/CefSharp@vs2012+autobuild

[perlun]

Yeah, but the thing is that we really want to make it (as much as is possible) an "F5 experience" to install the CefSharp NuGet package and get a basic web browser up and running, in the sense that it should be easy - ideally, you should just have to install the CefSharp.Wpf package and add a WebView and off you go...

From what I've understood, we cannot add stuff to the post-build actions of the .csproj file when our NuGet package gets installed. But we can inject extra MSBuild targets (that we hand-craft ourselves), so it is definitely not so hard for someone experienced with MSBuild (that singles me out 😄)

If you feel like it (and you did mention you are keen on NuGet 😉) please do give it a try.

[mwisnicki]

Hmm... I can't get the markdown syntax right, it should be this (compare).

[perlun]

Yep, I saw it - very cool! Why haven't you told us before? 😉 (maybe you have)
Anyway, I made a PR out of this: #144.

How well do you feel this stuff is working? Is it mature enough to just merge in? My NuGet package was basically a quick hack I threw up while waiting at an airport early in the morning... I needed it for personal use.

Does your NuGet package support the "F5 experience" I'm referring to above, if you see what I mean?

[chillitom]

@perlun - touché, i did say I was keen on NuGet, MSBuild however I find abhorrent, much more a Rake man.

@mwisnicki - nice work!

[mwisnicki]

I didn't integrate NuGet with F5 since it would slow down build but it's as simple as invoking build nuget in root dir.

[mwisnicki]

I must've had some reason why I didn't submit this as a pull request but I forgot it ;-)
Anyway, it's working reasonably good.

[perlun]

@chillitom - hehe, Rake is neat but slightly out of scope in this case I'd say. 😉

@mwisnicki - ah, no worries. I didn't mean it like that; to me, the "F5 experience" means more that our stuff (= CefSharp) should be easy and intuitive to consume. It's perfectly OK if the nuget building is a commandline action like that.

Do you have separate packages for the core, WinForms and WPF like I suggest in the header of this issue?

[mwisnicki]

No, I saw no reason to split it since both WPF and WinForms are provided by .NET framework and don't introduce external dependency.

[mwisnicki]

It would be more useful to split locales and multimedia.

[mwisnicki]

And DevTools.

[perlun]

OK, I see how you mean. However, to me it's about general feeling of "tidiness". Yes, it doesn't add external dependencies, but it still feels odd if we don't split since that means WPF projects using this will suddenly start referring to a couple of extra WinForms DLL:s and vice versa. It just doesn't look professional enough in my eyes (this is definitely NOT criticizing what you've done, only trying to improve on it further 😄 My own .nuspec doesn't have this distinction either, but if we start rolling this out further I definitely think we should.)

Also, for your comment about locales and multimedia - you're right; the core should probably only include the en-US locale (since you must have at least that). The extra ones can be put in a separate package, as well as the devtools.

So how about something like this:

• CefSharp.Core: libcef.dll and CefSharp.dll basically, plus the other stuff that you MUST have to be able to run.
• CefSharp.Locales: The additional locales, which I actually believe very few people really use...
• CefSharp.Multimedia: The multimedia rendering DLLs (that seems to have changed a little with CEF3 btw)
• CefSharp.DevTools: The devtools .pak
• Cefsharp.Wpf: The WPF control library
• CefSharp.WinForms: The WinForms control library

A number of packages, yes, but normal users only have to install CefSharp.Wpf or CefSharp.WinForms and NuGet will pull in CefSharp.Core automagically.

Doing this means that we definitely should set the "devtools available" setting to "false" by default, since it will not be available in many cases. What do you feel?

[mwisnicki]

Looks sensible. What's "devtools available" flag and what are its implications ?

[perlun]

I'm speaking about this flag more specifically. It means that the Chrome developer tools will be unavailable (dunno if it means the "showdevtools" method will throw exceptions or just fail).

[perlun]

This thread in the CefSharp group gives some more details also: https://groups.google.com/d/topic/cefsharp/sgQY_9omyd4/discussion

[perlun]

(btw, @mwisnicki, if you feel like doing more work in this regard - feel very free to do so! My main focus for a while is now trying to get the CEF3 branch up to a mature and stable point, so "master" will likely not be touched so much. So, feel free to "hack around" there. 😄)

[peters]

@perlun Could you begin to embed cef binaries with each future nuget release? It's getting tiresome to rewrite git history everytime a new update comes along 👯

[perlun]

Absolutely. If you are interested in trying them out, you can install CefSharp.Wpf already now. I am using myself since we needed it for work. CefSharp1 only at the moment. It has all the required CEF stuff within it. You can use a post-build action to copy the files into their proper place, that's the easiest way to get it working at the moment.

Note that this package is not based on the theory/ideas listed above. It's merely a quick hack to be able to work in a somewhat reasonable way with CefSharp in my corporate project(s) where we use it.

[perlun]

@peters - cross-replying to your comments in #201. Hehe, it's just because I used VS2010 (+ VS2013 actually) to compile this... 😄 CEF3 can be linked towards either VS2010 or 2012, but 2013 isn't really working yet (because of some C++ change causing libcef to fail - it's easy to fix but just hasn't been done yet upstream). When I've done the releases previously, I've been using VS2012 (hence VC2012 C++ redist requirement), but recently I've been more working with CefSharp in another VM where I only have VS2010 and VS2013. So, that's the reason behind it.

So we can switch to VS2012 for next pre-release if you like; I don't know, maybe 2010 is better in some senses. I honestly don't know. What was that IPC comment you were referring to?

Anyway, really happy to hear that it's working nicely for you! 😄 I spent some work on the actual packaging (getting the .props and .targets right), but I think the end result was good. As you may have seen or not, I added the CefSharp.* references conditionally in the props file, to get it working properly with both x86 and x64. So that's why you will see two references to these assemblies in your project; it's perfectly natural.

The rest of you are also welcome to try it out if you feel so inclined. Remaining to be fixed:

• The multimedia package
• The locales package
• The WinForms package + an accompanying example app, like the MinimalExample.Wpf I just hacked up.

Oh, one more thing, the DevTools, yeah. They aren't really usable from WPF at the moment (since the previous approach of opening the DevTools in a popup isn't immediately available any more, which is good in a sense since it probably means we can dock the DevTools eventually) so I don't know if we have to focus on that immediately.

[peters]

@perlun

CEF3 can be linked towards either VS2010 or 2012, but 2013 isn't really working

That's perfectly understandable :)

I added the CefSharp.* references conditionally in the props file, to get it working properly with both x86 and x64. So that's why you will see two references to these assemblies in your project; it's perfectly natural.

Yes, it's a nice solution :)

@perlun Is it possible to force cef3 to emulate touch events? (As you can enable it in chrome web inspector)

[perlun]

@peters Noooo idea whatsoever. 😄 Check with the CEF forum I guess. If CEF supports it, feel free to file an issue/work on it/whatever.

[peters]

@perlun It's certainly possible. https://code.google.com/p/cefpython/issues/detail?id=57 I'll prepare a PR (with correct whitespace indenting this time)

[perlun]

😛 Cool!

[perlun]

I think we wait with the WinForms packages for the time being. Bumping the issue to next milestone because of this.

[JanEggers]

it works now as i manually add the nuget source but i can only add it to the upper part in the nuget source settings and the lower one is readonly i guess thats the problem

[jornh]

Huh odd, can you attach a screenshot? Though, real-soon-now I will push to the non-staging http://nuget.org so then this should disappear as a problem

[JanEggers]

hah i restarted vs and the default entry from the config appeared. seems the problem is a vs bug not detecting file changes on that config. and i just changed from another branch where that file was not present.

[JanEggers]

another error :(
after downloading the package i get the error that i should restore that package and
The missing file is C:\Users\Admin\Documents\GitHub\CefSharp.nuget\NuGet.targets.

[jornh]

Hah, the classic turn off the engine, everybody get out of the car and shut the doors, you may now enter again and we can start the engine again. Should be gone as soon as we don't rely on that NuGet.config ...
http://www.hcs.harvard.edu/pnw/microsoftjoke.htm

Now please try to start your engine 😄

[JanEggers]

hah perlun broke it in 71ec685

he added dependency on the file that is missing for me but did not include it

[jornh]

after downloading the package i get the error that i should restore that package and
The missing file is C:\Users\Admin\Documents\GitHub\CefSharp.nuget\NuGet.targets.

Per added some magic on top of #288 - let me look it up .. 71ec685 Could that be it

[perlun]

http://www.hcs.harvard.edu/pnw/microsoftjoke.htm

That one was really funny actually. 😉

[perlun]

@JanEggers, try again with the latest master code. It should work much better now.

[JanEggers]

now it works like a charm just rebuild and done

[brock8503]

@perlun or @jornh are you planning on release a nuget package for master/HEAD before the 31.0.0 release date? I'd like to make sure this package is working properly (even if we are still getting the some of the winform stuff put together).

[jornh]

@brock8503 /others ...yes I'm thinking we should iterate on 3.31 -Pre packages from now (hopefully not too many :) until we will declare a 31.0.0 stable. But since the native CEF ones are now separate it's much cheaper on disk/bandwidth etc. to iterate a lot on the CefSharp packages.

I'll see if I can tick of the first box in my list: #137 (comment) tonight and then just skip ahead and push NuGets that can get MinimalExample running after NuGet Update + F5

Thoughts? Seeing anything obvious missing?

[jornh]

@brock8503 (& others 😄) I pushed a cef.redist 3.1650.1562-pre3 to 'https://staging.nuget.org'...
based on cefsharp/cef-binary@864dc92 (note only x86 ATM).

Because https://staging.nuget.org/packages/CefSharp.Common/ has a cef.redist (≥ 3.1650.1562-pre1) dependency with the proper mix of NuGet Update etc. I can get MinimalExample to upgrade itself (currently tested with VS2010) if you have staging.nuget.org set as a feed.

It might require a bit if NuGet "wiggling". I think that's something we want to iron out/document a safe guide for across VS201x versions etc.

If somebody can confirm it's working mayhaps I should push it as a -Pre to the non-staging http://nuget.org?

[perlun]

@perlun or @jornh are you planning on release a nuget package for master/HEAD before the 31.0.0 release date? I'd like to make sure this package is working properly (even if we are still getting the some of the winform stuff put together).

It might be that we should schedule a pre-version of 31.0.0 (like 31.0.0-pre1, to indicate that it's the second prerelease after 3.29.0-pre.0, to try and get it a little bit more widespreadly tested before the 31.0.0 (stable) gets released. What are your (and @jornh) thoughts about that?

[perlun]

If somebody can confirm it's working mayhaps I should push it as a -Pre to the non-staging http://nuget.org?

Nah, don't be so shy. 😀 Just put up a prerelease now (as far as the redist and sdk stuff is concerned). I can then put up a 31.0.0-pre1 release (which is then not exactly identical to your 31.0.0-pre1 on staging) and we can then also upgrade the MinimalExample to use the newer version.

[jornh]

Hey! I just didn't want to get any more of that "grmph" thrown at me 😆

... more seriously though: DEAL (but until we agreed on how/when the CefSharp.Common and CefSharp.Wpf got updated on nuget.org proper - there really was no point in pushing the CEF ones - you still needed to have the staging feed for the CefSharp pieces for "MinEx" testing mentioned above)

we should schedule a pre-version of 31.0.0 (like 31.0.0-pre1, to indicate that it's the second prerelease after 3.29.0-pre.0, to try and get it a little bit more widespreadly tested before the 31.0.0 (stable) gets released. What are your (and @jornh) thoughts about that?

+1 on all that. I'll let you know when CEF is on NuGet proper (I'll start with just to copy over of -pre3 - it's got only x86 - but hey it's the first official -Pre!)

[perlun]

but until we agreed on how/when the CefSharp.Common and CefSharp.Wpf got updated on nuget.org proper - there really was no point in pushing the CEF ones - you still needed to have the staging feed for the CefSharp pieces for "MinEx" testing mentioned above

Ah...

I'll let you know when CEF is on NuGet proper (I'll start with just to copy over of -pre3 - it's got only x86 - but hey it's the first official -Pre!)

It's always a start. 😃

[jornh]

And https://www.nuget.org/packages/cef.redist is there - so you should be able to set version in pack.bat, pack, and push the common and Wpf NuGets if you think we should have the first 31.0.0-pre1 built with VS2012 (which has been today's subject elsewhere :)

Do you think we are ready for that now?

Yes I didn't push the cef.sdk just yet. But that's not needed for consumers of the CefSharp NuGets - only those who build CefSharp from source update: And that currently still has a NuGet.config to grab from the staging feed - which seems to work just fine for peeps for now ... will be fixed as part of cefsharp/cef-binary#6

[perlun]

@jornh, can we close this now? What do you think?

[amaitland]

Packages pushed to nuget.org