✅ Build CefSharp 100.0.120-CI4443 completed (commit 32f8f93baf by @mitchcapper)

• Use same nuget path and download function as build.ps1, I would assume no reason to use ../nuget

Your likely the first person to use UpdateNugetPackages.ps1, it was something I hacked together to make things easier when upgrading 😄 Reason for using a relative nuget.exe is that's what I always have on my machine. Having the script download if required makes sense 👍

• Major change: Edit the NuGet\CefSharp.Common.nuspec file to only require the cef dist files for the build users want. Rather than having an input file, or hardcoding the node data for the xml node we want added/removed we will just use the existing one as the template.

This should have already been covered by build.ps1 as part of generating the packages. Is it not working?

I'd prefer to keep all changes to the nuspec files as part of build.ps1 if possible as it already has logic for dealing with the different architectures.

Do you need a specific target to use as part of your workflow? Happy to split that out as a new target if required

Mostly rather than using my own scripts before to change versions I figure if UpdateNugetPackages.ps1 can do it all the better. Plus as it already has to happen on new versions officially makes it a bit easier.

As for the build.ps1 instead for the feature change, no problem and will investigate why it did not work for me in current form. Last time I built with a custom version number and just x64 for the arches it still referenced the x86 redist package in the Common cefsharp package and failed to build.

As for why, there is an annoying windows 10 21H2 docker issue where they did not put out windows base images that match the kernel version. This forces you to use hyperV rather than straight process isolation and it takes forever. This is fixed in w11 but not currently looking to upgrade. Building only x64 cuts time way down.

Mostly rather than using my own scripts before to change versions I figure if UpdateNugetPackages.ps1 can do it all the better. Plus as it already has to happen on new versions officially makes it a bit easier.

Makes sense to use the same script if possible 👍 I'll merge the base changes later today so I can test when when I upgrade to M101 shortly.

As for the build.ps1 instead for the feature change, no problem and will investigate why it did not work for me in current form. Last time I built with a custom version number and just x64 for the arches it still referenced the x86 redist package in the Common cefsharp package and failed to build.

It's possible there's a mistake, happy to take a look when I get a minute.

As for why, there is an annoying windows 10 21H2 docker issue where they did not put out windows base images that match the kernel version. This forces you to use hyperV rather than straight process isolation and it takes forever. This is fixed in w11 but not currently looking to upgrade. Building only x64 cuts time way down.

Building only the arch you need sounds very reasonable to me 👍 I'm sticking with Win 10 as hardware I have is too old to run Win 11.

It's possible there's a mistake, happy to take a look when I get a minute.

Confirming there is a problem, I've forgotten to remove the dependency. Should be a simple fix.

I didn't see any files with EnsureNuGetPackageBuildImports targets any more but I believe that xpath should be correct.

I've tested locally and the EnsureNuGetPackageBuildImports aren't removed, adding the namespace to the xpath query got it working again.

Merged via cherry pick cfa5b41

Additional changes made in commit 78b682a

build.ps1 handles changing CefSharp.common.nuspec. Fixed the EnsureNuGetPackageBuildImports and did a little reordering of code so functions are first.

First commit to use the updated script is 684e76c

Everything looks OK so far.

Confirming there is a problem, I've forgotten to remove the dependency. Should be a simple fix.

The nuspec dep should be fixed in commit 80ea921

If you are still having problems with #4066 then please let me know.