Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/cefsharp/CefSharp/issues/3319 below:

Nuget Package Restructure · Issue #3319 · cefsharp/CefSharp · GitHub

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.

• 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.

• 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

• 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

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.

.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

jwosty, kpreisser, jozefizso and allistairecallistairec

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4