Consider installer for NuGet.exe (w/ adding to path, etc...)

[mtrtm]

The release for nuget states that nuget "is only available with Visual Studio 2015, and was included in the distribution of Visual Studio 2015 Update 1". I have a clean development machine with VS 2015 and can open up Package Manager Console, type nuget, and get an error. This is crazy, it should just work.

I know Windows users shy away from the command line, but stuff like this is why. Please set the path upon install so nuget 'just works'. It is so annoying every time I try to do anything via command line I have to add folders to path and close/open apps.

[yishaigalatzer]

NuGet.exe is not part of the nuget visual studio install, furthermore package manager console is not intended to run generic command line executables.

We do not have an installer for nuget.exe, and don't plan to have one. We expect you to add nuget.exe to the path of your choice.

[hit comment too fast] I'm interested to hear if you have further input for discussion here.

[mtrtm]

OK, so which is correct? The home page and your comment seem to contradict one another.

[yishaigalatzer]

Can you link to what you refer to?

[mtrtm]

http://docs.nuget.org/ has the quote I referred to earlier: "NuGet 3.3 was released on November 30, 2015, is only available with Visual Studio 2015, and was included in the distribution of Visual Studio 2015 Update 1"

[yishaigalatzer]

Thanks, what is the contradictory statement? NuGet 3.3 is a generic name for the release, we have released two separate products:

1. The vsix (or the visual studio extensions)
2. NuGet.exe

They are individually downloadable, and one doesn't require the other.

[mtrtm]

OK, so you are implying that "NuGet 3.3" actually means the NuGet visual studio extension.

1. That's too bad, not sure why one would be included but not the other
2. If that isn't changing, I would suggest being explicit about this as it could be read either way
3. Maybe there is a difficulty that I don't see, but it would be best for users to have both vsix and exe, so why is the exe excluded?

[yishaigalatzer]

OK, so you are implying that "NuGet 3.3" actually means the NuGet visual studio extension. No, I'm saying that NuGet 3.3 is host of products, it is both the vsix and the exe. And they are two separate products.

1. That's too bad, not sure why one would be included but not the other It is just two separate downloads, both are available from https://dist.nuget.org/index.html
2. If that isn't changing, I would suggest being explicit about this as it could be read either way Sure we will make our next announcement crisper
3. Maybe there is a difficulty that I don't see, but it would be best for users to have both vsix and exe, so why is the exe excluded? The exe is not excluded as mentioned above. In general we don't install extra components as part of nuget.vsix because it is just a vs extension that revs without our control and we are not able to touch program files at that stage (as it requires elevation). This became even more important in visual studio update 2 to allow for auto updates.

If we started dropping nuget.exe as part of the vs install, you will quickly end up with stale instances of nuget.exe, so for now we prefer to not add it to the installer until we can figure out a good story. I'm definitely not saying this will never happen, just that it is not high enough on our todo list and the impact of downloading nuget.exe is very low. I need to find the bug asking as to include it, it should be somewhere here (and if not we can reuse this issue for that).

Last - I would really advise against using nuget.exe in the powershell console, you have a lot more power with the built in powershell commands, and I would love to know what you are missing that leads you to trying to use nuget.exe there?

[mtrtm]

I would assume that the following user story would be beneficial for everyone:

"As a user, I open Visual Studio 2015, open the Package Manager Console window, type nuget, see nuget options"

What it is now:

"As a user, I open Visual Studio 2015, open the Package Manager Console window, type nuget, get an error, google the error, read a bit, realize I have to download nuget.exe even though I know nuget works in VS, download it, add it to my path environment variable, close visual studio and then [insert first user story here]".

Just trying to be helpful. I just setup another dev machine and am starting to get fairly critical of things that just don't work out of the box.

[yishaigalatzer]

That's not the what you are supposed to do. You should use nuget.exe in the package manager console. You should use the built in cmdlets like find-package etc. Everything you need is already there, see https://docs.nuget.org/consume/package-manager-console-powershell-reference

[mtrtm]

We are definitely talking past each other here. I am using package manager console. It doesn't work out of the box, and the second user story above is what is required to make the console work on a clean install. I'm not sure what you are trying to say

[yishaigalatzer]

Obviously. Nuget.exe is not intended to be called from package manager console, read the doc link it shows what is intended to work there. And let's talk again after you read it

[yishaigalatzer]

I'll also be glad to jump on a Skype call to talk directly. Yishai Galatzer is my Skype id

[mtrtm]

I don't have skype or else I would. You say "You should use nuget.exe in the package manager console", then 6 minutes later you say "Nuget.exe is not intended to be called from package manager console".

Either way, developers find themselves needing to directly use nuget.exe for things other than getting packages. When that happens, they can use cmd, powershell, or package manager console. I refer back to my user stories - the second one is the current process, and it is a waste of time.

[yishaigalatzer]

Sorry if it sounded like I said it, that would be my mistake in communication. Let me clarify "You should not use or need to use nuget.exe in package manager console", package manager console provides cmdlets that cover everything you need to use. All of that is documented in the link I sent above.

Furthermore package manager console is not a generic console for running any executable, it is all about visual studio automation. I know it seems otherwise but we have no control over it. You should use a regular console windows or powershell console outside of visual studio.

So if you are asking for installing nuget.exe on your machine, we could build an installer that brings it. Since I couldn't find a duplicate bug and this thread is becoming a bit large and more of a discussion, I'll open an issue to make the visual studio installer bring down nuget.exe and make it available on the path.

Does that make sense?

I'm still open to a voice chat over any way you would like to (phone or any other other tool is fine), let me know if you are game I'd like to hear from you in more detail what exactly is getting in your way so we can do better.

[yishaigalatzer]

https://github.com/NuGet/Home/issues/2473

[wpostma]

This is a good example of the system design and the users being "incommunicado". It seems odd to me that Visual Studio has all these different "command console" like windows, one is designed only for install-package and similar cmdlets. And developers who package with nuget (and don't just install with nuget) and need to use nuget.exe spec and nuget.exe pack get a second rate experience because of this.

I wonder what the decision tree was that lead to the strange experience of "Nuget the VSIX" and "Nuget.exe the command line tool" being the story that they have today.

[yishaigalatzer]

@wpostma that's a great question, I wasn't around when it happened initially so I can only speculate like you.

As for the pack comment, we are introducing pack as a first class citizen in the next version of visual studio (without the need to have nuget.exe on the machine).

[wpostma]

that's fabulous. If it was my product I'd drop the Nuget "pseudo-powershell window where you can only run install-package" and put all the commands in ONE all-purpose-powershell-cmdlet-runner window. I would have powershell cmdlets for pack and push and every other verb that nuget supports, and powershell commands for every other thing (including something that would replace msdeploy).

Mantra: "DevOps all the things!"

[yishaigalatzer]

That's a noble goal, and sounds great. The reason for the powershell window is that it runs within the visual studio host and can interact with project system. That's just not easily supported from an external command line.

Our goal is a little bit different, we want to unify the nuget.exe scenarios to work without any dependency on visual studio, and have the ability to run x-plat on unix/mac/windows.

The core feature needed for this is to stop writing things the project systems owns into the csproj/XXproj files. The new <PackageReference> node will be the corner stone from detangling the two.

[wpostma]

Ah yes, that's a good goal. I don't think very many people who use "Install-Package" from that window know what it does and how it works, thanks for the explanation.

[NathanTheGr8]

This may not be the best place for this but I can't find it anywhere else and this thread is the top google result for "add nuget to path environment variable". I don't know how to do that and all your offical install guide for nuget cli says is "If desired, add that location to your PATH environment variable so you can NuGet from anywhere. " Not very detailed instuctions. A link to how to do that would be greatly appreciated.

So in short what is the windows path environment variable and how do I edit it so that I can just type "nuget" and not "\path\to\nuget.exe" Thank you for your help.

[wpostma]

Hi Nathan, it depends on whether you're talking about a CI server (build server), or your PC.

On your own PC, I would suggest you use this tutorial:

http://superuser.com/questions/444109/regarding-the-way-to-add-a-directory-to-the-path-environment-under-windows

This is a very basic task that any software developer and even any intermediate level windows user should know. As a developer you will often find your path grows out of control, has too many directories in it, and you should get comfortable with what's in your path, as you should be managing the path contents carefully.

Click here for a picture of where to click:

https://i.stack.imgur.com/JphSc.png

[NathanTheGr8]

I was talking about about the PC version, also "This is a very basic task that any software developer and even any intermediate level windows user should know." regardless of if you think it was basic, it wasn't to me. I am coming from a linux background and I am trying to incorporate nuget for my work powershell scripts. I am familiar with path variables for linux but most installers do this for you. Every app I have ever installed with homebrew or aptitude does this for me. I have only ever had to add a path variable for sublime on my mac. I think the CLI install guide would greatly benefit from adding this info.

Where should I store the nuget.exe file? Is there a convention on where I should be saving it? Also when I type

nuget.exe install nuget.commandline

It makes a folder in the same path as the nuget.exe called NuGet.CommandLine.3.4.3 Inside that folder is a nuget commandline.nupkg and a folder named tools. What is the difference between the nuget CLI exe I downloaded and this nuget.commandline?

[wpostma]

Hi Nathan, I'm just a community member like yourself. Imagine someone goes to a random github project and asks "how do I change my login shell from bash to ksh", I'm just pointing out that it's a basic system admin task. Now you DO know. Welcome to the club. Next time you need to know "how to do X on windows, for new windows people", try superuser.com

You also should be going in there and removing stuff that shouldn't be in there anymore or your build systems will fail to find the right versions of things. Having say, six versions of Visual Studio installed, you may even need to institute special practices where you run environment setup shell scripts as part of your build automation.

[NathanTheGr8]

I agree that this probably wasn't the best place to post my question but like I said after trying multiple ways of phrasing my question this was the top result and the thread was active just 2 days ago so I figure, hey why not. I have opened an issue with the nuget gallery site and will see if they can update the guide to be more detailed. I hope you understand how your comment could be seen as rude and take care to be more friendly to newcomers in the future, because we all have to start somewhere.

[marcosbrigante]

Trying to add something, I ended up in this thread trying to make my build machine auto restore nuget packages for a VS2015 solution. We used to depend heavily on "enable nuget package restore" and "auto download nuget.exe if missing" features, but it does not exists anymore as we can read here:

https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore#migrating-to-automatic-restore

On the section "Command-line restore" it says:

c:\proj\app> nuget.exe restore app.sln

But I could not find nuget.exe on my machine, just the VSIX, and it made no sense to me, I supposed it was installed somewhere as part of Nuget.

An installer would be very useful to ensure same experience and controlling version in all machines (dev and build).

NOTE: Really trying not to rant on IDE dependency here.

[CADbloke]

For something that is supposed to make things easier and more straightforward, the first stage of using it is anything but. An installer would make the experience consistent, not just for people with multiple machines but for, oh I dunno, the whole world.

For an example of something that is really smooth and seamless - https://github.com/Microsoft/Git-Credential-Manager-for-Windows. Not so seamless ...

if not exist C:\Codez\nuget.exe (
echo No Nugets at C:\Codez\nuget.exe - getting it from https://www.nuget.org/downloads
bitsadmin.exe /transfer "Nuget" https://dist.nuget.org/win-x86-commandline/latest/nuget.exe C:\Codez\nuget.exe
echo Nuget installed at C:\Codez\nuget.exe )