runtime: Incorrect library-root path => problem with loading CEF-files

I’m trying to embed ChromiumEmbedded into a .NET Core application.

So I download the appropriate CEF-build from spotify: http://opensource.spotify.com/cefbuilds/index.html for example http://opensource.spotify.com/cefbuilds/cef_binary_3.3626.1895.g7001d56_linux64_minimal.tar.bz2

This is my application (PdfGlue) https://github.com/ststeiger/CefGlue_NetStandard

The problem is all the CEF-native binaries in Release and Resources. They need to be copied to the output files.

However, there is a bug in .NET-Core and mono on Linux … I need to copy the files not only to the output directory, but also to /usr/share/dotnet, because the dotnet process runs there…

The same problem with mono, just that the mono-process runs in /usr/bin instead of /usr/share/dotnet. That means i need to deploy the native binaries to /usr/share/dotnet or /usr/bin, which is not possible without admin rights. Bug.

DeleteFiles("/usr/bin", allCefFiles); // /usr/bin/mono
DeleteFiles("/usr/share/dotnet", allCefFiles); // /usr/share/dotnet/dotnet

If I have to publish the application in order to run it, then I can’t debug in JetBrains Rider on Linux …

Seen from the developer’s perspective, it’s not using the right process root, because it’s using the process root of mono/dotnet instead of the application, which is wrong… I can mitigate that by export LD_LIBRARY_PATH="/path/to/my/application", but I shouldn’t have to do that in the first place.

Also, Visual Studio on Windows does not support debugging multi-process applications (CEF does not support single-process anymore). The .NET-Core application cannot be step-through debugged ! If I take the application to .NET 2 (non-core), then I can step-through debug it…

Also, when running the self-contained PdfGlue, the dotnet tool (.NET Core 2.2) continously outputs “incorrect command syntax” text to the console, both on Linux and Windows. Something is very wrong there, and that has nothing to do with CEF.