Publish self-contained .NET 5 application

[peters]

First of all, thank you for the great effort of enabling .NET core support. I tried updating our kiosk software from net48 to net5.0-windows. Using the latest pre-release this was quite easy. But when I published the application using a self-contained runtime it would run but was unable to render the web browser control. After a bit of experimenting I noticed that if I copy all CefSharp assets to a separate directory and changed CefSettings.BrowserSubprocessPath property to Path.Combine(currentDirectory, "cefsharp", "CefSharp.BrowserSubprocess.exe") and not deleting the aforementioned assets from the publish directory everything works as it should.

• What version of the product are you using?

  • v88.2.40-pre

• What architecture x86 or x64?

  • x64

• On what operating system?

  • Windows 10

• Are you using WinForms, WPF or OffScreen?

  • WPF

• What steps will reproduce the problem?

  • Install .NET 5.0.3 SDK
  • git clone https://github.com/cefsharp/CefSharp.MinimalExample.git
  • Change CefSharp.MinimalExample.Wpf.csproj target framework to net5.0-windows
  • Update CefSharp.Wpf.NETCore package reference to 88.2.40-pre
  • cd CefSharp.MinimalExample
  • dotnet publish .\CefSharp.MinimalExample.netcore.sln -c Release --runtime win-x64 --self-contained
  • .\CefSharp.MinimalExample.Wpf\bin.netcore\x64\Release\net5.0-windows\win-x64\publish\CefSharp.MinimalExample.Wpf.netcore.exe

• What is the expected output? What do you see instead?

  • The application starts but is fails to load google.com website

[amaitland]

• Change CefSharp.MinimalExample.Wpf.csproj target framework to net5.0-windows

Does it work if you publish leaving the TargetFramework unchanged? (Publish for netcoreapp3.1).

The BrowserSubprocess is actually a netcoreapp3.1 exe with <RollForward>Major</RollForward> specified so it should run with a newer .Net 5 runtime installed. In my limited testing this workings when using the installed runtime. I suspect (though haven't done any testing) that it's not working when self contained, possibly the framework version used is trimmed down and missing pieces required for the rollforward.

For this use case I expect you'll need to self host the BrowserSubprocess using your apps own exe. See https://github.com/cefsharp/CefSharp/blob/cefsharp/87/CefSharp.Core/BrowserSubprocess/SelfHost.cs#L26

Whilst I understand this is a little harder for WPF as there's no Main by default, it's pretty trivial to add one.

There are some linker errors trying to compile the VC++ projects targeting net5.0 so there's no way to currently build a full set of net5.0 libraries. (This will likely need to be raised with MS).

[peters]

Does it work if you publish leaving the TargetFramework unchanged? (Publish for netcoreapp3.1).

I will test.

For this use case I expect you'll need to self host the BrowserSubprocess using your apps own exe. See https://github.com/cefsharp/CefSharp/blob/cefsharp/87/CefSharp.Core/BrowserSubprocess/SelfHost.cs#L26

Great! Then that is an acceptable solution for me.

Thank you :)

[dustinrowland12]

I also ran into an issue publishing with self-contained selected using CefSharp.Winforms.NETCore 87.1.132.

I first tried publishing with my own application with target framework of net5.0-windows. When running my published executable, the window opens, but the page does not load and my mouse pointer constantly toggles the loading icon on/off.

I then tried publishing the minimal example that targets netcoreapp3.1 with self-contained selected. The same thing happens when I run the published executable. The window opens, but the page doesn't load, and the mouse constantly toggles loading icon on/off. Screenshot attached of what loads when running the executable. When I use "framework-dependent" instead of "self-contained", the published executable works perfectly.

I checked out the potential fix you mentioned for self hosting the BrowserSubprocess. I added the following code to my Main method and publishing with self-contained on .NET 5 for WinForms seems to work:

Cef.EnableHighDPISupport();
// added this section below
var exitCode = CefSharp.BrowserSubprocess.SelfHost.Main(args);
if (exitCode >= 0)
{
    return exitCode;`
}
var settings = new CefSettings();`
settings.BrowserSubprocessPath = System.IO.Path.GetFullPath("{InsertMyExecutableFile.exe}");

[amaitland]

The BrowserSubprocess is actually a netcoreapp3.1 exe with <RollForward>Major</RollForward> specified so it should run with a newer .Net 5 runtime installed. In my limited testing this workings when using the installed runtime. I suspect (though haven't done any testing) that it's not working when self contained, possibly the framework version used is trimmed down and missing pieces required for the rollforward.

This may actually have nothing to do with it at all. The CefSharp.BrowserSubprocess.exe distributed with the Nuget packages doesn't want to use the self contained .Net Core/Net 5 distribution. As the generated exe is a native executable it's not really going to be easy to debug the difference.

For publishing self contained and single file applications self hosting the BrowserSubprocess is required.

For WinForms your Program.cs would look something like:

[STAThread]
public static int Main(string[] args)
{
	//To support High DPI this must be before CefSharp.BrowserSubprocess.SelfHost.Main so the BrowserSubprocess is DPI Aware
	Cef.EnableHighDPISupport();

	var exitCode = CefSharp.BrowserSubprocess.SelfHost.Main(args);

	if (exitCode >= 0)
	{
		return exitCode;
	}

	var settings = new CefSettings()
	{
		//By default CefSharp will use an in-memory cache, you need to specify a Cache Folder to persist data
		CachePath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData), "CefSharp\\Cache"),
		BrowserSubprocessPath = System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
	};

	//Perform dependency check to make sure all relevant resources are in our output directory.
	Cef.Initialize(settings, performDependencyCheck: false, browserProcessHandler: null);

	var browser = new BrowserForm();
	Application.Run(browser);

	return 0;
}

See https://github.com/cefsharp/CefSharp/blob/cefsharp/87/CefSharp.Core/BrowserSubprocess/SelfHost.cs#L26 for additional details.

Target machines still require VC++ 2019 Runtime. It's likely you can package this as the Universal CRT is already included (so is a custom vcruntime140_cor3.dll for .Net Core 3.1, not clear which version this is though, or if it's usable.)

---

For future reference
dotnet/sdk#14488 (comment)
dotnet/runtime#46990
https://github.com/dotnet/cli/blob/master/Documentation/specs/runtime-configuration-file.md

[amaitland]

For SelfContained builds deleting the CefSharp.BrowserSubprocess.runtimeconfig.json appears to resolve the issue with the BrowserSubprocess not starting.

MyApp.runtimeconfig.json - An optional configuration file containing runtime configuration settings. This file is required for framework-dependent applications, but not for self-contained apps.

As per https://github.com/dotnet/cli/blob/master/Documentation/specs/runtime-configuration-file.md#what-produces-the-files-and-where-are-they

As CefSharp.BrowserSubprocess.runtimeconfig.json is optional when included in self-contained removing it when SelfContained = true would appear to be a reasonable option. Commit a3e8e91 removes the file from ReferenceCopyLocalPaths. The CefSharp.BrowserSubprocess.exe would appear to default to the included runtime. When running as Framework Dependant this shouldn't be a problem as the exe should run on .Net Core 3.1 and .Net 5.0 runtimes.

---

.Net Core 3.1

• Testing with and both self contained and single file apps appear to be working as expected.

---

.Net 5.0

• Normal (non publish) net5.0-windows build with SelfContained = true works as expected
• When publishing as SelfContained the CefSharp.BrowserSubprocess.runtimeconfig.json file still included, removing it manually and updating the apps .deps.json works as expected, so it's just a matter of excluding the file from the publish target.
• Publishing a SingleFile app as both SelfContained = true and SelfContained = false would appear to work as expected if the .Net Core 3.1 runtime is installed. Tested with Windows Sandbox (remember to install VC++ 2019 runtime for the arch you are targeting x86 or x64)

Removing the file from the Publish target should hopefully resolve this.

Important
.Net 5.0 behaves differently to .Net Core 3.1 in terms of Single File apps see

• https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file
• https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file#other-considerations
• https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design.md#optional-settings

1. Native files aren't included by default for Single File, need to set IncludeNativeLibrariesForSelfExtract=true
2. To use the included BrowsersubProcess the exe needs to extract the program to disk which is no longer the default. Need to set IncludeAllContentForSelfExtract=true I've not tested a self hosted BrowserSubprocess with the default in memory behaviour.

Using 88.2.90-RCI3922 build with https://github.com/cefsharp/CefSharp.MinimalExample/tree/cefsharp/88 changing the TargetFramework to net5.0-windows

dotnet publish CefSharp.MinimalExample.netcore.sln -f net5.0-windows -r win-x86 -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -p:IncludeAllContentForSelfExtract=true --self-contained true --verbosity n

---

Disclaimer
There are potential issues with runtime dependency mismatch as detailed in dotnet/sdk#14488 (comment)

• When self hosting the BrowserSubprocess (using your applications exe) this shouldn't be a problem as they're all the same runtime.
• Using the provided CefSharp.BrowserSubprocess.exe may be problematic with SelfContained builds (.Net runtime included with the application).

[amaitland]

• Publishing a SingleFile app as both SelfContained = true and SelfContained = false would appear to work as expected if the .Net Core 3.1 runtime is installed. Tested with Windows Sandbox (remember to install VC++ 2019 runtime for the arch you are targeting x86 or x64)

This should now work with the SelfContained = true and SingleFile = false with .Net 5.0

SelfContained = true and SingleFile = true under .Net 5.0 the apphost has hostfxr.dll and hostpolicy.dll statically linked into the runtime exe. As the included runtime doesn't include the required dlls to run the CefSharp.BrowserSubprocess the files will be removed from the generated executable for this use case. SelfHosting the BrowserSubprocess will be required.

Generating a net5.0-windows self hosting the BrowserSubprocess appears to work as expected under the Windows Sandbox (remembering to install VC++ 2019)

dotnet publish CefSharp.MinimalExample.WinForms.netcore.csproj -f net5.0-windows -r win-x86 -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -p:IncludeAllContentForSelfExtract=true --self-contained true --verbosity n

---

See https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/design.md#host-builds
hostfxr.dll and hostpolicy.dll are statically linked, so they aren't usable for our purposes, in theory you could bundle them yourself yourself.

Add the following to your project file (or set via command line when using dotnet publish) to see details of the files that are packed into the single file exe.

<TraceSingleFileBundler>true</TraceSingleFileBundler>

The .Net 5.0 SingleFile SelfContained exe doesn't appear to contain the Universal CRT, I'm assuming it's statically linked into the resulting exe, I've not seen seen any documentation confirming this though, just an assumption, https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/ suggests it's possible.