nuget.exe should be in PATH (or in a well-defined system-wide location) like any other build tool such as MSBuild. It should never be copied to a project-specific directory because it is a generic tool whose purpose is to avoid the situation where developers commit dependencies directly into their VCS repos. Thus, there needs to be a way to enable the mythical Package Restore feature without creating yet another copy of nuget.exe.
NuGet.targets should be installed to MSBuildExtensionsPath just like .m4 files are installed to /usr/share/aclocal or how Microsoft.WebApplication.targets is installed to $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications.
Sure, installing boilerplate `webClient.DownloadFile("https://www.nuget.org/nuget.exe", OutputFilename);` to every single solution in existence may, in some cases, manage to get people to create more local copies of nuget.exe unknowingly. The correct behavior of failing with an error about nuget.exe not being in PATH is preferred to the proliferation of more boilerplate code copied to more VCS repositories. Anyone seeing that nuget.exe is missing would automatically assume they have to find the installer for the nuget system package.
In its current state, when I try to find a nuget system package installer, I instead find that no such thing exists and I am baffled and confused. My natural instinct upon finding that the distribution point is http://nuget.org/nuget.exe is to open an administrator cmd prompt and run: `cd %USERPROFILE%&wget -Onuget.exe http://nuget.org/nuget.exe&move /y nuget.exe %WINDIR%\system32` since, to the best of my knowledge, system32 is the `/usr/bin` of Windows. But, as a Windows user, I am used to the .msi or setup.exe which nuget is still missing! Also, as a VS user, I am wondering which .targets files I should be manually downloading and plopping into `%PROGRAMFILES(X86)%\MSBuild\`, although, again, I would expect an installer to do the work for me and install the .targets files to to the correct paths.
Why must nuget.exe be so weird and nonconformist? Shouldn’t it instead be an example for other programmers/packagers of packages which try to reduce the amount external code that people copy into their own VCS repos to follow?
Comments: Oh, nevermind, apparently nuget requires the `packages.config` to be included as `<Content/>` in each .csproj in "solution mode" even though it doesn’t have a "project mode".
NuGet.targets should be installed to MSBuildExtensionsPath just like .m4 files are installed to /usr/share/aclocal or how Microsoft.WebApplication.targets is installed to $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications.
Sure, installing boilerplate `webClient.DownloadFile("https://www.nuget.org/nuget.exe", OutputFilename);` to every single solution in existence may, in some cases, manage to get people to create more local copies of nuget.exe unknowingly. The correct behavior of failing with an error about nuget.exe not being in PATH is preferred to the proliferation of more boilerplate code copied to more VCS repositories. Anyone seeing that nuget.exe is missing would automatically assume they have to find the installer for the nuget system package.
In its current state, when I try to find a nuget system package installer, I instead find that no such thing exists and I am baffled and confused. My natural instinct upon finding that the distribution point is http://nuget.org/nuget.exe is to open an administrator cmd prompt and run: `cd %USERPROFILE%&wget -Onuget.exe http://nuget.org/nuget.exe&move /y nuget.exe %WINDIR%\system32` since, to the best of my knowledge, system32 is the `/usr/bin` of Windows. But, as a Windows user, I am used to the .msi or setup.exe which nuget is still missing! Also, as a VS user, I am wondering which .targets files I should be manually downloading and plopping into `%PROGRAMFILES(X86)%\MSBuild\`, although, again, I would expect an installer to do the work for me and install the .targets files to to the correct paths.
Why must nuget.exe be so weird and nonconformist? Shouldn’t it instead be an example for other programmers/packagers of packages which try to reduce the amount external code that people copy into their own VCS repos to follow?
Comments: Oh, nevermind, apparently nuget requires the `packages.config` to be included as `<Content/>` in each .csproj in "solution mode" even though it doesn’t have a "project mode".