Adjust references in .props files for .NET Core projects

[kpreisser]

Issue #2796

Summary:

• Adjusted the <Reference> elements in the NuGet .props file for better .NET Core support

Changes:

• For .NET Core projects, a reference to CefSharp.BrowserSubprocess.Core is added, so that the app executable can run the subprocess logic (after BrowserSubprocess - Refactor to support .Net Core #2891 is done).
• <Private>False</Private> is no longer specified for the CefSharp assemblies in .NET Core projects, as otherwise these references would not be added to the generated .deps.json file and the CoreCLR wouldn't load them.
  (Note that this probably means we cannot support AnyCPU for .NET Core, but I think we can ignore that for now because e.g. when you publish a self-contained .NET Core application, it will already be platform-specific.)

Note: The CefSharp.BrowserSubprocess.exe file (using .NET Framework 4.5.2) is still copied to the output directory for .NET Core projects.

How Has This Been Tested?

Tested by running build.ps1, and then using the built .nupkg packages (via local NuGet package source) in the CefSharp.MinimalExample.NetCore.* projects (see cefsharp/CefSharp.MinimalExample#57), and removing the <Reference Update="CefSharp"> elements to verify the assemblies are correctly loaded by the runtime.
Additionally, I tested the new packages with the existing CefSharp.MinimalExample.* projects to verify classic .NET Framework projects using packages.config still work as expected.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Updated documentation

Checklist:

• Tested the code(if applicable)
• Commented my code
• Changed the documentation(if applicable)
• New files have a license disclaimer
• The formatting is consistent with the project (project supports .editorconfig)

[AppVeyorBot]

✅ Build CefSharp 76.1.90-CI3277 completed (commit bf5d00ebdf by @kpreisser)

[amaitland]

• <Private>True</Private> is no longer specified for the CefSharp assemblies in .NET Core projects, as otherwise these references would not be added to the generated .deps.json file and the CoreCLR wouldn't load them.

This part baffles me, will need to do some more digging before I'm prepared to accept this change. Currently I don't have space to install VS2019, so it might be a while before that happens.

Happy to merge the additional BrowserSubProcess entries separately.

[kpreisser]

• <Private>True</Private> is no longer specified for the CefSharp assemblies in .NET Core projects, as otherwise these references would not be added to the generated .deps.json file and the CoreCLR wouldn't load them.

Sorry, this should actually read "<Private>False</Private> is no longer specified"; I fixed my initial post.

This part baffles me, will need to do some more digging before I'm prepared to accept this change. Currently I don't have space to install VS2019, so it might be a while before that happens.

Note that it's also possible to just install the .NET Core 3.0 SDK and then run e.g. dotnet build <project> -p:Platform=x64 to build the project, without installing the full VS 2019. For C# debugging in .NET Core projects, Visual Studio Code with the MS C# extension could be used.

I don't know the technical details, but when you build a .NET Core project, a <project>.deps.json file is generated that contains entries for the references of the project. For example, with CefSharp.MinimalExample.WinForms.netcore it looks like this:

{
  "runtimeTarget": {
    "name": ".NETCoreApp,Version=v3.0",
    "signature": ""
  },
  "compilationOptions": {},
  "targets": {
    ".NETCoreApp,Version=v3.0": {
      "CefSharp.MinimalExample.WinForms.netcore/1.0.0": {
        "dependencies": {
          "CefSharp.WinForms": "75.1.142",
          "CefSharp.Core": "75.1.142.0",
          "CefSharp": "75.1.142.0",
          "CefSharp.WinForms.Reference": "75.1.142.0"
        },
        "runtime": {
          "CefSharp.MinimalExample.WinForms.netcore.dll": {}
        }
      },
     ...
      "CefSharp.WinForms.Reference/75.1.142.0": {
        "runtime": {
          "CefSharp.WinForms.dll": {
            "assemblyVersion": "75.1.142.0",
            "fileVersion": "75.1.142.0"
          }
        }
      }
    }
  },
  ...
}

Now, when an assembly reference like CefSharp.WinForms.dll is set to <Private>false</Private> (Copy Local = False), it seems this reference is no longer included in the .deps.json file (probably because it also wouldn't be copied and therefore it is expected that it is loaded using another mechanism).

Then, when running the application, it cannot load CefSharp.WinForms.dll even though the file exists in the folder near the EXE (as it was copied by the .targets file when Platform is x64 or x86):

System.IO.FileNotFoundException: 'Could not load file or assembly 'CefSharp.WinForms, Version=75.1.142.0, Culture=neutral, PublicKeyToken=40c4b6fc221f4138'. The system cannot find the file specified.'

Setting <Private>true</Private> fixes the issue as it adds the entry to the .deps.json file (which seems the correct way), but I don't know if there's another way to fix it.

Thank you!

[amaitland]

Note that it's also possible to just install the .NET Core 3.0 SDK and then run e.g. dotnet build <project> -p:Platform=x64 to build the project, without installing the full VS 2019. For C# debugging in .NET Core projects, Visual Studio Code with the MS C# extension could be used.

Free space permitting I'll install .Net Core 3.0 when the official release comes out. Hadn't considered using VS Code, thanks for the suggestion 👍

[kpreisser]

This part baffles me, will need to do some more digging before I'm prepared to accept this change.

Hi @amaitland, did you already have a chance to look into this?

Thanks!

[amaitland]

I did, there are a couple off issues that relates to the problem on GitHub, I'll see if I can find the links again.

I'm thinking instead of adding additional hacks to make .Net Core work we look at creating a more modern set of packages that specifically support PackageReference, issue #2795 will be used to track those changes.

I'm reluctant to merge this based on that, I'd rather not encourage people to use the current packages.

[kpreisser]

Thank you!
Yes, I agree creating separate packages is probably the better option.

[aesteves900]

Hello Guys, there was a big migration to .NET Core...I have an issue to run the BrowserSubProcess wrote In C# in CefSharp solution, I got badFormatedImageException all the time. I have some difficult to understand why CefSharp.Common.NETCore does not contain CefSharp.BrowserSubprocess.Core.netcore .dll.

I'm using the latest version from myget.org.

Can you help me?

Thank you!

[amaitland]

The project can be compiled with .Net Core, that part is correct. Issue #3197 is still open and you can subscribe to it for progress updates. The NetCore set of packages on myget aren't usable yet, the Badimageformatexception is actually misleading.

You can use the current Nuget packages in .Net Core details at https://github.com/cefsharp/CefSharp.MinimalExample#net-core-support

Further questions please ask on https://gitter.im/cefsharp/CefSharp