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 ?