Reference latest version of nuget package using PackageReference msbuild tag

[TFTomSun]

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):

NuGet version (x.x.x.xxx):
4.5.0.4685

dotnet.exe --version (if appropriate):

VS version (if appropriate):
15.5.7

OS version (i.e. win10 v1607 (14393.321)):
Windows 10.0.16299 Build 16299

Worked before? If so, with which NuGet version:

Detailed repro steps so we can see the same problem

I would like to automatically reference the latest available nuget packages with csproj files using the new PackageReference tag.
I tried:

<PackageReference Include="Selenium.WebDriver" Version="*" />
<PackageReference Include="Selenium.WebDriver" Version="Highest" />
<PackageReference Include="Selenium.WebDriver" Version="latest" />

However none of the above lines work as expected:

• Restore the latest version
• build against the latest version

Is there any way to force nuget to always take the latest available version of a nuget package?

[nkolev92]

The way NuGet floating versions are implemented, * will resolve to the latest stable version.

I assume in your scenario you're asking for the latest prerelease?

If that's the case, then this is a duplicate of #912

[TFTomSun]

Well, then there must be a bug. When I use the wildcard in the version attribute and try to reference the Selenium.WebDriver package it falls back to version 2.2.0 (the oldest package version), the latest stable version is 3.10.0. Any ideas why this happens?

Here's my csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <None Remove="Resources\chromedriver.exe" />
	
    <PackageReference Include="Selenium.Support" Version="*"/>
    <PackageReference Include="Selenium.WebDriver" Version="*"/>
    <PackageReference Include="TomSun.NetStandard.Extensions" Version="*" />
  </ItemGroup>

  <ItemGroup>
    <EmbeddedResource Include="Resources\chromedriver.exe" />
  </ItemGroup>

</Project>

[nkolev92]

@TFTomSun

I just attempted your repo and it resolves to 3.11.0 for me.

My csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>	
    <PackageReference Include="Selenium.Support" Version="*"/>
    <PackageReference Include="Selenium.WebDriver" Version="*"/>
    <PackageReference Include="TomSun.NetStandard.Extensions" Version="*" />
  </ItemGroup>

</Project>

Snippet from my assets file:

      "Newtonsoft.Json/10.0.3": {
        "type": "package",
        "dependencies": {
          "Microsoft.CSharp": "4.3.0",
          "NETStandard.Library": "1.6.1",
          "System.ComponentModel.TypeConverter": "4.3.0",
          "System.Runtime.Serialization.Formatters": "4.3.0",
          "System.Runtime.Serialization.Primitives": "4.3.0",
          "System.Xml.XmlDocument": "4.3.0"
        },
        "compile": {
          "lib/netstandard1.3/Newtonsoft.Json.dll": {}
        },
        "runtime": {
          "lib/netstandard1.3/Newtonsoft.Json.dll": {}
        }
      },
      "Selenium.Support/3.11.0": {
        "type": "package",
        "dependencies": {
          "Selenium.WebDriver": "3.11.0"
        },
        "compile": {
          "lib/netstandard2.0/WebDriver.Support.dll": {}
        },
        "runtime": {
          "lib/netstandard2.0/WebDriver.Support.dll": {}
        }
      },
      "Selenium.WebDriver/3.11.0": {
        "type": "package",
        "dependencies": {
          "Newtonsoft.Json": "10.0.3"
        },
        "compile": {
          "lib/netstandard2.0/WebDriver.dll": {}
        },
        "runtime": {
          "lib/netstandard2.0/WebDriver.dll": {}
        }
      },

What's the version of NuGet that you're using?
I used 4.6/15.6 Visual Studio in this case.

I'm not aware of any bugs regarding the above in area.

What are your sources?

Can you please post the full log here.

[nickrandolph]

It's still possible to reproduce this using Xamarin Android, Xamarin iOS or UWP projects: set packagereference to *, clean everything (delete bin/obj). VS/NuGet fails to retrieve the latest packages.
I've just tried this in the latest VS preview

[nkolev92]

@nickrandolph

Can you provide a repro project?

I just tried that in the UWP project and it resolved just fine (those same packages listed above).

If you have a repro, please attack your assets file as well.

[nickrandolph]

Try Android/iOS projects - they definitely seem to fail. Make sure you do a clean, remove any packages folders etc, and then attempt to build.

[nkolev92]

@nickrandolph
No luck.
There should be nothing special in the resolution logic in NuGet there.
NuGet just treats * as a * regardless of the project type.
Only case where things would be different would be duplicate references or targets updating the package version, which is out of NuGet's control.

[TFTomSun]

@nkolev92
The problem still persists. I have a very simple easy to reproduce scenario:

• create a package with Version 1.0.0 based on a folder incl. some target file that prints out a (hardcoded) version string and push it to artifactory

• install the package in project and replace the version with Version="*"

• change the version string in the target

• recreate the package with Version 1.0.1

• perform a rebuild on the project
  -> BUG: the package doesn't get updated -> Still the old version is displayed during build

• when i go to the package manager of visual studio I can see the available update. When I update via package manager, the new package is used, but my Version="*" will be replaced with "1.0.1" ... and thats not what I want.

Can I somehow force an update of packages at the beginning of the build?

Edit:
I can also reproduce the issue using the dotnet cli:

• dotnet restore
• dotnet build
• change and upload package with new version
• dotnet restore
• dotnet build
  --> Still the build output of the previous package

[nkolev92]

@TFTomSun
Running dotnet restore --force will reevaluate the restore graph.

NuGet caches part of the restore graph to avoid frequent network calls when using "*".

Related:

#6987
#5445

Potentially you could also be hitting the http cache (30 mins) during your restore runs. Opening the browse tab in the UI will defeat that http cache.

You can also read the old design spec here

[TFTomSun]

@nkolev92
thanks for the workaround. Since the nuget stuff is part of msbuild, is there a possibility to activate the force mode via an msbuild property? i could imagine to implement a little force logic that always forces the first time after i pushed a package from my own machine. That would be in my case the most natural and performant behavior.

especially the http cache is a problem since i can't really force a restore via rebuild in vs. .. right?

[nkolev92]

Yes, with MSBuild use /p:RestoreForce=true.
Rebuild in VS, currently does the spiritual commandline --force, but it won't invalidate the http cache.

Note that the VS experience is lacking and will likely change in the future (maybe an explicit option).

[TFTomSun]

@nkolev92 I have the same issue now with template installation and i didn't find anyway to force a restore of the template package. The template is installed via the:
dotnet new -i ....
command line. Is there any option to force a restore of the package here?

Edit:
even if i uninstall the template before reinstalling it, the newest available package is not restored.

[nkolev92]

When you create a template there are no nuget artifacts in place, so I'm not completely sure about your scenario.

Are the right sources configured in this scenario?
Did you try cleaning the http-cache before running the command?

[TFTomSun]

@nkolev92
How can i clean the http-cache?

My scenario is. I am currently developing a little tool that i deploy together with an template. I make changes to the tool, push the template incl. the tool assemblies and want to install the template again.
Unfortunately the latest pushed template is not used. I think its related to some caching.

[nkolev92]

To clean the http cache you can use the locals command.

https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-nuget-locals
https://docs.microsoft.com/en-us/nuget/tools/cli-ref-locals

Where do you push the template again?

Does it pick up the new template if you try installing it 30 minutes or more after pushing?

[TFTomSun]

thx. cleaning the http cache solved the issue