running cefglue.winapi.demo .net core

[meareindel]

Hi,

Perhaps it is related with #66 and new release will fix these, I would like to describe some problems I've faced with:

1. Starting debugging from VS 2017
   1.1) x86 configuration just fails to run
   1.2) x64 configuration opens window with white background and there is lot of messages in console like that (perhaps it's because there was some changes in dotnet 2.2):

[0301/111628.607:ERROR:browser_gpu_channel_host_factory.cc(119)] Failed to launch GPU process.
[0301/111628.607:ERROR:gpu_process_transport_factory.cc(1026)] Lost UI shared context.
Unknown option: --type=gpu-process
Unknown option: --no-sandbox
Unknown option: --locales-dir-path=C:\Users\admin\Downloads\Chromely-master\src\Demos\Chromely.CefGlue.Winapi.netCoreDemo\bin\x64\Debug\netcoreapp2.0\locales
Unknown option: --log-file=logs\chromely.cef_new.log
Unknown option: --log-severity=info
Unknown option: --resources-dir-path=C:\Users\admin\Downloads\Chromely-master\src\Demos\Chromely.CefGlue.Winapi.netCoreDemo\bin\x64\Debug\netcoreapp2.0
Unknown option: --lang=en-US
Unknown option: --gpu-preferences=KAAAAAAAAACAAwBAAQAAAAAAAAAAAGAAEAAAAAAAAAAAAAAAAAAAACgAAAAEAAAAIAAAAAAAAAAoAAAAAAAAADAAAAAAAAAAOAAAAAAAAAAQAAAAAAAAAAAAAAAKAAAAEAAAAAAAAAAAAAAACwAAABAAAAAAAAAAAQAAAAoAAAAQAAAAAAAAAAEAAAALAAAA
Unknown option: --use-gl=swiftshader-webgl
Unknown option: --locales-dir-path=C:\Users\admin\Downloads\Chromely-master\src\Demos\Chromely.CefGlue.Winapi.netCoreDemo\bin\x64\Debug\netcoreapp2.0\locales
Unknown option: --log-file=logs\chromely.cef_new.log
Unknown option: --log-severity=info
Unknown option: --resources-dir-path=C:\Users\admin\Downloads\Chromely-master\src\Demos\Chromely.CefGlue.Winapi.netCoreDemo\bin\x64\Debug\netcoreapp2.0
Unknown option: --lang=en-US
Unknown option: --service-request-channel-token=F38D75EA4E8188D7596E82744A8D3E9A
Unknown option: --mojo-platform-channel-handle=1788
.NET Command Line Tools (2.2.102)
Usage: dotnet [runtime-options] [path-to-application] [arguments]

2. Publishing self-contained app from VS 2017 (and from dotnet publish)
   2.1) CEF binaries does not get copied to publish folder (not all of them). It is needed to manually copy them to publish folder from build folder
   2.2) Even if I publish with -r linux-64 CEF binaries still get win-platform downloaded. It is needed to manually download linux-platform binaries to publish folder as described at CefGlue Application Layout
3. Running self-contained app
   3.1) Runs ok in Windows 10 1809 (-r win-x64)
   3.2) Fails to run in Linux (AstraLinux SE/Debian 9 Stretch; -r linux-64): segmentation fault error, dmesg says that:

traps: cefglue_winapi_[19131] trap int3 ip:7082a73a5968 sp:7ffea8bb9210 error:0 in libcef.so[7082a4630000+5830000]

Any thoughts? Perhaps I am missing something...

[mattkol]

@meareindel thanks for detailed description of the issues. Yes, they are all related to #66.

1. You are likely trying to debug as-is in the demo. That will not work for .NET core. From v68 SingleProcess is no longer supported and it has to be published. So debugging may be a tough situation in that regard unless your had a subprocess. This is discussed in Help Wanted - Turn into true cross-platform #66.

2. Please see - Help Wanted - Turn into true cross-platform #66 (comment)

3. That error you get is really strange. Never seen such before. For Help Wanted - Turn into true cross-platform #66 @FrankPfattheicher has made a fix. I will suggest you try the latest code (please remove nuget references for Chromely.CefGlue.Gtk).

Please let @FrankPfattheicher and I know what your findings are as that will help us improve on Chromely running on Linux.

Thanks.

[meareindel]

@mattkol thanks for quick answer.

1. I think it's possible to make custom VS (VSCode also if it is needed) launch configuration for that. It would publish app in debug configuration, start it and attach to it all in one. Then it could be described as a snippet in wiki so others could benefit. Perhaps I'll try to make this one later.
2. Comment you provided tells about CPU determining, but I meant that cefbinariesdownloader always downloads libcef.dll instead of libcef.so which is needed for linux. And if I correctly understand the 'how it works', there is no binding to runtime identifier in Chromely.CefGlue.Winapi.props (no binding to --os arg):
   

   Chromely/src/Chromely.CefGlue.Winapi/build/Chromely.CefGlue.Winapi.props

   Lines 18 to 21 in 1437e1b

   	<Target Name="DownloadCefBinaries" AfterTargets="CoreCompile">
   	<Message Text="$(DownloadCefBinariesExe) download $(ChromiumVersionParameter) --cef-binary-version=$(CefVersionParameter) --cpu=$(Platform) --dest=&quot;$(MSBuildProjectDirectory)\$(OutputPath)&quot;" Importance="high" />
   	<Exec Command="$(DownloadCefBinariesExe) download $(ChromiumVersionParameter) --cef-binary-version=$(CefVersionParameter) --cpu=$(Platform) --dest=&quot;$(MSBuildProjectDirectory)\$(OutputPath)&quot;" ContinueOnError="WarnAndContinue"/>
   	</Target>

   
   Also cef binaries download does not start if Chromely.CefGlue.Winapi project reference used instead of package reference - as far as I understand props only get included when packaging. Does it work as planned?
3. Tried that, no luck - still segmentation fault. Perhaps will try later on clean Debian 9. Are there any limitations for updating Cef to latest build? It possibly could be another way to resolve this.

cc @FrankPfattheicher

[FrankPfattheicher]

@meareindel do you want to give my sample https://github.com/FrankPfattheicher/stonehenge.Chromely a try?
It includes a CEF loader which loads the necessary version at program start if not already available.
I plan to move this loader to the chromely project later....

I tested it on Windows using VS2017 .NET 4.7.1, and .NET core 2.1.
Ubuntu 18.10 using JetBrains Rider or command line .NET core 2.1.
The core versions has to be published --self-contained

[mattkol]

@meareindel you are right on item # 2. Though it is working as planned, the OS version value was not set in props file. We are taking a new direction on this, this is what @FrankPfattheicher code changes will fix. Thanks for pointing all these out.

[meareindel]

Thanks, guys, will see later that. It's not the critical point though comparing to CEF crash in linux. Will investigate that first.

[meareindel]

@mattkol, how do version.g.cs get generated? I want to try to bind to one of later CEF to see if it makes any difference to run under linux.

[meareindel]

got #34 on clean latest Debian 9. Is it still actual - I mean, is it still not truly crossplatform?

[FrankPfattheicher]

@meareindel We are still working on "truly crossplatform"...
For now you have to decide between platforms as in

#if LINUX
using Chromely.CefGlue.Gtk.BrowserWindow;
#else
using Chromely.CefGlue.Winapi.BrowserWindow;
#endif

Please look at my example at
https://github.com/FrankPfattheicher/stonehenge.Chromely/blob/master/StonehengeChromelySample/StonehengeChromelySample/Program.cs

[mattkol]

@meareindel we do not have control over how CefGlue files are generated. This was a choice between using an external dependency - https://www.nuget.org/packages/Chromely.Unofficial.CefGlue.NetStd/ and embedding the code. The later was chosen.

So any code in the folder CefGlue is always going to be as-is. It is a NetStandard port of CefGlue.

[meareindel]

@mattkol why not to use package reference?

[meareindel]

@FrankPfattheicher thanks, your examples showed the way, I've managed to publish and run chromely demo both on win and debian.

There are some error messages in console though:

[0305/114403.664234:ERROR:gl_implementation.cc(292)] Failed to load /home/user/publish/swiftshader/libGLESv2.so: /home/user/publish/swiftshader/libGLESv2.so: cannot open shared object file: no such file or directory
[0305/114403.668165:ERROR:viz_main_impl.cc(201)] Exiting GPU process due to errors during initialization

but demo works regardless of it. I've moved libGLESv2.so and also libGLES.so to 'swiftshader' subfolder and messages gone, but no changes in demo itself.

I think issue could be closed now.

[mattkol]

@meareindel we could use the package reference. Chromely was started that way. The reason I did that was that the package was created by us, so why an extra dependency that WILL not change. If this is open to package reference, then developers may add references that are not supported - CefGlue is strict on versioning. Also my thought is this way, if there will be a change specifically for Chromely - it can be done without making a change to the published package that are used by non-Chromely projects.

CefGlue is not the only embedded code - the container - SimpleContainer, and json mapper LitJson are embedded.

Having said that, nothing here is written in stone, if there is need to revert that, it will be done.

Thanks.

[mattkol]

but demo works regardless of it. I've moved libGLESv2.so and also libGLES.so to 'swiftshader' subfolder and messages gone, but no changes in demo itself.

@meareindel good catch there. So when you did that, did you leave copies of libGLESv2.so and libGLES.so in the main folder?

[meareindel]

@mattkol , yes I did. Later I've also noticed readme.txt in cef binaries bundle where 'libEGL'-stuff are described. As far as I understood, neither of swiftshader/ or root folder libEGL-binaries are strictly needed - these are just for WebGL. Except that you doing some WebGL-stuff in your app. But I did not get a try yet to remove these.

It would also be nice to add linux cef binaries symbol stripping into build/binaries download pipeline (see this) so these would be just around 200Mb instead of 600Mb (and even around 10Mb less if libEGL would go away). I don't know yet if it is possible to run linux strip utility in windows though. There are also could be some other ways to reduce binaries size but I've not managed to get to cef-forum (https://magpcss.org) where these are supposed to be described - I have ERR_CONNECTION_RESET there for some reason.

[mattkol]

@meareindel so may be we should look at enabling/disabling WebGL.

Good info on Linux cef binaries size reduction. I looked at it earlier but I felt developers should decide if that s the route they want to take, but we will see how easy it can be to do that. May be @FrankPfattheicher is already looking at that too.

Thanks.

[FrankPfattheicher]

Created a User Story so this will not be lost:
https://dev.azure.com/ChromelyApps/Chromely/_workitems/edit/23/

[FrankPfattheicher]

@meareindel if you want to deploy smaller packages look at my loader. With that you don't need to deploy CEF at all. It is downloaded and installed on the first run.
Currently the loder is only in my Stonehenge.Chromely project.
It will be in the package when the cross-platform branch is merged.