You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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).
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.
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).
<PropertyGroupCondition="'$(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:
<PropertyGroupCondition="'$(PlatformTarget)' == 'x86'">
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>
<PropertyGroupCondition="'$(PlatformTarget)' == 'x64'">
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
<PropertyGroupCondition="'$(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>
<ReferenceUpdate="CefSharp">
<Private>true</Private>
</Reference>
<ReferenceUpdate="CefSharp.Core">
<Private>true</Private>
</Reference>
<ReferenceUpdate="CefSharp.Wpf">
<Private>true</Private>
</Reference>
</ItemGroup>
Make sure this is removed after migrating to the NETCore packages.
Reacted by BinaryCraX, Roland Leitenberger and Konstantin Preißer
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.
<RuntimeIdentifierCondition="'$(RuntimeIdentifier)' == ''">win-x86</RuntimeIdentifier>
<RuntimeIdentifierCondition="'$(RuntimeIdentifier)' == ''">win-x64</RuntimeIdentifier>
<!--You should also setSelfContained = false (otherwise the whole .Net Framework will be included in your bin folder-->
<SelfContainedCondition="'$(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:
.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>
<ReferenceUpdate="CefSharp">
<Private>true</Private>
</Reference>
<ReferenceUpdate="CefSharp.Core">
<Private>true</Private>
</Reference>
<ReferenceUpdate="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:
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):
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.
Activity
chris-kruining commentedon Nov 19, 2020
Haltroy commentedon Nov 26, 2020
julesx commentedon Nov 26, 2020
amaitland commentedon Nov 27, 2020
amaitland commentedon Nov 27, 2020
chris-kruining commentedon Nov 27, 2020
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
kpreisser commentedon Nov 27, 2020
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.NETCorepackages (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
TargetFrameworkof theCefSharp.xxx.netcoreprojects fromnetcoreapp3.1tonet5.0, the C++/CLI projects (CefSharp.Core) fail to compile with errors like this (not sure what they mean exactly):However, when I tried to create an empty C++/CLI project for .NET Core 3.1 and added a
ARM64platform configuration, it seemed to work, producing both the<Project>.dlland theIjwhost.dllfiles that are marked as ARM64 files in the PE header. So maybe Windows ARM64 support can still be added even when compiling fornetcoreapp3.1(but will only be usable in .NET 5.0 and higher applications).amaitland commentedon Nov 29, 2020
Haltroy commentedon Nov 29, 2020
amaitland commentedon Nov 29, 2020
Haltroy commentedon Nov 30, 2020
amaitland commentedon Jan 9, 2021
The first set of
-prerelease packages is now onNuget.orgThe https://github.com/cefsharp/CefSharp.MinimalExample/tree/cefsharp/87 branch of the
MinimalExamplecan be used for testing purposes.They should work for both
.Net Coreand.Net 5.0. In a version of two I'll change the mainCefSharp.WinForms/Wpf/OffScreenpackages to be just meta packages and create a set ofNet452packages, soNugetwill choose the correct package based on framework.I strongly suggest setting a RuntimeIdentifier. I've done my best to make it work when no
RuntimeIdentifieris 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.
Without a
RuntimeIdentifierthe required files will hopefully be copied to the output folder, as I said there are likely cases where it won't work.For
Debugbuilds I've been settingSelfContainedtofalse(whole .Net Core framework is copied otherwise).If your proj file specifies multiple platforms e.g.
<Platforms>x86;x64</Platforms>then I'd suggest using the following:For those migrating from the older packages please remove the entries you added to your
projfiles.If you were using
WPFit would look like the following:Make sure this is removed after migrating to the
NETCorepackages.amaitland commentedon Feb 3, 2021
VC++ 2022is backwards compatible..Net Core 3.1is required.To support C++/CLI libraries in .NET Core, ijwhost.dll was created by
Microsoftas 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.CefSharp.MinimalExample.netcore.slnwhich 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.
Without a
RuntimeIdentifierthe 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:SelfPublish and SelfContained
You will need to self host the
BrowserSubProcessusing your main application executable.See #3407 for details
Known Issues
ijwhost.dllnot being on the search path see C++/CLI libraries may fail to load due toijwhost.dllnot being on the search path dotnet/runtime#38231.Net Core 3.1/.Net 5.0+always produce a32bitexecutable forAnyCPU, this is a known limitation of the latest.Net Frameworkand notCefSharpspecific.For those migrating from the older packages to the new NETCore packages then please remove the entries you added to your
projfiles.If you were using
WPFit would look like the following:Make sure this is removed after migrating to the
NETCorepackages.pmuessig commentedon Feb 25, 2021
amaitland commentedon Feb 25, 2021
pmuessig commentedon Feb 25, 2021
amaitland commentedon Mar 23, 2021
For those attempting to load
CefSharp.Core.Runtime.dllwhich results in aBadImageFormatException, it's important to be aware that the.Net Core 3.1/.Net 5.0runtimes will throw this exception for any form of failure. The exception is often misleading.As per dotnet/runtime#31743 (comment) the
BadImageFormatExceptionis thrown for any sort of failure, some of the common causes are:VC++ 2019 Runtimeijwhost.dlllibcef.dll(See Output files description table for list ofCEF/CefSharpresources)pongba commentedon Feb 5, 2022
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?
kpreisser commentedon Sep 7, 2022
Hi, sorry for not replying earlier.
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) tonet5.0and switch the architecture configuration toarm64, the project now builds successfully, whereas fornetcoreapp3.1(that is currently used and buils successfully with VS 2019), I now get an error like this:So it seems that once we want to switch AppVeyor to use the
Visual Studio 2022image (e.g. for #4155), it would be required to conditionally set theTargetFrameworkof the C++/CLI projects for .NET Core (CefSharp.Runtime.Core.netcore,CefSharp.BrowserSubprocess.Core.netcore) tonet5.0when thePlatformTargetisarm64, and set it tonetcoreapp3.1for the other architecturs.