-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release binary packages using NuGet #137
Comments
@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. |
I have working nuget support and more build automation (including tests) on mwisnicki/CefSharp@vs2012+autobuild |
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. |
Yep, I saw it - very cool! Why haven't you told us before? 😉 (maybe you have) 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? |
@perlun - touché, i did say I was keen on NuGet, MSBuild however I find abhorrent, much more a Rake man. @mwisnicki - nice work! |
I didn't integrate NuGet with F5 since it would slow down build but it's as simple as invoking |
I must've had some reason why I didn't submit this as a pull request but I forgot it ;-) |
@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? |
No, I saw no reason to split it since both WPF and WinForms are provided by .NET framework and don't introduce external dependency. |
It would be more useful to split locales and multimedia. |
And DevTools. |
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:
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? |
Looks sensible. What's "devtools available" flag and what are its implications ? |
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). |
This thread in the CefSharp group gives some more details also: https://groups.google.com/d/topic/cefsharp/sgQY_9omyd4/discussion |
(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. 😄) |
@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 👯 |
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. |
@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:
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. |
That's perfectly understandable :)
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 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) |
😛 Cool! |
I think we wait with the WinForms packages for the time being. Bumping the issue to next milestone because of this. |
Add blurp on my new intentions on how to step towards closing cefsharp/CefSharp#137 - but solving "the red layer" in the cef-binary repo (and possibly Xilium.CefGlue#61 over on bitbucket https://bitbucket.org/xilium/xilium.cefglue/issue/61/make-nuget-packages)
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 |
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 |
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. |
another error :( |
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 ... Now please try to start your engine 😄 |
hah perlun broke it in 71ec685 he added dependency on the file that is missing for me but did not include it |
That one was really funny actually. 😉 |
…ually actually (or if I did, it was at least not today :-) Could be a difference with VS2012 and 2013 I guess.
@JanEggers, try again with the latest |
now it works like a charm just rebuild and done |
@brock8503 /others ...yes I'm thinking we should iterate on 3.31 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 Thoughts? Seeing anything obvious missing? |
@brock8503 (& others 😄) I pushed a Because https://staging.nuget.org/packages/CefSharp.Common/ has a 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? |
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? |
Nah, don't be so shy. 😀 Just put up a prerelease now (as far as the |
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
+1 on all that. I'll let you know when CEF is on NuGet proper (I'll start with just to copy over of |
Ah...
It's always a start. 😃 |
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 |
…p#137 - Bump version series from 3.<something> to the new 31.0.0-pre1. Note with this we don't even have a clash with unofficial version id's pushed to staging.nuget.org :-) - Change `cef.redist` dependency version indicator to allow auto-update or install of latest & greatest in the 3.1650.1562 series
For #137: Set the stage to pack and push 31.0.0-pre1 CefSharp NuGets
@jornh, can we close this now? What do you think? |
Packages pushed to |
Add blurp on my new intentions on how to step towards closing cefsharp/CefSharp#137 - but solving "the red layer" in the cef-binary repo (and possibly Xilium.CefGlue#61 over on bitbucket https://bitbucket.org/xilium/xilium.cefglue/issue/61/make-nuget-packages) Former-commit-id: 9cef99625b15298e8c5d8c3c4c3f552236040333
Add blurp on my new intentions on how to step towards closing cefsharp/CefSharp#137 - but solving "the red layer" in the cef-binary repo (and possibly Xilium.CefGlue#61 over on bitbucket https://bitbucket.org/xilium/xilium.cefglue/issue/61/make-nuget-packages) Former-commit-id: 9cef99625b15298e8c5d8c3c4c3f552236040333
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:
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:
All of this isn't so difficult really, but MSBuild isn't really my specialty...
The text was updated successfully, but these errors were encountered: