Home: 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: https://github.com/dotnet/cli/commit/04a7fca9fc5512e738cd9386e129f09a2235a55f.

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?

[mishra14]

This is blocked by https://github.com/NuGet/Home/issues/912.

[shanselman]

O_O

[CrossBound]

2 1/2 years later and I'm still getting this message.... any update??

[terrajobst]

@mishra14

This is blocked by #912.

Why is this blocked by floating versions? This has nothing to do with floating versions that are persisted. It's only about the dotnet add package UX. Considering the age of this issue, can we please get a scoped proposal into shape?

[MuiBienCarlota]

And why this evolution need is a nuget issue? it is only a need for evolution that concerns dotnet cli.
I think the right place for this evolution is https://github.com/dotnet/cli/issues/7043

[TomasHubelbauer]

I don't suppose this will make .NET Core 3? It's really unfortunate that this is still a thing, for CLI users it means we now have to install NuGet separately just to install a pre-release package.

[TomasHubelbauer]

Although I just realized one thing which might help others looking at this issue: You can use dotnet add package to install the latest stable version, then replace the version string in the CSPROJ manually and then run dotnet restore to install the pre-release version. Works well enough for my use-case, just got to keep that in mind.

[svick]

@TomasHubelbauer You can also use the -v option of dotnet add package to install a specific preview version of a package.

[m2nlight]

Dotnet (3.0-rc1) add package command doesn't support --prerelease and --configfile flags.

The --version 3.0.0-* cannot add some prerelease packages.

I have to give up. I search packages from nuget.org and copy PackageReference to .csproj file, manually. And edit the version to I want (v3.0.0-*). Then run dotnet restore.

[nietras]

@svick do you know of any possibility of querying for the latest pre-release version via some command e.g. nuget.exe or something? And then add the package using the -v option.

@mishra14 no answer was ever given for

Why is this blocked by floating versions? This has nothing to do with floating versions that are persisted. It's only about the dotnet add package UX. Considering the age of this issue, can we please get a scoped proposal into shape?

should it not be simple to support something like:

dotnet add package Swashbuckle --include-prerelease

which simply takes the latest release incl. prereleases? Without any version stuff. Most of us simply want the latest version of a package added incl. prerelease versions. Note that this is similar to the current command:

dotnet list package --outdated --include-prerelease

if we can list it, we can add it I would hope. :)

cc: @livarcocc this issue is going nowhere, what can we do to get this done?

[svick]

@nietras I don't know about anything like that. I do think it would be nice if there was a command-line tool for accessing the NuGet API.

[krwq]

Joining the request: It would make it much easier for us to write dogfooding instructions if we had this switch. Currently we need to ask people to install specific version which for private feeds is essentially asking people to install nuget package explorer or use VS directly. We've already had several people creating issues because we do not have a good way to communicate how to reference latest preview.

[AlexanderJohnston]

This makes Blazor development particularly difficult as I have to spend a lot of time manually updating the prerelease versions of packages across a large solution.

Package Management Console makes this reasonable to do thanks to Get-Package -ProjectName $value | Update-Package -IncludePrerelease.

But there are times when I do not have access to VS2019 and I must use VSCode. In those circumstances it is a huge pain to update packages.

I've been hoping for this feature to be added for over 2 years now and wanted to voice my support for it.

[terrajobst]

Bump. This is a serious adoption blocker for library authors who want feedback on their preview APIs. We're wasting considerable amount of time working with people giving us feedback on the wrong version 😢

[karann-msft]

We are doing some of the foundational work to support pre-release versions for the floating version scenario. That will help us make progress on this as well. We are targeting to roll it out during the .NET 5 timeframe.

[terrajobst]

Thanks @karann-msft!

[MuiBienCarlota]

This issue has been waiting for almost 3 years now.
As --pre function is not blocked by the floating version scenario, it should not wait for .Net 5. timeframe.

[terrajobst]

As --pre function is not blocked by the floating version scenario, it should not wait for .Net 5. timeframe.

.NET 5 is the next release after .NET Core 3.1 (slotted for Nov 2020), so that's the next vehicle for major changes.

[nkolev92]

Implementation comment for whoever ends up handling this issue:

• Using restore as the underlying component of add package is certainly the right thing when the package version is specified, or when a specific floating version range is specified. For example *, it allows us to write * in the project file, so the customer will automatically get the updates.

• Using restore when the version is not provided is incorrect. Restore by design includes unlisted versions. This leads to #7466 where unlisted packages are installed when someone runs dotnet add package packageId. Instead we should use the metadata resource https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Protocol/Resources/MetadataResource.cs, which can account for unlisted packages. Furthermore this makes the work in this not blocked on the *-* implementation in #912

[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.