Add --prerelease option to dotnet add package

[livarcocc]

From @yooakim at https://github.com/dotnet/cli/issues/5752

I'm not sure this is a bug but it would be nice if one could add NuGet packages with the -pre version as used by NuGet.

Steps to reproduce

dotnet add package Swashbuckle --version pre

Expected behavior

<Project Sdk="Microsoft.NET.Sdk.Web">                                                   
                                                                                        
  <PropertyGroup>                                                                       
    <TargetFramework>netcoreapp1.1</TargetFramework>                                    
  </PropertyGroup>                                                                      
                                                                                        
  <ItemGroup>                                                                           
    <Folder Include="wwwroot\" />                                                       
  </ItemGroup>                                                                          
                                                                                        
  <ItemGroup>                                                                           
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.0" />                 
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.1" />             
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.0" />   
    <PackageReference Include="Swashbuckle" Version="6.0.0-beta902" />                  
                                                                                        
  </ItemGroup>                                                                          
                                                                                        
</Project>                                                                              

Actual behavior

C:\Code\Coach\src\Coach.API [master]> dotnet add package Swashbuckle --version pre
Microsoft (R) Build Engine version 15.1.545.13942
Copyright (C) Microsoft Corporation. All rights reserved.

  Writing C:\Users\Joakim\AppData\Local\Temp\tmp2F1A.tmp
error: 'pre' is not a valid version string.

## Environment data
`dotnet --info` output:

[rohit21agrawal]

CC : @mishra14

[mishra14]

@livarcocc :

You can do dotnet add package newtonsoft.json -v 10.0.0-* to get the prerelease packages.

log -

log  : Installing Newtonsoft.Json 10.0.1-beta1.
info : Package 'newtonsoft.json' is compatible with all the specified frameworks in project 'E:\NuGet.Client\cli_test\cli_test.csproj'.
info : PackageReference for package 'newtonsoft.json' version '10.0.0-*' added to file 'E:\NuGet.Client\cli_test\cli_test.csproj'.

This will add -

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="newtonsoft.json">
      <Version>10.0.0-*</Version>
    </PackageReference>
  </ItemGroup>
</Project>

The --pre flag was not added because restore does not have an explicit way of request prerelease packages. Maybe @emgarten can chime in here?

[jacek-jaskolski]

@mishra14 I'm trying to dotnet add package rawrabbit -v 2.0.0-* and it gives me:

Please specify one package reference to add.
.NET Add Package reference Command

Adding <PackageReference Include="rawrabbit" Version="2.0.0-*"> to csproj file and restoring the packages works fine.

Using version 1.0.0-rc3-004530

[mishra14]

@jacek-jaskolski : We initially had a problem about placing -v param in the command after the package name. But that was fixed a while ago here: dotnet/cli@04a7fca.

Please try the latest dotnet cli and it should be fine.

[terrajobst]

At the very least the error message needs to change. This is the current experience:

$ dotnet add package Alexa.NET
Microsoft (R) Build Engine version 15.1.523.56541
Copyright (C) Microsoft Corporation. All rights reserved.

  Writing C:\Users\immol\AppData\Local\Temp\tmp9BFC.tmp
info : Adding PackageReference for package 'Alexa.NET' into project 'T:\Test\Test.csproj'.
log  : Restoring packages for T:\Test\Test.csproj...
info :   GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-corefxlab/nuget/v3/flatcontainer/alexa.net/index.json
info :   CACHE https://api.nuget.org/v3-flatcontainer/alexa.net/index.json
info :   GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/alexa.net/index.json
info :   NotFound https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-corefxlab/nuget/v3/flatcontainer/alexa.net/index.json 132ms
info :   NotFound https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/alexa.net/index.json 135ms
error: Unable to resolve 'Alexa.NET' for '.NETCoreApp,Version=v2.0'.
error: Package 'Alexa.NET' is incompatible with 'all' frameworks in project 'T:\Test\Test.csproj'.

The message implies that the package isn't compatible, not that it cannot be found. FWIW I'm not a fan of the -v <version> number as the sole way to install pre-release packages. The whole point of using the CLI to install the package is so that I don't have to look up the version number on NuGet org. I want to be able to quickly add a package in a sensible version (latest stable).

Ideally, this is how I would like the UX to be:

$ dotnet add package Foo
There are no stable packages for Foo. Consider specifying --pre to install the latest pre-release version.
$ dotnet add package Foo --pre
Installed package Foo 1.0.0-beta-5.

/cc @timheuer @bjorg

[timheuer]

@terrajobst is right. There are actually two things here. Bug: the error message is WRONG. Feature: add support for grabbing prerelease.

How can we at least fix the error message?

[billwert]

@richlander and I hit this last night as well. The experience must get better. I really like @terrajobst's suggestion of informing the user that no packages were found; I'd go a step further and only suggest --pre if pre-release packages exist. Otherwise just inform the user the package doesn't exist.

This sort of output is just frustrating:

error: Unable to resolve 'thiscantbeapackage' for '.NETCoreApp,Version=v2.0'.
error: Package 'thiscantbeapackage' is incompatible with 'all' frameworks in project 'whatever.csproj'.

[rrelyea]

We are doing some error/warning rework in nuget restore in our 4.3 release. If things go well, internal consumers of restore (like dotnet add package) could have better ability to understand those errors, beyond just passing along the log output.
/cc @mishra14

[rrelyea]

blocked by lack of 4.4.- support in versions right now.

[nietras]

What is the status of this? It's been several months, and this does not seem to have been added yet. I need this as well.

[terrajobst]

@rrelyea, what are your thoughts on making the cut for an upcoming release? It's probably too late for 2.1, but it's a high hitter in the UX. What's the next train this could catch?

[mishra14]

@terrajobst I have moved it to Priority 0 to reflect the request.

[terrajobst]

Thanks!

[nietras]

@mishra14 @terrajobst this issue is still open, has it not been resolved yet?

[arnotes]

still not working as of dotnet 3.1.4
Your.Package 0.41.7-pre.1 was not found

I can confirm this doesnt work even with the "-v 1.1.1-pre1.1" argument

[nkolev92]

@arnotes

The fix for this bug has not been released yet.

3.1.400 matches 5.7 of NuGet, but this was fixed in 5.0.100 of the SDK, matching 5.8 of NuGet and 16.8 of Visual Studio.