(I have a strong feeling there's something fundamental that I'm not understanding here, so please bear with me...)
I have a Local NuGet package feed on a network share that has some packages on it, and I have a User NuGet.Config file that points to that network share as a package source. Inside a project folder (git repository), I have a packages.config file that references a package from this local feed by name. I want to restore this package into this project folder.
What makes this difficult, I think, is that this is not a Visual Studio project. I work with it in a regular text editor, and have some PowerShell build scripts.
I know I can just download the nuget.exe binary and put it in my path or working directory and then do a nuget restore from the command line, but the problem I'm trying to solve here is rather one of philosophical purity. Namely:
Therefore, I can't commit the nuget.exe binary to my repository to make it portable; instead, I want to rely on a prerequisite dependency of "modern Windows 10 environment", which provides me with PowerShell and the built-in PackageManagement tools which come with the ability to bootstrap various providers including PowerShellGet and NuGet.
This feels like the right path, since PackageManagement is designed to be a built-in, unified interface to any package management solution. (But am I misunderstanding this, and it's actually only meant to be for installing software to your operating system or user account? I'm unable to find anything that clearly delineates this.)
So, is it possible to leverage built-in PackageManagement to do a nuget restore (or equivalent) from a packages.config file, outside the scope of Visual Studio? Or if not directly, is there an obvious/simple solution to bootstrapping up from PackageManagement to something that can accomplish this kind of restore?
You could take inspiration from the NuGet team's NuGet.Client repo, where they have a configure.ps1 powershell script that sets up the repo for development/building, and it calls two custom cmdlets Install-NuGet (download nuget.exe from a fixed HTTP source) and then Restore-SolutionPackages (restores a packages.config file), both defined in a common.ps1 file.
So, you could have a powershell script that downloads nuget.exe and runs restore. It means that after cloning the repo (and occasionally after pulling), the developer has an extra manual action to take before the solution can be built with Visual Studio. But, if it's the way the NuGet team does it themselves, it's probably not too horrible, right? At least there's precedent you can point to.
If having developers manually run a script to do this is a problem for you, you could investigate custom MSBuild targets (either include it from relevant csproj files, or simply create a Directory.Build.targets file) and make MSBuild do it when you build the solution. However, you'll probably want to spend time making sure that incremental builds is set up correctly for your custom targets, otherwise it will slow down the build time.