search

cefsharp / CefSharp

.NET (WPF and Windows Forms) bindings for the Chromium Embedded Framework
http://cefsharp.github.io/
Other
9.87k stars 2.92k forks source link

Net Core/Net 5 - Implementation #3197

Closed amaitland closed 3 years ago

amaitland commented 4 years ago

Track the progress remaining on actually compiling the project with .Net Core

Basic support for compiling with .Net Core was added with #3181 with additional commit (https://github.com/cefsharp/CefSharp/commit/e8cf336bf3f2871c400cd01ee090fa42df97adf8) to get the core projects compiling/tests passing,

OffScreen

campersau commented 4 years ago 
diff --git a/CefSharp.Native.props b/CefSharp.Native.props
index d34636ef..521c31cf 100644
--- a/CefSharp.Native.props
+++ b/CefSharp.Native.props
@@ -1,12 +1,13 @@
 <?xml version="1.0" encoding="utf-8"?>
 <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
-    <Target Name="AfterBuild">
-        <ItemGroup>
-            <!-- We only need the .exe and .pdb but I don't know how to express that easily with MSBuild... -->
-            <SubProcessFiles Include="$(SolutionDir)\CefSharp.BrowserSubprocess\bin\$(Platform)\$(Configuration)\CefSharp.BrowserSubprocess.*" />
-        </ItemGroup>
-        <Copy SourceFiles="@(SubProcessFiles)" DestinationFolder="$(TargetDir)" />
-    </Target>
+  <Target Name="CefSharpCopyBrowserSubprocess" AfterTargets="AfterBuild">
+    <ItemGroup>
+      <!-- We only need the .exe and .pdb but I don't know how to express that easily with MSBuild... -->
+      <!-- netcore -->
+      <SubProcessFiles Include="$(SolutionDir)\CefSharp.BrowserSubprocess\$(BaseOutputPath)\$(Configuration)\$(TargetFramework)\CefSharp.BrowserSubprocess.*" Condition=" '$(TargetFramework)' != '' " />
+      <!-- netframework -->
+      <SubProcessFiles Include="$(SolutionDir)\CefSharp.BrowserSubprocess\bin\$(Platform)\$(Configuration)\CefSharp.BrowserSubprocess.*" Condition=" '$(TargetFramework)' == '' " />
+    </ItemGroup>
+    <Copy SourceFiles="@(SubProcessFiles)" DestinationFolder="$(TargetDir)" />
+  </Target>

   <Target Name="CefSharpCopyLibs86" BeforeTargets="AfterBuild" Condition="'$(Platform)' == 'x86'">
     <Message Importance="high" Text="Copying cef.redist x86 files" />

See https://github.com/cefsharp/CefSharp/commit/e8cf336bf3f2871c400cd01ee090fa42df97adf8#r40843407

amaitland commented 4 years ago
  • the <Target> definition needs to be changed

Thanks for the tip, was very helpful. I've created a new targets file for the copying as I anticipate additional changes in the future. This should be resolved in commit https://github.com/cefsharp/CefSharp/commit/4505fdfef4b397537d777ccdd5647133382d5f52

amaitland commented 4 years ago
amaitland commented 4 years ago

Quickly revisiting the idea of using a symbol Nuget package, seems like that it's not possible for VC++ projects.

They do not currently support Windows PDBs (generated by VC++, or for managed projects that set build property DebugType to full)

As per https://github.com/dotnet/sourcelink#alternative-pdb-distribution

amaitland commented 4 years ago

I've spent quite a bit of time on this and can generate source for the csproj based projects it doesn't appear to be possible to install GenApi (as detailed in https://github.com/cefsharp/CefSharp/issues/2796#issuecomment-620336779) in a vcxproj file so we'll need to get creative.

It will be simpler to simply use the built in reference assembly generation for the csproj files, the downside being it will generate internal types. I'm thinking of creating a new csproj that reference CefSharp.Core simply for the purpose of manually invoking the GenApi targets.

What I've hacked together so far is at https://github.com/amaitland/CefSharp/tree/genapi (currently using GenApi to generate source for each of the csproj files). Not clear what properties the assemblies should actually have, should they be strongly signed? Need to investigate what .Net generates itself.

amaitland commented 4 years ago

If we create a CefSharp.Core.RefAssembly project, reference CefSharp.Core, install GenApi I'm wondering if we can execute GenApi as a prebuild step referencing CefSharp.Core and have the project in turn compile the generated source to produce a ref assembly. I'll try this next.

amaitland commented 4 years ago

JetBrains have a new tool for generating ref assemblies at https://github.com/JetBrains/Refasmer with an article on their blog at https://blog.jetbrains.com/dotnet/2020/08/05/generate-reference-assemblies-with-refasmer/

There doesn't appear to be a public set of nuget packages yet.

amaitland commented 4 years ago

Article on creating ref assemblies see https://claires.site/2018/07/03/create-and-pack-reference-assemblies/ and https://claires.site/2018/07/09/create-and-pack-reference-assemblies-made-easy/

amaitland commented 4 years ago

With commits https://github.com/cefsharp/CefSharp/commit/76c7918b83c2485f9ab664f343399b71368fa0bf and https://github.com/cefsharp/CefSharp/commit/159a45b79d17585608b427ab480288fdf31675d4 we can now generate a ref assembly for the Net Core version of CefSharp.Core.dll. Still need to make one improvement as x64 is hardcoded in https://github.com/cefsharp/CefSharp/commit/159a45b79d17585608b427ab480288fdf31675d4#diff-49c51a579f9e8487c404651224bf7612R28

amaitland commented 4 years ago

Appveyor can now build our NetCore project, see https://ci.appveyor.com/project/cefsharp/cefsharp/builds/34655450

There's no build scrip yet. Tests aren't running for some reason, need to review output.

amaitland commented 4 years ago

Will try https://github.com/dotnet/runtime/issues/37972#issuecomment-647726082 first

bbday commented 4 years ago

I have issue on new project (Core.net 3.1 WPF) on Application Entry Point (then is not related by code): Could not load file or assembly 'CefSharp.Wpf, Version=84.4.10.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138 It is strange cause there are all files inside folder.

amaitland commented 4 years ago

@bbday See https://github.com/cefsharp/CefSharp.MinimalExample#net-core-support

Further questions please use one of the options listed at https://github.com/cefsharp/CefSharp#contact

amaitland commented 4 years ago

The downside is that the consumer of your package has to specify which RID they want to get assets for at restore time.

As per https://github.com/NuGet/Home/issues/6083#issuecomment-340670584

Which appears to be the missing piece. The other option is to have a single package which isn't great if we add say ARM64 support on Windows.

Using a mix of ref assembly and targets to copy the files is still an option.

Not clear which approach is the best end user experience, they all have some downsides.

amaitland commented 4 years ago

Packages are basically working for x64 builds, problem with the x86 still

amaitland commented 4 years ago

Switching to having x86/x64 specific BrowserSubProcess resolves the x86 issues, it would appear the mismatch of having a x86 main application and a AnyCPU (running on a x64 host, so effectively an x64 process) was causing the problem.

Soon as I do this then the AppVeyor unit tests fail, they pass when I run them locally. Porting just that commit to the cefsharp/86 branch fails as well only on AppVeyor (commit https://github.com/cefsharp/CefSharp/commit/7621e2b4b850a7185ed4402193903dd9bb717f6f)

There's only two tests that fail see https://ci.appveyor.com/project/cefsharp/cefsharp/builds/36167984/job/9t5gk7xma9cg5ddr/tests

Strangely it's the WinForms and WPF test cases, the OffScreen variant of CanLoadGoogle passes correctly.

amaitland commented 4 years ago

Not sure if the test results were accurate, I think it was likely all the actual browser tests were failing. Anyway, should be fixed in commit https://github.com/cefsharp/CefSharp/commit/0a5292fd9554e5b9f765c3dbca03b92a6e659b7b

amaitland commented 4 years ago

The MinimalExample now has a branch that references the new packages. Both x86/x64 builds work as expected now. Only very basic testing has been performed though.

To use the packages you need to set a RuntimeIdentifier. Use one of the following in your project.

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

Without a RuntimeIdentifier the required files won't be copied to the build output. 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>

There are some quirks with using a RuntimeIdentifier, I'll try and document my findings later.

amaitland commented 4 years ago

If no RuntimeIdentifier(RID) specified the following should correctly set the RID based on the current Architecture when a Debug build.

Publishing the app specifying the desired RID

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

Thank you very much for the work on the .NET Core Packages! I'm currently using CefSharp.WinForms.NETCore (Version 87.1.1-CI3800) in a .NET 5.0 application. I think the only remaining issue with the current packages is the CefSharp.BrowserSubprocess.exe, which is compiled for a specific .NET Core configuration (.runtimeconfig), so it doesn't seem to work when publishing a self-contained application (and I think when using a different runtime like .NET 5 and you don't have .NET Core 3.1 installed).

To avoid this I'm self-hosting the browser subprocess, but as no reference assembly of CefSharp.BrowserSubprocess.Core is included, I'm currently adding references like this:

    <Reference Condition="'$(Platform)'=='x64'" Include="CefSharp.BrowserSubprocess.Core">
      <HintPath>$(USERPROFILE)/.nuget/packages/cefsharp.common.netcore/87.1.1-ci3800/runtimes/win-x64/lib/netcoreapp3.1/CefSharp.BrowserSubprocess.Core.dll</HintPath>
    </Reference>
    <Reference Condition="'$(Platform)'=='x86'" Include="CefSharp.BrowserSubprocess.Core">
      <HintPath>$(USERPROFILE)/.nuget/packages/cefsharp.common.netcore/87.1.1-ci3800/runtimes/win-x86/lib/netcoreapp3.1/CefSharp.BrowserSubprocess.Core.dll</HintPath>
    </Reference>

Regarding the need to set an RuntimeIdentifier, is this because there are separate packages chromiumembeddedframework.runtime.win-x86 and .win-x64 in order to reduce download size? Would it theoretically be possible to have a single package containing the binaries for the available architectures in the corresponding runtimes subfolder (so that it would work without specifying a RuntimeIdentifier), or would this cause problems loading the C++/CLI DLLs from the runtimes subfolder?

Thank you!

amaitland commented 3 years ago

. I think the only remaining issue with the current packages is the CefSharp.BrowserSubprocess.exe, which is compiled for a specific .NET Core configuration (.runtimeconfig), so it doesn't seem to work when publishing a self-contained application (and I think when using a different runtime like .NET 5 and you don't have .NET Core 3.1 installed).

Thanks for the heads up, makes sense. I haven't done any testing with .Net 5.0 yet.

Does it work if you manually edit the runtimeconfig.json file and change the tfm to net5.0? Does it work if you delete the tfm all together?

There is still some work to do in relation to self hosting the BrowserSubProcess. There are quite a few options of varying degrees of difficulty.

in order to reduce download size?

At some point I expect we'll add ARM64 as a platform. So we need to keep that in mind.

Would it theoretically be possible to have a single package containing the binaries for the available architectures in the corresponding runtimes subfolder (so that it would work without specifying a RuntimeIdentifier), or would this cause problems loading the C++/CLI DLLs from the runtimes subfolder?

When no RuntimeIdentifier is specified it would appear that I can include the runtime packages in the .targets file and include them succesfully, not sure if this is valid, it does work from my limited testing.

You can directly reference the chromiumembeddedframework.runtime.win-x86/x64 packages to simulate what it would be likely if they are in the same package. From memory you'll still end up with a runtimes sub folder. The .Net framework doesn't make any attempt to resolve the dll at runtime.

I am look at getting rid of the RefAssembly and renaming CefSharp.Core.dll to CefSharp.Core.runtime.dll, adding a managed dll called CefSharp.Core.dll that exposes the public API and includes a CLR Module Initializer that has the relevant dll loader logic.

amaitland commented 3 years ago

Commit https://github.com/cefsharp/CefSharp/commit/aada072f8039acaf4ce66fe9d480a40d6f7a7dc3#diff-b8f242c74549f51929647a3113abfa29a39bd08a5a6a2ce1afc708d688a979b3R28 adds a simple static method to CefSharp.Core.dll that loads CefSharp.BrowserSubprocess.Core.dll with some reflection for self hosting purposes, I'll look at some better options once I've finished a few other things.

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

if (exitCode >= 0)
{
    return exitCode;
}
kpreisser commented 3 years ago

Thank you! I will give the new MainNetCore a try. I'll also try your suggestions about the runtimeconfig.json when I have some time.

About RuntimeIdentifier, you're right that when I don't specify one in the application and then build it, the runtimes folder with win-x64 and win-x86 is created in the bin directory, and native contains files like libcef.dll, and lib\netcoreapp3.1 files like CefSharp.dll, CefSharp.Core.dll. However, when I run the app, the error Could not load file or assembly 'CefSharp.Core' occurs that indicates a missing native dependency. When using process monitor, I can see that it loads CefSharp.Core.dll successfully from the lib\netcoreapp3.1 folder, but then also tries to load libcef.dll from the lib\netcoreapp3.1 folder (where it doesn't exist) instead of the native folder:

grafik

After that, it searches for libcef.dll in the PATH folders like windows\system32 etc. but doesn't look in the native folder (probably due to the mechanism how the C++/CLI DLL is loaded, which would load native dependencies automatically from the same folder).

Maybe it would work when files like libcef.dll are also placed in the lib\netcoreapp3.1 folder instead of the native folder, but I don't know if that is correct from a packaging point of view (and it might cause problems like the need to duplicate those files when adding a new target framework like net5.0 later).

Btw, it seems there is a typo in the .targets file: https://github.com/cefsharp/CefSharp/blob/592c8a384dcf39ff7202f54985a8b92611251388/NuGet/PackageReference/CefSharp.Common.NETCore.targets#L64-L65

The win-x64 should probably mean win-x86.

Thanks!

amaitland commented 3 years ago

I'll also try your suggestions about the runtimeconfig.json when I have some time.

There are some options like rollForward that we might need to tinker with, see https://github.com/dotnet/runtime/blob/master/docs/design/features/framework-version-resolution.md

A quick test and it appears to still run if I remove the tfm.

Maybe it would work when files like libcef.dll are also placed in the lib\netcoreapp3.1 folder instead of the native folder, but I don't know if that is correct from a packaging point of view (and it might cause problems like the need to duplicate those files when adding a new target framework like net5.0 later).

As they are architecture specific I don't believe that's an option.

Btw, it seems there is a typo in the .targets file:

Thanks, I've added a TODO above.

amaitland commented 3 years ago

I'll fix the broken build later today, I'll likely rename MainNetCore to just Main and provide an implementation for both versions.

amaitland commented 3 years ago

Commit https://github.com/cefsharp/CefSharp/commit/01d775a46d2e3fb4644ce43e5c1e122606c780d5 should fix the build error and now renames MainNetCore to Main.

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

if (exitCode >= 0)
{
    return exitCode;
}
kpreisser commented 3 years ago

Ok, thanks! Unfortunately I encountered a new problem with the runtime identifier: In an application where we use CefSharp we need to set the RuntimeIdentifier e.g. to win7-x64 as one of the dependencies doesn't support a portable runtime identifier. However, this causes CefSharp to no longer work because the .targets file only checks for win-x64 and win-x86: https://github.com/cefsharp/CefSharp/blob/f1daac71316724430b0df21431db62ea318361cc/NuGet/PackageReference/CefSharp.Common.NETCore.targets#L4

Is it possible to extend this check, e.g. also for win7-xxx, win8-xxx, win81-xxx, win10-xxx, or maybe something like $(RuntimeIdentifier.Contains('-x64'))?

Thank you!

amaitland commented 3 years ago

Thanks for the feedback, I'm sure we can accommodate that. Maybe a StartsWith win and EndsWith x86/x64 check?

By all means submit a PR if you need this fixed ASAP.

amaitland commented 3 years ago

After that, it searches for libcef.dll in the PATH folders like windows\system32 etc. but doesn't look in the native folder (probably due to the mechanism how the C++/CLI DLL is loaded, which would load native dependencies automatically from the same folder).

As part of #3311 I've refactored CefSharp.Core.dll to be a managed assembly with CefSharp.Core.Runtime.dll being the mixed mode CLI/C++ dll. In .Net Core I've added a CLR Module Initializer to CefSharp.Core.dllwhich can loadlibcef.dll` based on the current architecture.

3311 is fairly close to being complete. I'm hopeful that version 87 will include a .Net Core version.

amaitland commented 3 years ago

3311 has now been merged, so hopefully installing in .Net Core/.Net 5 will run without additional configuration steps. There's still some testing to do.

There are some options like rollForward that we might need to tinker with, see

For the BrowserSubProcess setting RollFoward appears run successfully when .Net 5.0 is installed (without having .Net Core installed) commit https://github.com/cefsharp/CefSharp/commit/32a8cc6b88e94bc194d09ff11b168051b20660e4

andrewmd5 commented 3 years ago

Off-topic but I just wanted to say I've been incredibly impressed with your progress on adding .NET 5 support to CefSharp. We just sponsored the project for the full year given how much we've built around it.

Keep up the great work!

amaitland commented 3 years ago

Off-topic but I just wanted to say I've been incredibly impressed with your progress on adding .NET 5 support to CefSharp. We just sponsored the project for the full year given how much we've built around it.

Again a huge thank you from myself and my family 😄

Just a quick status update, I'm hoping to have the first -pre release out next week.

amaitland commented 3 years ago

Switching to using System.Text.Json for the DevTools client implementation is taking a little longer than I had hoped, the work in process is at https://github.com/amaitland/CefSharp/tree/netcore/devtoolsjson

I'll hopefully finish this tomorrow/friday and release the first -pre release to Nuget.org

amaitland commented 3 years ago

C160 DLL characteristics High Entropy Virtual Addresses Dynamic base NX compatible Control Flow Guard Terminal Server Aware

dumpbin /headers CefSharp.BrowserSubprocess.exe confirms that the exe is TSAware.

amaitland commented 3 years ago

CEF has upgraded to Chromium 87.0.4280.141 (https://bitbucket.org/chromiumembedded/cef/commits/481a82af37bd1b0330abe60040bcf261374023e6)

A new build is available on https://cef-builds.spotifycdn.com/index.html so I'll upgrade before pushing out the first -pre release tomorrow.

amaitland commented 3 years ago

The first -pre set of NETCore/Net 5 packages are now on Nuget.org

The minimum required Nuget Client version is 5.0.0, the packages currently specify a minimum of 4.0.0, which is incorrect, I'll fix that shortly and will be included in the next release.

(Nobody had a better name, so sticking with NETCore for now, will likely move the current packages over to a Net452 naming suffix and change the older packages to be simple meta packages, select the correct implementation based on target framework).

kpreisser commented 3 years ago

Thanks a lot for your work on this! I'm using CefSharp.WinForms.NETCore 87.1.130-pre (with a self-hosted browser subprocess) in a .NET 5.0 application and it works without problems so far (as long as I specify a RuntimeIdentifier).

Without a runtime identifier, the main application itself starts successfully (it correctly loads libcef.dll from the runtimes/win-x64/native folder); however, the selfhost subprocess fails as it tries to load CefSharp.BrowserSubprocess.Core.dll from the runtimes/win-x64/lib/netcoreapp3.1 folder (but the file is placed in the native folder):

System.IO.FileNotFoundException: Could not load file or assembly 'C:\pro\CoDaBix\Sources\CoDaBix.Host.Wpf\Package\CoDaBix.Host.Wpf\Binary\x64\Debug\net5.0\runtimes\win-x64\lib\netcoreapp3.1\CefSharp.BrowserSubprocess.Core.dll'. The system cannot find the file specified.
File name: 'C:\pro\CoDaBix\Sources\CoDaBix.Host.Wpf\Package\CoDaBix.Host.Wpf\Binary\x64\Debug\net5.0\runtimes\win-x64\lib\netcoreapp3.1\CefSharp.BrowserSubprocess.Core.dll'
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at CefSharp.BrowserSubprocess.SelfHost.Main(String[] args)
   at Codabix.Host.Wpf.EntryPoint.Main(String[] args)

However, this isn't a problem for us as we are OK with setting the RuntimeIdentifier. Thanks!

amaitland commented 3 years ago

Without a runtime identifier, the main application itself starts successfully (it correctly loads libcef.dll from the runtimes/win-x64/native folder); however, the selfhost subprocess fails as it tries to load CefSharp.BrowserSubprocess.Core.dll from the runtimes/win-x64/lib/netcoreapp3.1 folder (but the file is placed in the native folder):

Thanks, great feedback. For the Net Core implementation we can add an extra property for the Core.Dll path into https://github.com/cefsharp/CefSharp/blob/master/CefSharp.Core/Initializer.cs#L51

I've added that to the TODO list above.

kpreisser commented 3 years ago

Note that placing PDB files in the native folder seems to cause the .NET SDK to add them to the .deps.json file of the application, which means the application will fail to start when they are missing. Package CefSharp.Common.NETCore 87.1.130-pre now contains the CefSharp.BrowserSubprocess.Core.dll and .pdb files in the runtimes/win-xyz/native folder, whereas in version 87.1.11-ci3823 they were placed in the runtimes/win-xyz/lib/netcoreapp3.1 folder.

For example, the generated .deps.json will look like this:

"CefSharp.Common.NETCore/87.1.130-pre": {
        "dependencies": {
          "chromiumembeddedframework.runtime": "87.1.13"
        },
        "runtime": {
          "runtimes/win-x64/lib/netcoreapp3.1/CefSharp.Core.Runtime.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/lib/netcoreapp3.1/CefSharp.Core.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/lib/netcoreapp3.1/CefSharp.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/lib/netcoreapp3.1/Ijwhost.dll": {
            "fileVersion": "3.100.1020.51903"
          }
        },
        "native": {
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.pdb": {
            "fileVersion": "0.0.0.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.dll": {
            "assemblyVersion": "87.1.130.0",
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.exe": {
            "fileVersion": "87.1.130.0"
          },
          "runtimes/win-x64/native/CefSharp.BrowserSubprocess.runtimeconfig.json": {
            "fileVersion": "0.0.0.0"
          }
        }
      },

Notice the entry with "runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.pdb". This means when you delete all .pdb files after publishing the application (when you don't want to keep them for debugging, as e.g. CefSharp.BrowserSubprocess.Core.pdb is about 6 MB in size), the app will fail to start with an error like this:

Description: A .NET application failed.
Application: app.exe
Path: C:\Program Files\app.exe
Message: Error:
  An assembly specified in the application dependencies manifest (app.deps.json) was not found:
    package: 'CefSharp.Common.NETCore', version: '87.1.130-pre'
    path: 'runtimes/win-x64/native/CefSharp.BrowserSubprocess.Core.pdb'

I think the issue is similar to this one in Microsoft.Data.SqlClient: https://github.com/dotnet/SqlClient/issues/644#issuecomment-658737235

This doesn't seem to happen when the .dll and .pdb files (CefSharp.BrowserSubprocess) are placed in the runtimes/win-xyz/lib/netcoreapp3.1 folder, where then the .pdb files aren't added to the .deps.json file.

Is it possible to not include the CefSharp.BrowserSubprocess.Core.pdb file in the package, or to move these files into the runtimes/win-xyz/lib/netcoreapp3.1 folder? Thanks!

amaitland commented 3 years ago

Firstly pdb support is rather badly broken, it's been 3 1/2 years and nobody has fixed it see https://github.com/dotnet/sdk/issues/1458 for background

The managed dlls have the pdb embedded into the dll. From a support point of view having a pdb included by default is a huge plus. Trying to get people to provide an actual stack trace is hard enough as it is.

Publishing a snupkg to Nuget.org is something I still need to look into.

Package CefSharp.Common.NETCore 87.1.130-pre now contains the CefSharp.BrowserSubprocess.Core.dll and .pdb files in the runtimes/win-xyz/native folder, whereas in version 87.1.11-ci3823 they were placed in the runtimes/win-xyz/lib/netcoreapp3.1 folder.

Is it possible to not include the CefSharp.BrowserSubprocess.Core.pdb file in the package

For this release that might be the simplest option. Moving the files back into the lib folder requires extra entries in the targets to copy the .runtimeconfig.json file and code changes to CefSharp.BrowserSubprocess.exe so it can locate libcef.dll when it's not in the same folder.

kpreisser commented 3 years ago

Understood, thank you!

amaitland commented 3 years ago

Without a runtime identifier, the main application itself starts successfully (it correctly loads libcef.dll from the runtimes/win-x64/native folder); however, the selfhost subprocess fails as it tries to load CefSharp.BrowserSubprocess.Core.dll from the runtimes/win-x64/lib/netcoreapp3.1 folder (but the file is placed in the native folder):

This should hopefully be fixed in https://github.com/cefsharp/CefSharp/commit/b5118b5646fa173afc8ea6ae8eef6eca01e2e5ec

For this release that might be the simplest option. Moving the files back into the lib folder requires extra entries in the targets to copy the .runtimeconfig.json file and code changes to CefSharp.BrowserSubprocess.exe so it can locate libcef.dll when it's not in the same folder.

I've decided to just move the CefSharp.BrowserSubprocess.Core.pdb back into the lib folder. It won't be included as part of the build, it will be available in the package if required for debugging purposes. If I exclude it then there's the hassle of hosting it somewhere.

I'll release another -pre version to Nuget.org in a few days.

amaitland commented 3 years ago

The 87.1.131-pre packages are now on Nuget.org ready for additional testing.

PaulParau commented 3 years ago

Hi @amaitland

Thanks for putting in the effort to migrate CefSharp to .Net Core/.Net 5! I have some questions related to this:

Thanks

amaitland commented 3 years ago

do you have any timeline as to when a stable version will be available?

@PaulParau Likely in the next few days. Subscribe to release only notifications here on GitHub to be notified.

currently I see that you're targeting .Net Core 3.1, do you plan to upgrade to .Net 5 at some point?

See #3284

Also there are problems compiling the VC++ projects with .Net 5.0, so technically I cannot create a successful build.

As .Net 5.0 is backwards compatible with .Net Core 3.1 is there a specific reason you require an upgraded version?

PaulParau commented 3 years ago

@PaulParau Likely in the next few days. Subscribe to release only notifications here on GitHub to be notified.

Awesome, thanks!

As .Net 5.0 is backwards compatible with .Net Core 3.1 is there a specific reason you require an upgraded version?

I wasn't sure whether the .Net Core 3.1 version would be usable within a .Net 5 app, but it seems that they are compatible. So no specific reason to upgrade to 5 at this time.

amaitland commented 3 years ago

Further enhancements will be made as part of #3388