-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
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 toAnyCPU:CefSharp.dllCefSharp.WinForms.dllCefSharp.Wpf.dllCefSharp.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.dllis now written inC#withCefSharp.Core.Runtime.dllbeing the runtime dependency that provides theMixed Mode CLI/C++implementation.- Simplify
AnyCPUtargeting - Resolves issue with
pacakges.configbased 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.dllis loaded. - Potential to add additional runtime checks like validating
VC++is installed. - Upgraded
GitLink
Changes:
-
Rename
CefSharp.Core.dlltoCefSharp.Core.Runtime.dll- No longer directly referenced by client applications
- All the
Public APImethods it exposes are hidden fromVisual Studio Intellisense - Used indirectly through new
CefSharp.Core.dll(AnyCPUclass library).
-
Add
CefSharp.Core.dll- Managed (
AnyCPU) dll that provides the publicAPI - In
.Net Corethere will be aCLR Module Initializerto loadlibcef.dllfrom 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
- Managed (
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