Closed softworkz closed 10 months ago
In my fork, I've just added the tool to the repo and modified the PowerShell scripts, but I wasn't sure whether you'd like that.
The annoyance is that even after downloading nuget.exe, it still won't work with the current scripts as long as you don't add it to %PATH%.
Then I had thought it must be available as a dotnet tool. Then it could have been added in a dotnet tools manifest (dotnet-tools.json) and in the PS scripts you would just run dotnet tools restore
- but it seems that it's not available as a dotnet tool (at least not under the names I've tried).
That's how I came to the winget command. It's a one-line solution, but the shell needs to be re-opened before it works.
We also temporarily add the other tools to the path inside our build file, and restore the original path afterwards (look for $env:Path
). I don't want to force people to manually install tools. Even winget is a tool that needs to be installed. I mean, it's great, I use it a lot. But I don't want it as a dependency here, as long as Microsoft does not ship it with Windows.
Even winget is a tool that needs to be installed.
Oh, I thought it's included, don't remember that I installed it, but maybe it's been late at night..
But I don't want it as a dependency here, as long as Microsoft does not ship it with Windows.
LOL - yea, of course it doesn't make sense to resolve one dependency by requiring another one..
Thank you. I thought about automatically downloading nuget.exe, like we do with other tools. This would also solve issues where nuget.exe is outdated and does not understand the nuspec. But until then, a hint in the readme is good.