Can we do Maven style snapshots?

[red8888]

Now that project.json is dead how can you emulate maven style snapshots?

I want to mark a package as a snapshot version so nuget/Visual Studio always downloads the most current version of that package.

[nkolev92]

NuGet already supports pre-release packages, which is kind of what snapshots are trying to achieve.

NuGet also has the concept of floating versions that allows you get the latest prerelease version of that said package.

What exactly are you trying to achieve here?
Please also refer to https://semver.org/#spec-item-9. Relying on a mix of stable/prerelease packages is generally not the best idea.

[red8888]

I want to mark a package as a snapshot version so nuget/Visual Studio always downloads the most current version of that package.

Like maven does it- this isn't a wierd use case.

Can the prerelease thing do that? I want to not have to modify the version number and have nuget always redownload the latest version- like maven snapshots

[nkolev92]

Even with maven, you still can't re-download the same version.
You need to purge the local repository of that version.

You can achieve a similar thing. The thing is that each package you release should have a unique identifier.
Then you can just float the prerelease version.
Example 1.0.0-rc.* would always get the latest RC (there's 30 min http caching as a perf optimization, but that can be bypassed).
Look at for example https://dotnet.myget.org/feed/nuget-build/package/nuget/NuGet.Frameworks, how we publish a package with each build.

Please refer to https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution and https://docs.microsoft.com/en-us/nuget/reference/package-versioning#version-ranges-and-wildcards for more info.

[red8888]

"--update-snapshots" correct me if im wrong but maven absolutely can and thats kind of the whole point!

Doing it your way means I still need to update the package reference right? Go into nuget package manager and install that version right? Maybe im missing something?

Maybe there is a VS extension or a build task that can selectively run "Update-Package –reinstall" on certain packages- by doing a string match for some identifying token in the version number or something?

[nkolev92]

@red8888
No you don't need to change the csproj.
You only need to change it when you start depending on an entirely different version.
You would just have 1.0.0-rc.* and then whenever you run some specific restores it will download the latest version .
Those specific restores are listed here.
Please note that with the future addition of repeatable builds those gestures may change.

[red8888]

Thanks for answering my questions. So to set that version like "1.0.0-rc.*" do I do that in packages.config or in PackageReference in csproj files? Our users are most familiar with nuget package manager though, is there a way to set a wildcard version from that GUI too?

Thanks again!

[nkolev92]

@red8888

Floating versions are only supported with PackageReferences in csproj.

packages.config is a rather old design at this point and we prefer if customers move towards PR whenever appropriate.

Floating versions docs

There's currently no UI handling for floating versions unfortunately.
#3788
#3101

Please note that updates/installs are way more performant and consistent in PackageReference that they don't need to be changed with the UI.

[PatoBeltran]

Closing as all the questions seem to be resolved, feel free to reopen or create a new issue if there are further related concerns.

[drdamour]

one of the nice things about snapshots is that if i maven publish a project with snapshot it gets pushed to my local maven repo, and then when i refresh dependencies over in another project it'll see that local snapshot and pull it in fairly quickly. This makes REPL on a dependency very easy...i'm wondering what the equivalent flow is for NuGet

[benlongo]

Having snapshot style managing would be very nice for local development of packages and the consumer of the package.

[nickhoeferpickpro]

Having snapshot style managing would be very nice for local development of packages and the consumer of the package.

Agreed! I have been spending the last couple days trying to figure this out. I did something like this to achieve a similar effect.
I borrowed the idea from @thesushil here #9891

	
<Target Name="DeleteLocalCache" BeforeTargets="Pack">
  <RemoveDir Directories="$(NugetPackageRoot)$(PackageId.ToLower())\$(version)" />
  <Message Text="Cleaning $(NugetPackageRoot)$(PackageId.ToLower())\$(version)" />
</Target>

<Target Name="UpdateLocalCache" AfterTargets="Pack">		
  <Message Text="creating diretory $(NugetPackageRoot)$(PackageId.ToLower())\$(version)" Importance="high" />
  <MakeDir Directories="$(NugetPackageRoot)$(PackageId.ToLower())\$(version)" />
  <Message Text="copying file $(PackageOutputPath)$(AssemblyName).$(version).nupkg" Importance="high" />
  <Copy SourceFiles="$(PackageOutputPath)$(AssemblyName).$(version).nupkg" DestinationFolder="$(NugetPackageRoot)$(PackageId.ToLower())\$(version)" />
		
  <Exec Command="tar -xf $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\$(AssemblyName).$(version).nupkg -C $(NugetPackageRoot)$(PackageId.ToLower())\$(version)" />
  <Exec Command="certutil -hashfile $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\$(AssemblyName).$(version).nupkg SHA512 &gt; $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\temp1.txt" />
  <Exec Command="more +1 $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\temp1.txt &gt; $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\temp2.txt " />
  <Exec Command="powershell Get-Content $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\temp2.txt -First 1 &gt; $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\$(AssemblyName).$(version).nupkg.sha512" />
  <Exec Command="del /f $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\temp1.txt" />
  <Exec Command="del /f $(NugetPackageRoot)$(PackageId.ToLower())\$(version)\temp2.txt" />
</Target>

If anyone knows a more elegant way to handle this, I'm all ears. Changing version numbers each time just for local development is just silly. semver is great and everything but we shouldn't be forced to adhere to it just for the sake of purity because doing so results in dirty hacks or workarounds.

[nickhoeferpickpro]

I think #6579 is related.

[derekm]

@red8888 -- I don't think these people have ever developed with Java or Maven, so they don't know what they're missing with how clunky nugets & multi-project solutions & cross-solution development are in C#/.NET!