Bump cef.sdk package to 3.2062.1876-pre1 with VS2013 specific libs too

[jornh]

BTW I guess we have to exercise "the split" on x86/x64 a bit on this branch with how it affects NuGet users (and prepare some communication?). We can use CefSharp.MinimalExample + start from scratch scenarios like the one painfully documented in #520 for that.

Maybe we can even move CefSharp.* packages a bit more towards a more normal NuGet structure with lib folders and such? We just need to find a way to make sure we can still install both x86 and x64 in parallel - or should we go for a AnyCPU package?

Hmm - forgive me for thinking out loud above - I hope some of it brings us forward though ;)

[amaitland]

Should this include the -pre tag? I can't remember

[jornh]

I guess it depends on when we push CefSharp.* packages?

If we wait until we have verified the cef.* ones via use here in the CefSharp repo and pushed them to NuGet proper as non-pre I think we can leave it?

[amaitland]

Verifying the cef.* packages does make a lot of sense, no point creating extra work for ourselves 😄

[jornh]

Yeah, "measure twice, cut once" and if we can find a way to get what little community CefSharp has help do some of the verification by kicking tires on -pre NuGet packages etc. I think we should be able to speed up a bit without sacrificing stability.

OK to merge this PR then?

update AppVeyor seems happy about it - which should say it at the least still can build on VS2012 😜

[amaitland]

OK to merge this PR then?

Merge away 😄

[amaitland]

BTW I guess we have to exercise "the split" on x86/x64 a bit on this branch with how it affects NuGet users (and prepare some communication?). We can use CefSharp.MinimalExample + start from scratch scenarios like the one painfully documented in #520 for that.

What about having a CefSharp.Wpf and CefSharp.WinForms package that simply contains dependencies to both the x64 and x86 packages? That would allow users to simply upgrade as is. I was reading that Nuget allows a readme file that can be opened upon install, perhaps we can explain the situation there?

Maybe we can even move CefSharp.* packages a bit more towards a more normal NuGet structure with lib folders and such?

Normalising sounds like an excellent idea 👍

We just need to find a way to make sure we can still install both x86 and x64 in parallel - or should we go for a AnyCPU package?

How would an AnyCPU package work?

Hmm - forgive me for thinking out loud above - I hope some of it brings us forward though ;)

Keep the brain dumps coming 😄

[jornh]

What about having a CefSharp.Wpf and CefSharp.WinForms package that simply contains dependencies to both the x64 and x86 packages?

Oh yeah, that's the fourth scenario, here we go with some more brain dumping:

1. PM> Install-Package CefSharp.[Wpf|WinForms].x86 means my application is already a good old faithful x86 thing or I'm happy with converting required parts of it into that AND I just need a minimal install that can run on any machine/OS version.
2. PM> Install-Package CefSharp.[Wpf|WinForms].x64 says, gimme just the x64 pieces I don't have or care about any 32bit users.
3. PM> Install-Package CefSharp.[Wpf|WinForms].AnyCPU I don't care about distribution size, I prefer to build and distribute ONE version picking the optimal binaries on any users machine - this one means implementing simplify deployment by including native dll #483 - which @perlun BTW was dreaming about back in the last reply-blurp of HTML5 video in MinEx (MinimalExample) should "just work" cef-binary#4 (comment)
4. PM> Install-Package CefSharp.[Wpf|WinForms] just a convenience method of doing 1. and 2. above. The sad thing about this one is that it requires some kind of guard-mechanism like the if's we currently have in our package .props and .targets. It puts restrictions on what we can do with the .x64 and .x86 packages (I'm fearing we can't move stuff to lib/ folders in those packages, but maybe we can if we add platform size to file names as suggested by @AaronLS in 2) of Nuget doesn't add references (in the usual way) #458 (comment)).