CefSharp v132.3.11 native binaries for chromiumembeddedframework.runtime.win-x** get copied over to bin folder #5056
Replies: 1 comment 5 replies
-
|
The above solution had worked except that it added a reference to the chromiumembeddedframework.runtime.win-x86 binary for all the projects in the solution which makes sense as we have used an Include attribute. So we decided to make the necessary changes to ensure that the CefSharp dependency chromiumembeddedframework.runtime.win-x86 will not be copying over the native files (CefSharp.dll, chrome_100_percent.pak, chrome_200_percent.pak, chrome_elf.dll, d3dcompiler_47.dll, icudtl.dat, libcef.dll, libEGL.dll, libGLESv2.dll, resources.pak, snapshot_blob.bin, v8_context_snapshot.bin, vk_swiftshader_icd.json, vk_swiftshader.dll, vulkan-1.dll) in the bin folder for the project and also it should not add the dependency reference to all the projects where they are not needed. We tried:
But this did not work. We were not considering this as the best option as, had it worked, we would have had to modify the csproj files for all the projects that reference CefSharp. But since it did not work, we are not sure on what way to proceed. Can anyone guide us with a possible solution? |
Beta Was this translation helpful? Give feedback.
-
I don't know what your structure looks like, so basically impossible to say. Make sure you've read https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets
|
Beta Was this translation helpful? Give feedback.
-
|
I will try to explain the solution structure as much as possible. There is lets say a single solution file which loads 20 different projects out of which maybe 3/4 reference the CefSharp package. These projects in turn gets referenced in some of the other projects that are loaded in the solution. The package management is implemented using a centralized package.props file in the root. The CefSharp package versions has always been added to the package.props file. This worked without any issues till version 116.0.230. When we updated to version 121.3.70 the build folder size started to increase as the native assets started getting copied over to the bin folder. This was because of the change to the CefSharp dependency NuGet packages for the used version. (Issues · cefsharp/CefSharp.) From version 121, the native assets of the runtime packages were being copied by msbuild to the primary output folders (along with the Chromium sub-folder - this might have been a part of the build script for our solution) as well (while this was not the case for earlier versions of runtimes\win-x86\native folders prior to 121 for .Net Framework NuGet packages). We fixed it by adding
to the package.props file which prevented the native files from getting copied over to the bin folder (it was still getting copied to the Chromium subfolder which was desired) but added chromiumembeddedframework.runtime.win-x86 and chromiumembeddedframework.runtime.win-x64 as dependencies to all projects in the solution. So during the next upgrade (upgrade to Version v132.3.11), we decided to update the Chrome dependency in package.props from
to
hoping that the Update tag will only impact the projects that reference the Chrome dependency (because they include the CefSharp binaries) so that we will be able to address both the requirements of ensuring that the build size will not get increased (due to the fact that the native assets will not get copied to the bin folder) and that the Chromium runtime dependencies will only get referenced by the projects that actually need them. But we ended up having the old issue back i.e. the build size started to increase again as the native files started to get copied in both the bin and the Chromium folders. This is something that we are currently struggling with and multiple attempts at using different combinations of the Exclude tag and Include/Update tag in PackageReference has not yielded a solution yet. This is the primary issue that we are trying to solve. In a nutshell, we have the following 2 objectives:
Hopefully I was able to explain the issue at hand. If not, I can elaborate further as well. |
Beta Was this translation helpful? Give feedback.
-
|
We were able to solve the issue with <PackageReference Include="chromiumembeddedframework.runtime.win-x86" Version="132.3.1" Condition="'$(CefSharpReferenced)' == 'true'"> <ExcludeAssets>native</ExcludeAssets> </PackageReference>after defining the CefSharpReferenced flag across all projects that reference CefSharp before we triggered the build. |
Beta Was this translation helpful? Give feedback.
-
|
As mentioned in my previous reply, we have solved the issue for the CefSharp runtime dependency (ChromiumEmbeddedFramework.Runtime.win-*) native folder content from copying over to the primary output folder (bin) for all projects in a solution by adding the following lines in package.props file:
and adding the CefSharpEnabled property to the project files (csproj) of projects that directly add CefSharp as a package, like so:
While the primary issue is resolved, we are seeing 2 issues that does not seem logically correct which are described below: Issue 1: In the project that directly adds CefSharp as a package reference, we can see 2 instances of the CefSharp Dependency (ChromiumEmbeddedFramework.Runtime.win-*) getting listed under the Dependencies --> Packages in Visual Studio, one under the CefSharp entry (when expanded) and one directly under the Packages node. I think this is because CefSharp automatically adds the dependency when referenced and the pair under the Packages node is because of the line in Package.Props to include the Dependency conditionally ( and this project has been marked as CefSharp enabled. Can you please validate this understanding and do you think this can have any negative impact in terms of size or otherwise? See screenshot for reference.
Issue 2: Projects that include the above project directly or anywhere we have a direct CefSharp referenced project in the chain of references (Project B references Project A which references Project CefSharp), we can see the CefSharp dependencies added as a reference in Visual Studio. Essentially we are looking at an example of transitive dependency propagation. We have tried with different flags like All with both the CefSharp entries and ChromiumEmbeddedFramework.Runtime.win-* entires in package.props but this seems to have no impact. Can someone explain why this is happening as it does not seem logical and what can we possibly try to avert this? Refer to the screenshots below:
|
Beta Was this translation helpful? Give feedback.
-
FINAL SOLUTIONWe have solved the initial issue of the contents of the native folder for CefSharp runtime dependency (ChromiumEmbeddedFramework.Runtime.win-*) getting copied over to the bin folder by adding the ExcludeAssets="native" metadata to the projects which reference CefSharp at the level of the CefSharp packages themselves. So the current code stands at: <PackageReference Include="CefSharp.Common" ExcludeAssets="native"/>
<PackageReference Include="CefSharp.WinForms" ExcludeAssets="native" />
<PackageReference Include="CefSharp.OffScreen" ExcludeAssets="native" />The reference for the ChromiumEmbeddedFramework.Runtime.win-* dependency package has been removed from package.props which has also fixed the dependency getting added to projects where CefSharp is not referenced. We had to go through a couple of iterations to arrive at the final solution because we did not understand that the ExcludeAssets="native" tag has to be added at the CefSharp package level (as the files were getting copied over from the native folder under the CefSharp runtime dependency package) and the runtime dependency (ChromiumEmbeddedFramework.Runtime.win-*) does not need to be explicitly mentioned anywhere. Thank you for all your assistance. I chose to update the final solution here so that it may assist someone in the future. |
Beta Was this translation helpful? Give feedback.
-
Thank you so much for your help. I was finally able to resolve the issue following the link you suggested and the following changes from your suggestion.
Originally posted by @koder4076 in #4785 (reply in thread)
Beta Was this translation helpful? Give feedback.
All reactions