CefSharp NuGet packages not installing dependencies

[shawty]

Hi Team,

First off let me congratulate you all on the great work so far, please keep it up and if/when I have the bandwidth to contribute in the future I most certainly will.

Background

After a frustrating morning trying to set up a CefSharp project for a blog post I'm about to write, I find myself here reporting what I now believe is an issue with the CefSharp NuGet packages.

The original problem that lead me to investigating this, is documented in detail here:

https://nuget.codeplex.com/workitem/3996

The crux of it is that R# < v8.2.3 has been causing the current version of NuGet to misbehave. This mis-behaviour as I mentioned is fully documented , and now resolved with the most recent R# install.

However following on from that documented issue (As you'll see in my last post) I'm still having an issue with CefSharp itself.

Symptoms

When installing from NuGet everything appears to install correctly, however when closing the NuGet GUI there are no references to CefSharp in my project, and any attempt to "using" the libraries, or include them in any code leads the visual studio compiler to error with a report that the CefSharp libs cannot be found.

A manual exploration of the projects package folder confirms that the following three packages have been downloaded:

cef.redist.3.1750.1738

CefSharp.Common.33.0.0

CefSharp.WinForms.33.0.0

These 3 packages have been unzipped into the packages folder and the files within the various folders suggest that everything needed is present.

There are no messages in the Package Manager console output or Visual Studio Error logs.

To Reproduce

1) Start up visual Studio (I'm currently using VS2013 Ultimate with Update 3)

2) Create a new WinForms project targeting .NET V4.5

3) Add a panel and a couple of buttons to the form (Not really important at this stage as not used)

4) Right click on project, open NuGet, search for 'cef'

5) Install the 3 packages above, one at a time in the following order. cef.redist, cef.common, cef.winforms

6) In the form class/code add "using CefSharp;" to the using's list, you'll see when you attempt to compile that the library is not found, or as in my case R# highlights the using statement in red to show it cannot be resolved.

If you want any further help, tweet me @shawty_ds for a direct email address.

Shawty

[jornh]

Thanks for the good issue report. Really an example for others to copy!

The crux of it is that R# < v8.2.3 has been causing the current version of NuGet to misbehave.

Oh yes, I got bitten by that one too at some point - luckily it was easy to resolve via Google.

I guess there is one crucial extra step we need to document in our FAQ/in the NuGet readme etc. until we can find and implement a better solution:

2a) Set your Platform to either x86 or x64 because AnyCPU does not currently work.

[shawty]

Hi Jornh,

Thanks for the props RE: the issue report. I run my own I.T company so I know the value of capturing as much information as possible.

RE step 2a, to be honest I hadn't noticed that there was an entry in the FAQ for that point, but I'll go look to ensure I didn't miss.

However in relation to that, I figured something similar after I opened the original incident report.

Upon submitting it, i wen't back to my project, removed all the dependencies via NuGet, set the build to X86 then re-added the CefSharp NuGet packages, but observed no change to my original report.

I've since (as way of a test to make sure the libs I've downloaded are actually working) performed a manual addition of the CefSharp kit in the following manner:

1) Added CefSharp.winforms.dll and cefsharp.dll as references by browsing for them.

2) Added any remaining DLL's and all the dll's in CefDist as "Content" to be copied to the output directory

The build now compiles and is satisfied in terms of the dependencies in my code working, but I've failed to get any output from CefSharp at all, that is no errors, no events firing, no web pages appearing even with template code based on the example in the GitHub repo.

I do however have a previous application (Based on Kevin Boyles sample) using a previous version, that is nearly Identical in set-up and works fine.

I'm still debugging this however to make sure it's not something I'm doing wrong.

If I may make a suggestion RE using NuGet to install X86vsX64 and have things switch correctly, you may want to take a look at how the SQlite team have achieved it.

I've not dug into it myself, but they've successfully managed to put together a NuGet package that deploys an X86 + X64 native library + dependencies and managed to wrap it all under a single Managed Assembly that works fine under 'AnyCPU' while choosing the appropriate platform Binary.

I'll go persue the FAQ & Readme further, make sure I've not missed anything and report back.

Regards Shawty

[jornh]

Whoa, sorry - a bit to hasty with saying "done deal there" from my side. I got a bit too hung up on that one error. I should have read your other steps more thoroughly.

See http://stackoverflow.com/questions/26307444/cefsharp-winforms-web-browser-wont-display for a few additional pointers. Hopefully that does it. Otherwise ping back here again!

Regarding wrapping everything for AnyCPU ...

you may want to take a look at how the SQlite team have achieved it.

Yep I have looked at their solution, among others, which is super nice. We already have an issue #483 suggesting it. Unfortunately that's not the same as having it implemented ...

[shawty]

No problems, it happens :-)

Ok, so based on the information in stack overflow post, I'm going to propose a set of updated steps to reproduce.

To Reproduce (Updated)

• 1) Start Visual Studio (I'm using VS2013 Ult + Update 3)
• 2) Create a new win forms project, .NET framework is V4.5, folder is created for the solution (Meaning it will have it's own private packages folder)
• 3) Before making any changes to the project, go straight into properties and set the build type to X86
• 4) Go into NuGet package manager via the GUI, search for 'cef'
• 5) In the list, select and install 'CefSharp.Winforms' (This will also install the 2 required dependencies)
• 6) Once back in your project (Using the simple example on Github as a template) , open up program.cs and make the following changes
• a) Remove everything in main

• b) Add:

  var settings = new CefSettings { BrowserSubprocessPath = "CefSharp.BrowserSubprocess.exe" }; Cef.Initialize(settings);

  var form1 = new Form1(); Application.Run(form1);

• c) Add 'using CefSharp' to the using's list in program.cs
• 7) At this point the install fails. Visual Studio is unable to resolve any of the CefSharp dependencies installed via NuGet.

Further points to be noted

I had come across some other sources of information with regards to 'Cef.Initialize' including the notes in the Wiki here on GitHub, as noted previously I tried a manual linking of the assemblies (Given the current NuGet problems) and while this manual referencing & linking resolved the ability to reference CefSharp (Thus leading me to the blank browser comment above) I have not yet been able to resolve either

'CefSettings' or any static object with the name of 'Cef'

Nor have I been able to find 'Initialize' anywhere in any of the current assemblies pulled down from NuGet (currently 33.0.0 as of this typing)

I've opened the assemblies up with Teleik Just Decompile, I've examined them with the Resharper assembly explorer and had a peek using the Visual Studio Object Browser.

None of these 3 tools reveal the existence of 'CefSettings' or 'Cef'

When I do attempt to access 'CefSettings' however, intellisense prompts me and suggests I may be looking for 'CefSettingsBase', however when I try this I get an error that suggests this object cannot be directly newed up using the 'new' statement.

My Next point of investigation is going to be comparing the solution file in the simple example repo, to the solution file in my project in order to see if NuGet has made the required changes, I'll report back on my findings once this is done.

regards Shawty

[amaitland]

5) In the list, select and install 'CefSharp.Winforms' (This will also install the 2 required dependencies) 6) Once back in your project (Using the simple example on Github as a template) , open up program.cs and make the following changes

After successfully installing CefSharp.WinForms in step 5, close Visual Studio (fully close, not just close solution), then reopen your solution in Visual Studio. The missing references should then be there.

Let me know how that goes.

[amaitland]

'CefSettings' or any static object with the name of 'Cef'

Nor have I been able to find 'Initialize' anywhere in any of the current assemblies pulled down from NuGet (currently 33.0.0 as of this typing)

The CefSharp.MinimalExample project now includes a WinForms example, the relevant code is here https://github.com/cefsharp/CefSharp.MinimalExample/blob/master/CefSharp.MinimalExample.WinForms/Program.cs

Thanks for the detailed feedback and bug report. As anyone can edit the wiki entires, any contribution to either https://github.com/cefsharp/CefSharp/wiki/Frequently-asked-questions or a new entry I created a week ago https://github.com/cefsharp/CefSharp/wiki/CefSharp3-QuickStart-Guide would be greatly appreciated! :smile:

[shawty]

Hi Amaitland,

5) In the list, select and install 'CefSharp.Winforms' (This will also install the 2 required dependencies) 6) Once back in your project (Using the simple example on Github as a template) , open up program.cs and make the following changes

After successfully installing CefSharp.WinForms in step 5, close Visual Studio (fully close, not just close solution), then reopen your solution in Visual Studio. The missing references should then be there.

Let me know how that goes.

I tried that and sure enough when I restarted all the dependencies do indeed appear in the references tree, but all with yellow warning triangles next to them.

I don't seem to be able to see any reason for the error though, that is VS offers me no clue as to why the Yellow triangles.

The references in my code also are still unable to be satisfied and in my case at least all show red due to me having R# installed.

[shawty]

Thanks for the detailed feedback and bug report. As anyone can edit the wiki entires, any contribution to either https://github.com/cefsharp/CefSharp/wiki/Frequently-asked-questions or a new entry I created a week ago https://github.com/cefsharp/CefSharp/wiki/CefSharp3-QuickStart-Guide would be greatly appreciated! :smile:

A may just do that, as I've discovered another reason why the browser may appear blank that doesn't appear to have been documented anywhere yet.

With regards to the code in the minimal example, that's what I was basing my code off when I realized I couldn't find cef & cefsettings, I may however have a further insight on that.

On the machine I'm writing this on (the first machine that experienced problems) my copy of VS2013 appears to possibly have been corrupt in some way. I noticed during this whole debugging episode that I was no longer able to choose .NET4 as a target in my IDE. I did however have another machine that had only just been re-installed a few weeks ago, this machine was able to target .NET4.

Doing a manual install of CefSharp on this 'fresh' machine and setting .NET4 as the target, then actually showed my the 'Cef' and 'CefSettings' static objects, allowing me to use them in program.cs to initialize the browser. Also of note, on the fresh machine, when I did the manual install I also added a reference to the exe stub (Thus making that too appear in the references tree) that you provide for WPF projects.

I'm not sure if it was the .NET4 selection, or the extra addition of the EXE that finally gave me access, but that combined with the strangeness I discovered in starting the browser up, I finally managed to get the current version of CefSharp to load up and display a web view in my windows form app.

I want to try a few more things first, and plus it's getting late here in the UK now, but tomorrow I'll put a final post on here with my summary/findings in.

[amaitland]

I don't seem to be able to see any reason for the error though, that is VS offers me no clue as to why the Yellow triangles.

I just ignore the yellow triangles these days, everything usually works without a hitch, sometimes I find that doing a clean and rebuild helps with some of the little glitches. The joys of dealing with VC++!

The references in my code also are still unable to be satisfied and in my case at least all show red due to me having R# installed.

Occasionally R# shows red, even though everything is working and compiles, usually doing a clean, rebuild and then restart VS solves the issue.

[jornh]

@shawty good to hear you are making progress with another machine. Though usually that's a little to much to expect of people in order to get to a running CefSharp build :wink:

I actually see the same behavior here with the yellow triangles etc. I think I can offer an explanation for them though:

• The CefSharp packages and build currently relies on for copying/referencing either x86 or x64 DLLs and content is based on NuGet adding .target and .props files to MSBuild http://docs.nuget.org/docs/reference/support-for-native-projects#MSBuild_Integration
• The copying of CefSharp.Core.dll happens via this .targets file in the CefSharp.Common NuGet: https://github.com/cefsharp/CefSharp/blob/v33.0.0/NuGet/CefSharp.Common.targets
• See https://github.com/cefsharp/CefSharp/blob/v33.0.0/NuGet/CefSharp.Common.props for the mechanism that filters either x64 or x86 DLLs depending on the chosen $(Platform). It should explain why half of the references get yellow triangles.

The same mechanisms are used across all the NuGet packages.

CefSharp clearly needs a better, more robust, way of handling this. One effort towards that is to split the packages into separate ones for x86 and x64. It's being worked on from the lower native CEF packages up currently in https://github.com/cefsharp/cef-binary/pull/14 and some related pull requests.

[amaitland]

I'm interested to see how sqlite handles things. The list of sqlite packages on nuget is quite large, is there a particular one that I should be looking at?

[shawty]

@jornh - we do now exist in a world of consumers, there's a diminishing number of producers these days especially in the OSS world. I used to run a lot of OSS projects in my younger days, but eventually I had to hand them off to to others, I just didn't have the time that was being requested of me to be free/unpaid customer support all the time, especially when team members joining and wanting to help where greatly outnumbered by those commanding help. These days I try to help where I can when I can (Such as I am here) but I frequently don't have the time to dedicate all my resources to any one particular project.

@amaitland - Yes alex, the main package "System.Data.SQLite", in that NuGet package they offer a method that installs an x86 and a x64 build, they also install a number of common bit's that are processor agnostic. This package is usually the first one in the list and has "(x86/x64)" in the package title. The other 3 you may see when looking for it "Core", "LINQ" & "EF6" are just the main package split into it's 3 constituent parts.

[shawty]

Issue Update 21/10

Since the problems encountered yesterday, and the many bits of advice and solutions tested I have now been able to get an application successfully working on both the older machine (That initially had the problems) and the newer "Fresher" machine.

There are still some problems however, what follows is my interpretation of what I believe may be the root cause for these issues.

NuGet

As noted above, closing VS right down then re-opening does indeed show the references added to the project by NuGet, however all 6 of the available linkages show with a yellow triangle. For me this was just as bad as not having the references at all.

VS2013 Ultimate still refused to resolve the needed dependencies and thus build errors where caused with respect to the various CefSharp objects being missing.

I did however try a few experiments and noted the following results.

• 1) Remove ALL 6 of the references manually (But NOT removing the package installations from NuGet), then setting the project to either X86 or X64, and referencing only the 3 DLL's needed for the chosen platform.

result

• Linked references worked, application code was able to compile BUT various dependencies (Such as the required DLL's from the cef redistributable package) had to be copied to the application output folder manually. Strangely however some things remained automatic, for instance the 'Locales' folder copied fine.
• 2) Adding the 3 CefSharp NuGet packages to the project, closing down and restarting Visual Studio, reloading the project and attempting build.

result

• Packages added successfully, and on returning to VS all 6 references show as Yellow triangles in the VS references tree. No build is possible, references are not resolved in the application code, Nothing is copied to the applications output folder on a build attempt either. One thing of interest that did intrigue me though is that ALL 6 of the file paths appeared to have previous folder paths in them.

EG: "path\path..\path\path\file"

• I know from previous experience that having relative path's like this mixed inside absolute paths sends MSBuild into a bit of a blind panic. I can look it up in the MSBuild bible, but I don't have the book to hand at the moment as I type this.
• 3) As for step 2, but upon restarting ensure the project is set to a specific processor type (x86 or x64) then removing the 3 references from the reference tree that are not needed EG: if x64 is chosen, remove the 3 x86 packages)

result

• same as for attempt 2, references could not be loaded, same relative path segment is seen in the path that VS is trying to find, but the VS output log clearly states the file cannot be found even though a manual examination of the location shows the file to be there.

The only way currently to get the CefSharp packages to work via NuGet is as follows:

• 1) Install the packages in NuGet
• 2) Restart Visual Studio
• 3) Remove all 6 references in the ref tree
• 4) Set platform build to either X86 or X64
• 5) Add the 3 required DLL's as references from the package folder matching the Xxx setting as follows: "CefSharp.Core.dll", "CefSharp.dll" & "CefSharp.Winforms.dll"
• 6) Manually copy everything in "packages\cef.redist.xxx\CEF(x86 or x64)\ to the application output folder "Debug or Release", then copy the folder 'locales' and the 2 .pak files from the CEF folder to the application output folder.

The Blank Browser Output

Bit of a strange one this.

Following the template in the simple win-forms example, as previously noted even when the references where happy and everything in the main form was satisfied the objects 'Cef' and 'CefSettings' remained not found while trying to initialize CefSharp.

Beacuse the init couldn't be found and was not called, this lead to a blank browser.

However, after clearing the NuGet package cache, re-installing the package, then following the method outlined under NuGet to get things working, Cef & CefSettings re-appeared and have worked since.

This however did not resolve the Blank Browser output, what eventually resolved that was putting my Browser init code (That is the new Chromium Web Browser bit) in my Forms constructor.

I initially had the "browser = new ChromiumWebBrowser...." portion of my code triggered from a button handler on my form, as I initially didn't want any content loaded until I pressed another button. However, loading the application and rendering the browser displayed nothing on the form doing this.

Opening the dev tools however clearly showed the browser had initialized, as there was a document DOM and everything else expected there.

Moving this set up code back to the Ctor, then letting it run at start up resolved this and the initial browser invocation worked.

The conclusion is that, if you want to not load anything into an embedded CefSharp object at start-up, then you must initialize the browser object in the form Ctor but pass in an empty string instead of a Url/Html file name. This will cause a blank browser to appear on the form , which if you add using a panel component can easily be hidden. You would then use 'load' to perform navigation when needed.

I will however add a Wiki post detailing this.

Update

Wiki page has been added : https://github.com/cefsharp/CefSharp/wiki/Trouble-Shooting

[amaitland]

@shawty Thanks for the very detailed wiki article. There are probably a few things that need to be addressed programmatically to reduce the number of questions.

• DockStyle.Fill should be the default.
• References to BrowserSubprocessPath = "CefSharp.BrowserSubprocess.exe" should be removed from as many places as possible, it's actually the default and only needs to be changed if you move the exe outside your bin folder, having it in examples just seems to confuse people.
• Some sort of dependency check on Initialize to make sure at least the required dependencies are present.

Overall the WinForms control isn't quite as mature compared to the WPF version. I've tried to get it up to spec over the last couple of months, still has a few resize/rendering issues that will hopefully be addressed in the near future.

[shawty]

@amaitland - I would agree with that. If something can be set programatically then it's usually a good Idea to do so.

I've made some changes to the Wiki post to reflect the browser exe stub change.

[shawty]

@amaitland - feel free to delete this comment by the way (I don't know any other way to get a message to you) - the reason I'm putting effort into getting this working is I write for here commercially:

http://www.codeguru.com/columns/dotnet/

And one of my posts for this months submissions id on the subject of using CefSharp to create an HTML UI for your WebForms applications.

In order to demonstarte the concepts, I need to build a working winforms app, and will likley make it available on my own git hub page once done.

:-)

[amaitland]

@amaitland - I would agree with that. If something can be set programatically then it's usually a good Idea to do so.

Changes including DockStyle are in #521, hopefully it'll be merged in the coming days.

I've made some changes to the Wiki post to reflect the browser exe stub change.

Thanks, it's not really a big deal, I just see a lot of code copy and pasted that includes that line, which only needs to be set if your doing something other than the default :smile:

@amaitland - feel free to delete this comment by the way (I don't know any other way to get a message to you) - the reason I'm putting effort into getting this working is I write for here commercially:

Cool! Post a link when the article is done :smile:

[shawty]

@amaitland - I most certainly will do. Actually if you ping me on twitter @shawty_ds , I'll follow then let you know how to contact me directly, rather than using notes on this issue :-)

[jornh]

Wow, Interesting news @shawty! I guess we can't hide under our rock any more then. If nothing else this for sure will help us mature CefSharp (as much as we can given our limited CefSharp OSS time). You probably should have chosen WPF as the more mature as @amaitland said ... but then again we could just have kept the -pre label on WinForms a bit more. You're of course free to do what you see fit :smile:

Exciting times :roller_coaster: ahead!

[jornh]

@shawty in this https://github.com/cefsharp/CefSharp/issues/520#issuecomment-59909002 you said:

EG: "path\path..\path\path\file"

I'm currently starring at the "missing" \ before the .. in that path of yours! I have never experienced (noticed) that on my own machine, VS2013 Proff. - Upd. 3 BTW. But it looks exactly like what was reported in https://github.com/cefsharp/CefSharp/issues/458#issuecomment-53151524 but later dismissed https://github.com/cefsharp/CefSharp.MinimalExample/issues/8#issuecomment-53165053 as a copy/paste error. I wonder if it has to do with VS Ultimate, a specific R# version or any other plugin. It would be good if we could narrow it down somehow.

[shawty]

@jornh actually that might be a typo I missed, just looked at the Laptop which has sat in standby untouched since I typed that last night, that should be

EG: "path\path..\path\path\file"

The comment still stands though RE using relative path parts. I have here what many call the MS-Build bible "Inside the Microsoft Build Engine", the book is written by the guy that wrote 'MSBuild' and at numerous points he makes reference to not using periods in paths unless you really have too.

The recommended way of creating paths to place files into is to use the various environment variables such as $solution, $output etc then using the various functions to add remove parts of the string thus forming an absolute path.

I'll take a nosey at the build scripts for you later if you want and let you know my thoughts, but right now I have to get this blog post plus one other finished :-) oh and finish the last 30 pages of my current Ebook before I can even consider it.

RE: Using win-forms, yup I would probably agree that WPF would be the way forward, and I do intend to mention that WPF is preferable, but when penning the idea for the blog post I already had a win-forms sample application to hand from a previous experiment. Also (Not for the blog post, but for another application I have in the works) I'm toying with the idea of building a mini custom browser and linking it in some way to a windows service that I've written using Owin & Katana, this service is standard windows GDI as is the server it's running on, but the service provides it's own UI using Razor, I was considering somehow linking a win-form viewer to it that would view the razor UI only on the server it runs on, a server which doesn't have a graphics card capable of even asking what a WPF app can do!!

[shawty]

Hi All, one last quick update. Just tried to 'RegisterJsObject' and after following the FAQ etc, realized that it's not present in 33.0.0.0, Iv'e just tried the 33.1.0 pre release, and still got an exception only this time rather than a not implemented one it was a null ref.

I need the 'RegisterJsObject' to work for this example but I'll open a separate ticket for that though, since I'm now out of time for this months blog posts, I'm going to swap the one involving CefSharp to next month, and instead replace it with a subject I had in my backlog queue for this month.

Once I get my backlog cleared, I'll see what I can do to help troubleshoot the null ref, but as I have to get these posts written I can't spend any more time on the cef one for the next couple of weeks.

I'll keep an eye on this issue however (I'm subscribed to Email updates)

If you want me to close the issue I'm happy too.

Shawty

[amaitland]

still got an exception only this time rather than a not implemented one it was a null ref.

Can you post a stack trace? Any any sample code you have to reproduce. Most of testing to date has been done on the WPF example, though I am aware of a few people using the WinForms version.

[amaitland]

Substantial progress has been made in terms of overall development, so I'd suggest upgrading to 37.0.0-pre01. If there's still a problem, I'd ask that you create a new issue with specific details.