Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Net Core/Net 5 - Implementation #3197

Closed
18 of 20 tasks
amaitland opened this issue Jul 23, 2020 · 47 comments
Closed
18 of 20 tasks

Net Core/Net 5 - Implementation #3197

amaitland opened this issue Jul 23, 2020 · 47 comments
Assignees
Milestone

Comments

@amaitland
Copy link
Member

amaitland commented Jul 23, 2020

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 (e8cf336) to get the core projects compiling/tests passing,


OffScreen

@amaitland amaitland self-assigned this Jul 23, 2020
amaitland referenced this issue Jul 23, 2020
- Make Wpf/WinForms/OffScreen projects target AnyCPU
Only the VC++ projects are platform specific now.
- Remove BrowserSubProcess project reference
Not needed as we now have a standalone exe
- Add OffScreen example
- Add WPF Example project
- Fix some compile errors for main solution
- Add BrowserSubProcess executable
- JavascriptObjectRepository remove isAsync param
Rather than throw exception remove the option
- BrowserSubprocess Exclude the WCF specific code from the netCore project
- Add some ifdef/ifndef to exclude the WCF specific implementation
- Move WCF implementation into separate namespace
@campersau
Copy link
Contributor

campersau commented Jul 23, 2020

  • The CefSharp.BrowserSubprocess isn't copied into the output directory in netcore because the paths are different and the <Target> definition needs to be changed. Here my proposal:
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 e8cf336#r40843407

@campersau campersau mentioned this issue Jul 23, 2020
9 tasks
@amaitland
Copy link
Member Author

  • 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 4505fdf

amaitland added a commit that referenced this issue Jul 24, 2020
- In preparation for adding a Net Core Specific XUnit project file

Issue #3197
amaitland added a commit that referenced this issue Jul 24, 2020
@amaitland
Copy link
Member Author

amaitland commented Jul 26, 2020

@amaitland
Copy link
Member Author

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
Copy link
Member Author

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 #2796 (comment)) 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
Copy link
Member Author

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 added a commit that referenced this issue Aug 7, 2020
- Add ChromiumWebBrowser.Partial.cs and include in all three projects
- Remove InternalsVisibleTo from Cefsharp.dll start moving code into the partial class
  (We don't want to publish our internals as part of our Ref Assembly so this goings together)

#3082
#3197
amaitland added a commit that referenced this issue Aug 7, 2020
- Produce ref assembly for Release builds only

#3197
@amaitland
Copy link
Member Author

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
Copy link
Member Author

@amaitland
Copy link
Member Author

With commits 76c7918 and 159a45b 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 159a45b#diff-49c51a579f9e8487c404651224bf7612R28

amaitland added a commit that referenced this issue Aug 14, 2020
Remove the old win-x64/x86 packages as I'll hopefully get this approach working

**Incomplete**

Issue #2795
Issue #3197
amaitland added a commit that referenced this issue Aug 14, 2020
Build Net Core projects using the VS 2019 build worker image.

No custom build script yet, nuget packages are only created for our Net Full build

Issue #3197
amaitland added a commit that referenced this issue Aug 14, 2020
amaitland added a commit that referenced this issue Aug 14, 2020
amaitland added a commit that referenced this issue Aug 14, 2020
amaitland added a commit that referenced this issue Aug 14, 2020
amaitland added a commit that referenced this issue Aug 14, 2020
amaitland added a commit that referenced this issue Aug 14, 2020
amaitland added a commit that referenced this issue Aug 14, 2020
dotnet restore doesn't like the vcxproj files, trying msbuild restore instead

Issue #3197
amaitland added a commit that referenced this issue Aug 14, 2020
dotnet restore and msbuild doesn't like the vcxproj files
use nuget restore directly for the two vcxprojs

Issue #3197
amaitland added a commit that referenced this issue Aug 14, 2020
before_build is interpreting our commands as one, split them

Issue #3197
@amaitland
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member Author

amaitland commented Jan 9, 2021

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
Copy link
Contributor

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
Copy link
Member Author

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.

amaitland added a commit that referenced this issue Jan 12, 2021
- Add Initializer.BrowserSubProcessCorePath which is calculated the same as BrowserSubProcessPath
- Update SelfHost to use new path then fallback to old path.

Details in #3197 (comment)
amaitland added a commit that referenced this issue Jan 12, 2021
- Add Initializer.BrowserSubProcessCorePath which is calculated the same as BrowserSubProcessPath
- Update SelfHost to use new path then fallback to old path.

Details in #3197 (comment)
@kpreisser
Copy link
Contributor

kpreisser commented Jan 12, 2021

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: dotnet/SqlClient#644 (comment)

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
Copy link
Member Author

Firstly pdb support is rather badly broken, it's been 3 1/2 years and nobody has fixed it see dotnet/sdk#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.

  • When no RuntimIdentifier is specified then the folder structure is fragmented, the CefSharp.BrowserSubprocess ends up in a different folder to libcef.dll
  • The CefSharp.BrowserSubprocess.runtimeconfig.json file isn't copied

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.

amaitland added a commit that referenced this issue Jan 13, 2021
…lder

Leave the pdb in the lib folder for now, won't be copied, it will be in the package if required

#3197 (comment)
@kpreisser
Copy link
Contributor

Understood, thank you!

amaitland added a commit that referenced this issue Jan 13, 2021
…lder

Leave the pdb in the lib folder for now, won't be copied, it will be in the package if required

#3197 (comment)
@amaitland
Copy link
Member Author

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 b5118b5

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
Copy link
Member Author

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

@PaulParau
Copy link

Hi @amaitland

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

  • do you have any timeline as to when a stable version will be available?
  • currently I see that you're targeting .Net Core 3.1, do you plan to upgrade to .Net 5 at some point?

Thanks

@amaitland
Copy link
Member Author

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
Copy link

@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 amaitland modified the milestones: 87.1.x, 88.1.x Jan 29, 2021
@amaitland amaitland modified the milestones: 88.1.x, 87.1.x Feb 3, 2021
@amaitland
Copy link
Member Author

Further enhancements will be made as part of #3388

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants