A big draw of .NET 5 is the single file executable. I am investigating if using Costura + CefSharp is possible, but it's certainly not simple.

Unless I'm an idiot and missed something. I've been working with .net5 for a couple of months now, and the single file executable is only used if you configure your project that way. it isn't even the default

Firstly supporting .Net 5.0 doesn't necessarily mean compiling a .Net 5.0 specific version. As it is my understanding .Net 5.0 is the version after .Net Core 3.1 and is backwards compatible. #3197 (comment) suggests testing with .Net 5.0 to this point has been fairly successful, just a few quirks with the packaging.

Agreed, packages built for .NET Core 3.1 should mostly work in .NET 5.0 applications as technically .NET 5.0 is the next version after .NET Core 3.1 (just the naming was changed), so the CefSharp.NETCore packages (once they are finished) should work with .NET 5.0 apps.

(Regarding the single-file executable feature, I think the mechanism has changed in .NET 5.0 compared to .NET Core 3.x, but I haven't look at this in more details to see whether this will still work with the current CefSharp.NETCore packages when you want to create a single-file application.)

An advantage of compiling specifically for .NET 5.0 would be the Windows ARM64 support (once support for the desktop components is provided in a servicing release) (#2944). Unfortunatly, when I tried to switch the TargetFramework of the CefSharp.xxx.netcore projects from netcoreapp3.1 to net5.0, the C++/CLI projects (CefSharp.Core) fail to compile with errors like this (not sure what they mean exactly):

2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>LINK : fatal error LNK1255: link failed because of metadata errors

However, when I tried to create an empty C++/CLI project for .NET Core 3.1 and added a ARM64 platform configuration, it seemed to work, producing both the <Project>.dll and the Ijwhost.dll files that are marked as ARM64 files in the PE header. So maybe Windows ARM64 support can still be added even when compiling for netcoreapp3.1 (but will only be usable in .NET 5.0 and higher applications).

The first set of -pre release packages is now on Nuget.org

• https://www.nuget.org/packages/CefSharp.WinForms.NETCore/87.1.130-pre
• https://www.nuget.org/packages/CefSharp.Wpf.NETCore/87.1.130-pre
• https://www.nuget.org/packages/CefSharp.OffScreen.NETCore/87.1.130-pre

The https://github.com/cefsharp/CefSharp.MinimalExample/tree/cefsharp/87 branch of the MinimalExample can be used for testing purposes.

They should work for both .Net Core and .Net 5.0. In a version of two I'll change the main CefSharp.WinForms/Wpf/OffScreen packages to be just meta packages and create a set of Net452 packages, so Nuget will choose the correct package based on framework.

I strongly suggest setting a RuntimeIdentifier. I've done my best to make it work when no RuntimeIdentifier is specified, there are probably use cases when you will need to specify one for it to work.

Specify a RuntimeIdentifier. Use one of the following in your proj file.

<RuntimeIdentifier>win-x86</RuntimeIdentifier>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>

Without a RuntimeIdentifier the required files will hopefully be copied to the output folder, as I said there are likely cases where it won't work.
For Debug builds I've been setting SelfContained to false (whole .Net Core framework is copied otherwise).

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <!--
    When SelfCOntained the whole Runtime is copied, for dev purposes
    We don't need this in our debug builds
    -->
    <SelfContained>false</SelfContained>
</PropertyGroup>

If your proj file specifies multiple platforms e.g. <Platforms>x86;x64</Platforms> then I'd suggest using the following:

<PropertyGroup Condition="'$(PlatformTarget)' == 'x86'">
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

<PropertyGroup Condition="'$(PlatformTarget)' == 'x64'">
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>

<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
  <!--
  When SelfCOntained the whole Runtime is copied, for dev purposes
  We don't need this in our debug builds
  -->
  <SelfContained>false</SelfContained>
</PropertyGroup>

For those migrating from the older packages please remove the entries you added to your proj files.

If you were using WPF it would look like the following:

<!-- Add the following to your csproj/vbproj file -->
<ItemGroup>
  <Reference Update="CefSharp">
	  <Private>true</Private>
  </Reference>
  <Reference Update="CefSharp.Core">
	  <Private>true</Private>
  </Reference>
  <Reference Update="CefSharp.Wpf">
	  <Private>true</Private>
  </Reference>
</ItemGroup>

Make sure this is removed after migrating to the NETCore packages.

• Microsoft Visual C++ 2019 Redistributable or greater is required. VC++ 2022 is backwards compatible.
• NOTE A minimum of .Net Core 3.1 is required.
• Ijwhost.dll must be included
  To support C++/CLI libraries in .NET Core, ijwhost.dll was created by Microsoft as a shim for finding and loading the runtime. All C++/CLI libraries are linked to this shim, such that ijwhost.dll is found/loaded when the C++/CLI library is loaded.
• The MinimalExample is available for testing purposes and services as a reference. Use CefSharp.MinimalExample.netcore.sln which multi targets .Net Core 3.1/.Net 5.0 and 6.0.

It is recommended that you set a RuntimeIdentifier during development. I've done my best to make it work when no RuntimeIdentifier is specified, there are use cases when you will need to specify one for it to work.

Specify a RuntimeIdentifier. Use one of the following in your proj file.

<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">win-x86</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">win-x64</RuntimeIdentifier>

<!--
You should also set
SelfContained = false (otherwise the whole .Net Framework will be included in your bin folder
-->
<SelfContained Condition="'$(SelfContained)' == ''">false</SelfContained>

Without a RuntimeIdentifier the required files will hopefully be copied to the output folder, as I said there are likely cases where it won't work.

If your proj file specifies multiple platforms e.g. <Platforms>x86;x64</Platforms> then I'd suggest using the following:

<PropertyGroup Condition="'$(PlatformTarget)' == 'x86'">
  <RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">win-x86</RuntimeIdentifier>
  <SelfContained Condition="'$(SelfContained)' == ''">false</SelfContained>
</PropertyGroup>

<PropertyGroup Condition="'$(PlatformTarget)' == 'x64'">
  <RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">win-x64</RuntimeIdentifier>
  <SelfContained Condition="'$(SelfContained)' == ''">false</SelfContained>
</PropertyGroup>

SelfPublish and SelfContained

You will need to self host the BrowserSubProcess using your main application executable.
See #3407 for details

Known Issues

• C++/CLI libraries may fail to load due to ijwhost.dll not being on the search path see C++/CLI libraries may fail to load due to ijwhost.dll not being on the search path dotnet/runtime#38231
• .Net Core 3.1/.Net 5.0+ always produce a 32bit executable for AnyCPU, this is a known limitation of the latest .Net Framework and not CefSharp specific.

For those migrating from the older packages to the new NETCore packages then please remove the entries you added to your proj files.

If you were using WPF it would look like the following:

<!-- Add the following to your csproj/vbproj file -->
<ItemGroup>
  <Reference Update="CefSharp">
	  <Private>true</Private>
  </Reference>
  <Reference Update="CefSharp.Core">
	  <Private>true</Private>
  </Reference>
  <Reference Update="CefSharp.Wpf">
	  <Private>true</Private>
  </Reference>
</ItemGroup>

Make sure this is removed after migrating to the NETCore packages.

For those attempting to load CefSharp.Core.Runtime.dll which results in a BadImageFormatException, it's important to be aware that the .Net Core 3.1/.Net 5.0 runtimes will throw this exception for any form of failure. The exception is often misleading.

Our diagnostics for mixed-mode assembly loading need a bit of work since they throw a BadImageFormatException for basically every failure.

As per dotnet/runtime#31743 (comment) the BadImageFormatException is thrown for any sort of failure, some of the common causes are:

• Missing VC++ 2019 Runtime
• Missing ijwhost.dll
• Missing native libraries e.g. libcef.dll (See Output files description table for list of CEF/CefSharp resources)
• Trying to load a 64-bit DLL inside a 32-bit process, or vice-versa

Unfortunatly, when I tried to switch the TargetFramework of the CefSharp.xxx.netcore projects from netcoreapp3.1 to net5.0, the C++/CLI projects (CefSharp.Core) fail to compile with errors like this (not sure what they mean exactly):

2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>MSVCMRTD_netcore.LIB(mstartup.obj) : error LNK2022: metadata operation failed (80131195) :
2>LINK : fatal error LNK1255: link failed because of metadata errors

I met the same link error when compiling my C++/CLI project targeting .NET 5.0. Did you eventually resolve the issue? If so how?

Hi, sorry for not replying earlier.

I met the same link error when compiling my C++/CLI project targeting .NET 5.0. Did you eventually resolve the issue? If so how?

I did not resolve the issue, but it seems that the error might have been resolved at least in the current Visual Studio 2022 version (17.3.3). When I change the TargetFramework of CefSharp.Core.Runtime.netcore (C++/CLI project) to net5.0 and switch the architecture configuration to arm64, the project now builds successfully, whereas for netcoreapp3.1 (that is currently used and buils successfully with VS 2019), I now get an error like this:

2>   Creating library bin.netcore\arm64\Debug\CefSharp.Core.Runtime.lib and object bin.netcore\arm64\Debug\CefSharp.Core.Runtime.exp
2>LINK : error LNK2001: unresolved external symbol _CorDllMain
2>C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.28\runtimes\win-x64\native\IJWHOST.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'ARM64'
2>bin.netcore\arm64\Debug\CefSharp.Core.Runtime.dll : fatal error LNK1120: 1 unresolved externals
2>Done building project "CefSharp.Core.Runtime.netcore.vcxproj" -- FAILED.

So it seems that once we want to switch AppVeyor to use the Visual Studio 2022 image (e.g. for #4155), it would be required to conditionally set the TargetFramework of the C++/CLI projects for .NET Core (CefSharp.Runtime.Core.netcore, CefSharp.BrowserSubprocess.Core.netcore) to net5.0 when the PlatformTarget is arm64, and set it to netcoreapp3.1 for the other architecturs.