(#508) Uplift NuGet library

[TheCakeIsNaOH]

Description Of Changes

Uplift Chocolatey CLI from NuGet.Core to using NuGet.Client

Motivation and Context

This allows for features like V3 api support, and SemVer 2.0

Testing

Built and ran tests.

Things to test list

• Test stuff when running on Linux, including uninstalling uppercase packages. (Everything seems to be working as far as I can tell).
• Test if new (to Chocolatey) nuspec elements break anything locally, in licensed, or on CCR. Then potentially add validation to pack (and/or push) to ensure the new .nuspec element are not used if needed, or warn if they would be ignored currently?
• Test and add tests for semver 2.0 prerelease strings
• Test against v3 feeds in more scenarios
• Test to see if NuGet errors are reported to stdout instead of stderr #1648 is fixed
• See if I can get a reproduction for Upgrading a package won't work as depending versions are not resolved properly  #1408 and test if it is fixed
• Test if chocolateyBeforeModify.ps1 does not get called for dependent packages #1092 is fixed by this.
• Test leading zeros, breaking change? Prevent usage of leading 0 in package version numbers #1174
• Investigate changes to pack token substitution, this issue seems to indicate that there may have been changes upstream: new - Token replacement with in nuspec should more closely match nuget #2100
• Investigate changes to pack encoding filenames, due to potential upstream changes: pack - URI encodes filenames #1628
• See if proxy support for push comes along for the ride with supporting proxies for other calls: Push command does not honor proxy settings #1271
• Test other push authentication, push - add authentication same as with other methods that use sources #2026
• See if choco uninstall all does not honor dependencies #1822 is fixed

Tests to add:

• Add test(s) to ensure that the NuGet version is still correct after ilmerging the libraries. Potentially would throw errors about needing to upgrade NuGet if it is not working.
• Add tests around new semantic versioning prerelease strings, check that pack, install, etc all work.
• Add tests to ensure that Nuspec files with forward slash creates nested layer of directories when packed on Windows #2166 does not reoccur (perhaps upstream the fix for it?)
• Add tests to ensure that Prevent creation of empty nuget.config in user appdata folder #2233 does not reoccur
• Add tests to ensure that Building a package on Linux fails if the description has encoded xml special character(s) #2382 does not reoccur
• Add tests for install/search/outdated/upgrade/etc with relative local path (#508) Attempt to resolve relative paths for sources #2943
• Add tests around logging for all install messages
• Add more pin scenarios, and/or mock out pending pin scenarios (should be more doable with new libraries hopefully) and enable the tests
• Add tests to ensure that package and install arguments are not passed to dependent packages unless argument(s) specified to do so
• Add scenarios for pinned dependencies for install/upgrade/uninstall
  • Install that requires upgrade/downgrade of pinned dependency
  • Upgrade that requires upgrade/downgrade of pinned dependency
  • Upgrade that requires upgrade of pinned parent
  • Uninstall (with force dependencies) that tries to uninstall pinned dependency
• Add tests for chocolateyPackageVersionPrerelease and chocolateyPackageVersionPackageRelease to ensure that they are set correctly, e.g. normalized, etc
• Add test for uninstalling package with package ID that includes uppercase letter(s) (#508) Fix nuspec casing on non-Windows #2957

Known issues

• Logging from NuGet is at a more verbose level than needed. This can be adjusted either in the NuGet.Client fork, or in the ChocolateyNugetLogger class. What to do should be determined by a review of the messages from libraries once they used classes/methods are more settled on. This can be seen when running choco install and choco search by the network requests information logged to info by NuGet. (#508) Change NuGet normal logging to be verbose logging #2944
• Pushing packages to CCR does not work (and does not error, where it should work or error). This can be seen by pushing a valid package to CCR with a valid apikey, and having it say that it was ok, but no package was actually uploaded.
• When push has errors, they are not always caught correctly. I have not always been able to reproduce this, but pushing to nexus with a bad apikey, or where the server is not available are two situations that should trigger it. Once pushing to CCR is working, then testing the error handling if the package already exists would be appropriate.
• Using a relative local path as a source is not working. When using a dot . as the source like .\choco.exe list -s ., it erors with The path '.' for the selected source could not be resolved.. However, installs do seem to be working? (#508) Attempt to resolve relative paths for sources #2943
• There are quirks with list/search. Not sure what all is broken. Test matrix should include listing/searching from a local folder, from v2 APIs like CCR and nexus, and from V3 APIs like NuGet.org and Nexus, then should have a search with no search term (so listing all package), listing with a search term, listing with a search term with --exact and/or --all-versions
• A couple of the list/search command line options are not properly functional. --page, --page-size=, --by-tags-only are all likely broken in some cases. (#508) Fix --page and --page-size arguments #2949 and --by-tags-only is working.
• Download progress is not available. Previously, the PackageDownloader class was overridden, but the class no longer actually downloads the packages inside it. (#9) Add Download Progress NuGet.Client#12
• The code to set a source bypass a proxy has not been ported to NuGet.Client, so it won't work. Proxy functionality should be tested first.
• Search and outdated commands use way more API calls than previously in some cases. Try running search with and without a search term, --exact and --all-versions, then compare to NuGet.Core quantity of calls. It may also be worth looking at install/upgrade when --version is not passed, and for packages that have a large dependency chain.
• Source priority is not respected. It might just so happen to work, but there is no longer any code that explicitly enforces it.

Features to add?

Moved to comment: #2740 (comment)

Completed

• Fork NuGet.Client
• Create a list of commits added to nuget-chocolatey that should be ported/upstreamed/ignored/investigated
• Investigation of various things relating to the licensed extension. Overriding nuget download service?

Change Types Made

• Bug fix (non-breaking change)
• Feature / Enhancement (non-breaking change)
• Breaking change (fix or feature that could cause existing functionality to change)

Related Issue

Preparing for #508

Change Checklist

• Requires a change to the documentation
• Documentation has been updated
• Tests to cover my changes, have been added
• All new and existing tests passed.
• PowerShell v2 compatibility checked.

[TheCakeIsNaOH]

Some initial thoughts:

• Semver stuff is now available in NuGet.Versioning, and appears to be fairly compatible, at least from a compilation point of view.
• There is a ILogger available in NuGet.Common, against somewhat compatible with the current interface.
• Metadata, information about packages, and IPackageDownloader are available in NuGet.Packaging
• IPackage is no longer available, and it is heavily used in the Chocolatey codebase.
• I'm completely ignoring the unit/integration tests for the moment, some do have NuGet references.
• There are NuGet references to IPackage and similar across the codebase, but as to calling actual methods, that is mostly limited to stuff in infrastructure.app.nuget, in the NugetService, and in the templates/pins commands (to check for locally installed packages, these probably could be abstracted into something in the NugetService or whatever).

[TheCakeIsNaOH]

I went for the low hanging fruit and got push working to my local nexus repository. There are still a number of things that are broken, but it is kinda working:

• The logging levels need adjustment to be less verbose. I'm not sure if that is adjustment in ChocolateyNugetLogger, something that can be set via a method in NuGet, or something that needs to be changed in the NuGet code.
• When attempting to push to Nexus with an invalid apikey, it instead asks for username/password, although I can't reproduce it anymore. Either way, it is something to possibly investigate if it pops up: Forbidden status and prompted to enter credentials when attempt to push new package with same ID as an existing one NuGet/Home#3391
• The user-agent header is being partially set, but it always includes the version of the NuGet library, and there is no way to set that. So, I've set it to do this, Chocolatey Command Line/<version> via NuGet Client/<nuget version>. There is an upstream issue open here: Users using the API should have greater control over the user agent string NuGet/Home#7464
• Pushing to CCR (via https://push.chocolatey.org) is not working. If it is a valid package and apikey, then nuget logs ok and that the package was pushed, but the package was definitely not pushed. Same thing happens with a pre-existing immutable package version, with both a valid and invalid API key.
• I suspect that different exceptions would be thrown than with NuGet.Core , so the exception handling will need to be checked, once things are working better.

Other notes:

• I traced the codepath that nuget.exe uses, and replicated the approiate method calls, at about the same abstraction level as push via NuGet.Core had.
• Detection of the push being a v2 vs v3 feed seems to happen automatically, and so this should theoretically "just work" for both.
• Appending of /api/v2/packages to the push source was disabled by noServiceEndpoint, as Chocolatey has push URLs that are specified explicitly.
• Reminder to self, test "pushing" packages to a unc location. Edit: this is working for me. It does spit out an error about skipping duplicates not being supported, but that can be dealt with later.

[TheCakeIsNaOH]

So, I've got pack working as well. It works with NuGet compatible .nupecs, so using the older schema and not using any of the elements added to nuget-chocolatey.

• This is one area that has not changed much from older library versions. It just required tweaking a couple of things like switching from implementing an interface to passing a function, but overall, not super difficult. Yay for low-hanging fruit.
• Since there are not a lot of changes, it is looking like it is still not easy to add additional elements, but on the upside, it looks like it would be reasonably easy to bring forward the commit(s) from nuget-chocolatey to the newer libraries. It is possible everything would be contained within NuGet.Packaging, but it would actually have to be ported to ensure that.
• File filtering, and .nuspec metadata property replacement are working as far as I can tell
• It also looks like it would be fairly simple to bring in the command line specification of file exclude filters in from NuGet, the code would be almost copy/paste for the filtering.

[TheCakeIsNaOH]

A couple of things I noted today in research:

• The protocol for pushing is the same between v2 and v3, so there is not a new/separate push URL for nuget.org or for Nexus as they both would have the same push URL between v2 and v3 APIs. "Push and Delete" mentions API v3 but URLs use v2 NuGet/docs.microsoft.com-nuget#964 and https://docs.microsoft.com/en-us/nuget/api/package-publish-resource#base-url
• There is another way that could be used to get a PackageUpdateResource documented here: https://docs.microsoft.com/en-us/nuget/reference/nuget-client-sdk#push-a-package as compared to the method used when running the nuget push command: https://github.com/NuGet/NuGet.Client/blob/beb3bd51b1d4af1a1c17cbed5a9cc4b190a10a30/src/NuGet.Core/NuGet.Commands/CommandRunners/PushRunner.cs#L34-L42
• After looking at the metadata code and confirming with Gary, it looks like it will be a requirement to fork the NuGet.Client repository to allow Chocolatey packages to be packed, instead of only NuGet compatible packages. A custom version of the NuGet.Packaging package would be required to add the Chocolatey .nuspec schema. Potentially other packages would also have to be forked, but that is still up in the air.
• Fortunately, it seems like everything required is in the one repository. There are submodules currently, but they mostly gone in the dev branch: Stop using FileSystem and Common submodules NuGet/NuGet.Client#4536
• Also fortunately, it looks like that area of the codebase has not changed as much as some other areas, so hopefully it should be fairly smooth to port the relevant commit(s) from nuget-chocolatey.
• As to my todo from Friday for testing pushing to a UNC path, that is working for me.

[TheCakeIsNaOH]

In nuget-chocolatey, IPackage inherits from IPackageMetadata (which provides the metadata available in .nupec) and from IServerPackageMetadata (which provides the other metadata not in .nuspec schema but available from v2 API feeds). Therefore,

In NuGet.Client, IPackage has been removed. IPackageMetadata still exists, in almost unchanged form. However, IServerPackageMetadata is not available, with IPackageSearchMetadata taking it's place. IPackageSearchMetadata has all of the metadata from a source, not just the metadata not available in a .nuspec. Therefore, we can't just re-add IPackage, as there would be name conflicts/ambiguity between the two now, for example they both have title.

Instead, I'm thinking of using IPackageMetadata and IPackageSearchMetadata directly, and replacing usages of IPackage with the appropriate one as required. Say for example, with PackageResult, instead of using instance.Package, use instance.PackageMetadata/instance.SearchMetadata (or whatever they are called).

This would require changes in lots of files, but theoretically the changes mostly should just be updating the names of things without too many larger changes. I talked with @gep13 about this, and it seems like a reasonable option to explore.

[TheCakeIsNaOH]

While looking into getting list/search/find working, there are a couple of fun things I discovered:

• There is no longer a concept of an AggregateRepository that I could find to have a single repository object with multiple sources. Instead, commands like nuget list and nuget search have to keep a list of sources, and iterate through them to initialize the repository, get the resource, get the package(s), and print out the results. This means that Chocolatey will have to take ownership of that, although that is an upside is that version resolution behavior can be adjusted as required without having to dive into nuget code (see Switch aggregate repository package resolution to all feeds for latest instead of just first location found (Vertical) #283 for example).
• I do not think there is currently a concept of a source priority in the NuGet.Client codebase, at least nothing close to the way Chocolatey does. It will have to be investigated further.
• There are a number of nice resources to do some search things, like finding all versions of a package (FindPackageByIdResource), or getting information about a specific package (PackageMetadataResource), or searching for a package (PackageSearchResource). Some of these fit very neatly into a specific use (i.e. specific switch combination) of the list/search/find command, but not all uses.
• There is also a ListResource, for listing all packages on a source, but unfortunately, that is only available for V2 feeds and local packages. There is no direct equivalent for the V3 api at the moment, Package ID service (enumerate all package IDs) for V3 feeds NuGet/NuGetGallery#3878
• The only reason the nuget list command works for the nuget v3 source is because that source has a link that says "here, go look at the v2 feed to list packages", see this Add a sample for listing package ids from a feed. NuGet/Samples#41 (comment) I discovered this when nuget list refused to list against my local Nexus instance.
• The NuGet catalog also exists as a suggested alternative to using the v2 search API, but it is only implemented for some repositories (so nuget.org has it, but my Nexus instance does not). Additionally, there is no library in NuGet.Client that I am aware of that will process this, so Chocolatey would either have to fork NuGet.Jobs to use NuGet.Protocol.Catalog from their gallery jobs implementation or download and process the Json manually.
• On the upside, the catalog is a good candidate for downloading to use as a local package index, since it is an append only log of additions/modifications/deletions of packages on the repository. And since there is no longer an aggregate repository, then package indices could be stored per source without issue and results combined inside the Chocolatey code as needed.
• Since not all repositories Chocolatey would use would have one of these options to use for a listing of all packages, then a fallback to the PackageSearchResource with an empty search term would be required to list all packages. The fun part of using this is that it would mean that it is pagination time. Joy. Though it could mean getting results out to the screen quicker instead of waiting for everything, and being able to work around Nexus pagination issues if needed.

[TheCakeIsNaOH]

With Chocolatey CLI versions that use NuGet.Core, when upgrading a package that has a "parent" package, it will upgrade the parent package to the lowest version that will work with the dependency package being installed, while with the NuGet SDK, it is the highest version. A "parent" package means a package that depends on the dependency package that is being upgraded.

Here is the integration test example. It has a starting situation of hasdependency 1.0.0 and isdependency 1.0.0 being installed, where hasdependency 1.0.0 depends on isdependency [1.0.0, 2.0.0). Then upgrade is run for hasdependency, with the latest version of 2.1.0, which is not compatible with the installed version of hasdependency. Therefore, hasdependency is upgraded to a version that is compatible with isdependency 2.1.0. The source has multiple versions of hasdependency that are compatible (with isdependency 2.1.0) ranging from version 1.0.1 to 2.1.0.

With NuGet.Core (where PackageManager is set to DependencyVersion.Highest), then it will choose version 1.0.1 of hasdependency, i.e. the lowest compatible version available.
With NuGet SDK package resolver (Set to DependencyVersion.Highest), then it will choose version 2.1.0 of hasdependency, i.e. the highest compatible version available.

This does seem to be a breaking change, as it is behavior that is integration tested for, and the tests do fail when using NuGet SDK. However the NuGet SDK behavior where it installs the highest compatible version seems to be the correct behavior, given that it is set to DependencyVersion.Highest.

I don't think there is a way to tweak this behavior without changing DependencyVersion.Highest to something else, which would break other things. Or of course, changing code in the NuGet.Resolver library, which I am not touching if at all possible.

So, the question becomes, are there any operational cases where this breaking change would be a problem? If so, this needs to be investigated further to see if there is a way to mitigate or it that case. If not, then it should be documented during release, and the tests changed to reflect the new behavior

I'll assume it is the second option for the moment, and modify the tests to assume the highest compatible version of parent package(s) will be installed, instead of the lowest.

[TheCakeIsNaOH]

The NuGet.Versioning library has both a SemanticVersion class and a NuGetVersion class. The SemanticVersion class is a strict semver 2.0 system, while the NuGetVersion class has the support for the fourth revision element in the version. See documentation here: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#where-nugetversion-diverges-from-semantic-versioning

Therefore, usages of SemanticVersion from NuGet.Core have been switched to use NuGetVersion, and same for any further uses unless there is some reason to use strict semver 2 in a specific area.

Another change from NuGet.Core is that the Constants class has been renamed to NuGetConstants, but some things are now in PackagingConstants. All of the ones that Chocolatey uses (like .nupkg, .nuspec) are still available, so it is simply a matter of a search+replace.

For reading .nupkg files, NuGet.Core had OptimizedZipPackage. The equivalent in NuGet SDK is PackageArchiveReader, which offers similar functionality. It does have to be disposed of though, so using statements need to be added in, but fortunately, this does not translate to huge amounts of indentation changes since most times it is being used in Chocolatey, it is just a line or two of getting the metadata from the .nuspec in the .nupkg

[TheCakeIsNaOH]

Proposal for a branching strategy for the NuGet.Client fork:

• Upstream tracks development in the dev branch as the main branch PRs target. Then for a release a release-A.B.x branch is created (where A.B is the major.minor version like 6.3), and any fixes for A.B are pull into that branch (and/or picked from the dev branch).
• From what I understand, the intention is for Chocolatey to create custom builds with changes, but that follow upstream fairly closely. So the intent is for the changes to be more of a patch set that is applied on top of the latest code, instead of a major fork that changes lots of things and diverges from upstream.
• So, assuming we want to use git to add the patch set as commits, instead of having a separate repository of .patch files or something, that leaves two options: merging changes, or rebasing on top of changes.
• Given that rebasing the patch commits on top of new upstream commits (in the same branch) means rewriting history, that is a no-go for a number of reasons.
• But merging could work. So base the fork on the dev branch, and then upstream changes get brought in with merge commits. The downside of this is that it makes the history very messy, and it could be hard to get a sense of what the actual patch set on top of upstream is, because there are the patches mixed in on the commit history.
• So, instead I propose basing the fork on the release-A.B.x branch. Then once upstream creates the release-A.B+1 branch, the required commits can be cherry-picked onto the release-A.B+1 branch (and cleaned up if needed to create a streamlined patch set). If there are any upstream commits on the release- branch, then they can be merged in. This allows for a much shorter history that has to be picked through to separate out upstream work from work on the fork. The downside is that it means that the active development branch of the fork is changing frequently.

To keep the fork up to date, it may be a good idea to utilize a bot to create PRs to merge in changes on the release-* branch from upstream, and to create new release-* branches as they become available.

• One option for merging in changes is pull: https://github.com/wei/pull
• An option for doing both would be to build something using probot: https://github.com/probot/probot
  • The Nextcloud organization has one that uses probot to backport code to previous release branches: https://github.com/nextcloud/backportbot

[TheCakeIsNaOH]

The NuGet PackageResolver class does not have proper documentation, but fortunately, with the method parameter comments and reading through how NuGetPackageManager uses it, it is possible to set up. The Resolve() method takes a PackageResolverContext, and the parameters passed into that are where the real action is in regard to using the resolver.

There is not a distinction between upgrades and installs for the dependency resolver, so more or less the same setup can be used for installs and upgrades.

Here is my explanation of what to pass to the PackageResolverContext to use it with Chocolatey:

• dependencyBehavior: This is set to DependencyBehavior.Highest, same a used with the NuGet.Core package manager. Given what Chocolatey's intended use case, having everything be the newest version that work for everything is ideal.
• targetIds: A IEnumerable of strings, with just one entry with the ID of the package being installed.
• requiredPackageIds: An IEnumerable of strings. This should have the package IDs of all packages locally installed, minus the ID of the package being installed (in the case that it was already installed, and it is being forced or a different version is being installed).
• packagesConfig: An IEnumerable of PackageReference (a representation of a package ID, version, and allowed framework). Same as above, should include all packages installed locally, minus any versions of the package to be installed.
• preferredVersions: An IEnumerable of PackageIdentity (a representation of a package ID and version). Same as the two above, should include all packages installed locally, minus any versions of the package to be installed.
• availablePackages: An IEnumerable of SourcePackageDependencyInfo (A partial set of metadata about a package). This should include the dependency infos of all locally installed packages (again minus any versions of the package that is to be installed), joined with the dependency info of the package version to be installed, and the dependency infos of all available versions all direct and child dependencies of the package version to be installed.
• packageSources: Pass in the PackageSource from the enabled sources
• log: Pass in a ILogger like ChocolateyNuGetLogger

These have worked for all situations in the tests, and everything I have played with manually. There could be situations, say for example with multiple versions of packages installed, and complex dependency trees, that it does not work for, but nothing has popped out yet.

As for uninstalls, instead of using PackageResolver, use NuGet.PackageManagement.UninstallResolver.GetPackagesToBeUninstalled.

[TheCakeIsNaOH]

Features to possibly add

Investigate adding support for v3 catalog reading/parsing

This would be for the purpose of adding a local index of packages: #820

Some NuGet v3 feeds support the catalog resource: https://docs.microsoft.com/en-us/nuget/api/catalog-resource

It is a append-only resource that records all package additions/changes/unlistings in a json format. So it could be paged through and saved locally, and updated via a new update command to update the index. Then the data can be read locally and parsed as needed.

There are a few samples and projects that use it, but it is not something available through NuGet.Client as far as I am aware, so it would have to be implemented within Chocolatey.

https://github.com/NuGet/NuGet.Jobs/tree/main/src/NuGet.Protocol.Catalog
https://github.com/emgarten/NuGet.CatalogReader
https://github.com/NuGet/Samples/tree/main/CatalogReaderExample

Figure out version ranges, potentially get version range working for --version and/or pin

Feature requests from these two issues: #1278, #800

The NuGet SDK provides a nice class called VersionRange that allows representing a range of allowed versions. It should be possible to be able to use this to parse and represent a version range passed in.

The version range can be saved within the pin file, if the pin file is empty, then it falls back to the previous behavior of pinning the current version.

Then during upgrade, the metadata for all package versions (for the package being upgraded) can be gotten, and filtered to versions allowed in the version range, and then the max of those be used for upgrade.

Add and test validation of package signing

Feature request here: #504

This may already be working, but has not been tested yet. It should be a matter of setting the ClientPolicyContext correctly in the ChocolateyNuGetProjectContext implementation of INuGetProjectContext. Which then gets passed into FolderNuGetProject.InstallPackageAsync which has signature validation, depending on what ClientPolicyContext is set to.

Add in per-source confirmation?

Feature request here: #179

Given the manual package installation routine, it would be possible to toggle confirmation on and off without too much issue for each package.

This may or may not require changes to NuGet.Client, similar to what is required for #1486 to make sure that the source is available inside Chocolatey to check if it require confirmation.

Add in checksum validation of downloaded .nupkgs?

Feature request: #1144

It may be a good idea to investigate adding checksum validation at the same time as validating the .nupkg code signature. Checksums are provided from some repositories, and exposed via IPackageSearchMetadata

Improve the NuGet user-agent?

The user-agent header is being partially set by Chocolatey, but it always includes the version of the NuGet library, and there is no way to currently change that.

So, I've set it to do this, Chocolatey Command Line/<version> via NuGet Client/<nuget version>. This method is fine, but potentially it may want to be changed.

There is an upstream issue open here to allow complete control over the user-agent string: NuGet/Home#7464

Install a (locally available) non-packed/extracted .nupkg?

Feature request #903, may require #624

This should be a case of coping the required files, and then moving right along to the continue action to run the package automation scripts.

Don't save the .nupkg, only keep the .nuspec

Feature request #624

This could be as simple as flipping the current PackageSaveMode.Nupkg | PackageSaveMode.Nuspec | PackageSaveMode.Files to PackageSaveMode.Nuspec | PackageSaveMode.Files in the package extraction context in the ChocolateyNuGetProjectContext implementation of INuGetProjectContext

It would breaks lots of tests, and potentially anything else in Chocolatey that relies on the .nupkg being there, but I think those all could be worked around by just reading the info from the .nuspec directly, and if a list of files is required, reading the .files file for the package. It also should be looked at if any of the list -lo things get broken, but again, that should be reasonable to work around.

Allow dependencies from alternate sources?

Feature request #879

Probably requires changes to the .nuspec schema to add an extra element. Due to the manual installation routine, any dependencies from alternate sources can be removed before passing things to the dependency resolver, then it should be a case of just calling the alternate source for the install of the dependency.

[TheCakeIsNaOH]

As side by side is going to be removed, I'm updating this to not include side by side support.
The code with side by side support is backed up in this branch: https://github.com/TheCakeIsNaOH/choco/tree/nuget-v3-sidebyside

And here is the branch with the previous version of the NuGet.Client code: https://github.com/TheCakeIsNaOH/NuGet.Client/tree/sidebyside-backup

[TheCakeIsNaOH]

To be able to rebase this without a huge amount of hassle, I had to squash a bunch of commits, since otherwise changes would not merge smoothly in. As noted in the last comment, the previous version of this branch is still available here: https://github.com/TheCakeIsNaOH/choco/tree/nuget-v3-sidebyside

[choco-bot]

Task linked: PROJ-311 Take some time to familiarise ourselves with the changes that Josiah has put into PR

[AdmiringWorm]

These are just notes for us on the Chocolatey Team. No change is needed, as we will merge this code as is (after a few updates) and continue working on it.

[AdmiringWorm]

Failures on GitHub action here is expected, we have not made the NuGet.Client libraries we use public yet.

[AdmiringWorm]

LGTM, thank you for your work on this @TheCakeIsNaOH. We have decided to pull these changes in and continue working on them to fix any outstanding issues in separate pull requests.