Fully Qualify Install-Package command on website

[potatoqualitee]

Summary of the changes (in less than 80 characters):

• Install-Package exists in both Microsoft's NuGet module and PackageManagement module. This clarifies which Install-Package is expected, which helps PowerShell end-users
• Added a PowerShell tab to further clarify

Addresses #9201

[joelverhagen]

I have a hypothesis that most NuGet packages does not make good PowerShell packages. My understanding is that the structure and contents of the packages are quite different. NuGet packages are essentially DLLs compiled against or used for build/deploy of .NET projects. PowerShell packages are .ps1 or module files for a PowerShell session. It might give folks the wrong impression if we mention PackageManagement\Install-Package. Wouldn't this command be more appropriate on PowerShell Gallery (https://www.powershellgallery.com/).

[potatoqualitee]

The PowerShell community does indeed use nugets outside of Visual Studio. I use it enough to get frustrated with the fact that the command on the website doesn't work.

Steve Lee of the PS Team said

Installing arbitrary assemblies from http://nuget.org is something we want to support in PSGet v3.1 so after 3.0 is complete

Patrick Meinecke of the PowerShell team said

For now, I usually tell folks to build a binary module instead.
You can also build a csproj, add your dependencies, do dotnet publish and copy the dependencies out. It's not a great experience atm.

Another PS community member talks about how he handles nuget packages

A csproj file with PackageReference and a build.ps1 script to import the dependencies in the right location is still how I'm doing it. Not the best, but it works

So there is interest, and we do use it but it's not enjoyable (though as Steve mentioned, enhancements are coming soon). Ultimately, if there is a PowerShell tab, people like me will click it and it reenforces that the first tab isn't for us.

We use Install-Module on the PowerShell Gallery.

[joelverhagen]

Thanks for this additional context! I think we might be able to make quicker progress if we split this into two separate issues:

1. Make NuGet\ prefix on the command with a note on why. This seems like obvious goodness to me since it at least helps people know that there's two Install-Package commands floating around in the world.
2. Help PowerShell users know about how to use NuGet packages or, with that upcoming feature, use normal dependency NuGet packages (arbitrary DLLs) from PowerShell.

I'm concerned about item 2 because the vast majority of packages on NuGet.org don't work well with PowerShell's (or PSGet's) current feature set.

What do you think?

[potatoqualitee]

Sounds good. When the feature is released, do you think we could add the PowerShell tab?

[joelverhagen]

Sounds good. When the feature is released, do you think we could add the PowerShell tab?

I think it would be quite reasonable to add! We need to consider the full scenario, get some input from the PowerShell team, etc, but I see know reason why this isn't in a similar category as the Cake or Paket categories. Essentially, it's not specifically NuGet client tooling involved but it is a scenario that has NuGet packages (from NuGet.org) in mind.

[potatoqualitee]

Fantastic news! I'll keep it on their radar /cc @SteveL-MSFT

[joelverhagen]

@potatoqualitee, could you rebase this on dev branch? We merge all non-hotfix changes to dev first to allow it to reach our testing environment first as part of a CD (continuous deployment) flow.