Nuget Package Restructure

[amaitland]

Summary

To resolve a few long standing issues and to better support .Net Core going forward I'm restructuring the Nuget Packages, this includes the inclusion of CefSharp.Core.Runtime.dll, this is actually the current CefSharp.Core.dll with a new managed dll called CefSharp.Core.dll which allows me to switch (at least mostly) to having CefSharp.Core.runtime.dll as a runtime only dependency.

UPDATE
Whilst it is no longer necessary to close Visual Studio for the references to show up (dotnet/project-system#4158) the runtime dependencies, libcef.dll etc still aren't copied until the project is closed/reopened when using packages.config style projects. Using PackageReference works correctly and is the recommended option. Please note you can use PackageReference with older non SDK Style projects (ones that would typically have used packages.config) under VS2017/2019.

CefSharp.Core.Runtime.dll will need to be distributed with your application.

Breaking Changes

• The following arch specific (x86/x64) dlls have been converted to AnyCPU:
  • CefSharp.dll
  • CefSharp.WinForms.dll
  • CefSharp.Wpf.dll
  • CefSharp.OffScreen.dll

Specifying $(CefSharpTargetDir) in MSBuild will no longer move these files to a sub folder as they are now included in the lib\net452 folder within the Nuget package (this is the standard). Moving libcef.dll and it's many other resources is still possible.

Details

• Better support .Net Core/5.0
• CefSharp.Core.dll is now written in C# with CefSharp.Core.Runtime.dll being the runtime dependency that provides the Mixed Mode CLI/C++ implementation.
• Simplify AnyCPU targeting
• Resolves issue with pacakges.config based projects having to reload the solution for the dependencies to show up (Building project with CefSharp fails to build until I restart visual studio dotnet/project-system#4158)
• Remove requirement for package consumers having to change $(Platform) at the solution level ($PlatformTarget) at project level is now sufficient
• Greater control over how libcef.dll is loaded.
• Potential to add additional runtime checks like validating VC++ is installed.
• Upgraded GitLink

Changes:

• Rename CefSharp.Core.dll to CefSharp.Core.Runtime.dll

  • No longer directly referenced by client applications
  • All the Public API methods it exposes are hidden from Visual Studio Intellisense
  • Used indirectly through new CefSharp.Core.dll (AnyCPU class library).

• Add CefSharp.Core.dll

  • Managed (AnyCPU) dll that provides the public API
  • In .Net Core there will be a CLR Module Initializer to load libcef.dll from the relevant location where required
  • Additional runtime checks can be added to validate if say VC++ is installed
  • Generally give more control over loading of the unmanaged resources and setting the relevant paths e.g. BrowserSubProcessPath

Known Issues:

Specifying <CefSharpTargetDir/> in MSBuild doesn't currently copy CefSharp.dll to the subfolder which is required by the BrowserSubProcess.

Temp workaround is to copy $(CefSharpCommonManagedDlls) to the subfolder via a custom AfterBuild Target.

Additional

.csproj.nuget.g.props files in the obj directory have a $(NuGetProjectStyle) which might be better than the current '$(UsingMicrosoftNETSdk)' != 'true' check to determine if a SDK Style(PackageReference) project.

<NuGetProjectStyle Condition=" '$(NuGetProjectStyle)' == '' ">PackageReference</NuGetProjectStyle>

PR #3311

[amaitland]

The Ref Assemblies don't appear to be build correctly on AppVeyor.

https://ci.appveyor.com/project/cefsharp/cefsharp/builds/36859715/job/lmn6djbvfijk3fui#L591

Reverted to using the full AnyCPU assemblies until it's resolved (if it can be resolved) Commit 8351fac

It's likely the older version of MSBuild doesn't pickup the ProduceReferenceAssembly property. Works as expected when building with VS2019 locally.

[amaitland]

Whilst it is no longer necessary to close Visual Studio for the references to show up (dotnet/project-system#4158) the runtime dependencies, libcef.dll etc still aren't copied until the project is closed/reopened when using packages.config style projects. Using PackageReference this isn't a problem and is the recommended project structure.

It might be possible to hack something together where a Target copies the files when using packages.config and they don't appear in the output folder.

[amaitland]

To better support ClickOnce/Publish I've added the option to switch from using the <None/> entries to <Content/> this should allow support via a single configuration setting in the proj file.

Add the following to a PropertyGroup in your proj file before the .targets entries (which are at the bottom).

<CefSharpBuildAction>Content</CefSharpBuildAction>

IMPORTANT :

• Currently only works when PlatformTarget is x86/x64
• Upgrading users make sure to remove any custom .targets files or ItemGroups you'd previously used to copy the CefSharp dependencies from your proj file.

[amaitland]

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

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

The rest of the changes related to updating the documentation will be tracked as part of #3343

[Yahasana]

@amaitland i don't know whether should i file a new bug. when i create new project with CefSharp name and just inject ChromiumWebBrowser for simplest test.

<PackageReference Include="CefSharp.WinForms.NETCore" Version="98.1.210" />

build it and run, then crash with nothing tips. when i change the project name to other one, it works like a charm.

i think the reason should be that the output dll CefSharp.dll conflict with the one in runtimes\win-x64\native\CefSharp.dll.

[amaitland]

when i create new project with CefSharp

Please don't open a bug. You will need to give your project a unique name. This is not something I can fix.

[Xan-Kun]

Hello and thanks for the awesome library!
Sorry in advance if this isn't the right place to ask, I will delete/edit/move it gladly to a better place.

Does the above explained also include the file libGLESv2.dll or is that different somehow? Either way, it doesn't get put in a subfolder and just seems to 'resist' 😄
I have great problems with that file (Memory Access Violations) when it is in the build-root, together with the main app.

Thx again.