This project is read-only.
33

Closed

Remove the "Enable NuGet Package Restore" context menu item

description

Now that NuGet package restore is handled outside of the MSBuild process, I believe we'd all be better off if the context menu item to "Enable NuGet Package Restore" was removed.

It currently leads to confusion amongst users. Perhaps a "Disable MSBuild-based NuGet Package Restore" menu item would be a better option (if the old package restore mechanism is detected).

Is there any reason to keep this context menu item?
Closed Aug 6, 2014 at 8:28 PM by danliu
verified using latest VSIX from master branch.

comments

JeffHandley wrote Feb 10, 2014 at 10:43 PM

I'd love to see if there are any arguments for keeping this feature. When we made the decision to abandon the MSBuild-based package restore, we decided to keep it around for a while until people are educated and choose to switch over. We wondered if there would be anyone who would choose to keep doing MSBuild-based restore.

I think it would be reasonable to remove the menu item from NuGet 3.0 though, assuming there is no outcry of desire for it to stick around.

davidebbo wrote Feb 10, 2014 at 11:02 PM

Kill it!

dmarsh wrote Feb 10, 2014 at 11:04 PM

Honestly we still use it because we also leverage the fact that the .targets file has the ability to create packages as well. Of course that's all very manual (have to add BuilPackage=true property to .csproj manually), but it works. There is no "great" alternative to this other than maybe Fowler's NuGet power tools, but that hasn't been updated in a while. Otherwise we'd have to roll our own which kinda sucks as I feel like this is the other side of the coin that NuGet itself should provide intrinsically.

I know that's not a great reason to keep it and I know the days are numbered that I can count on this, but just wanted to give you the feedback. :)

gregmac wrote Feb 10, 2014 at 11:13 PM

We use TeamCity (gasp! not TFS!) as a CI server, and so the MSBuild-based restore means there is no extra work to be done to get CI working: in simple cases, we just tell TeamCity to call msbuild on the .sln file, and in complex cases we have an MSBuild script that specifically invokes the <msbuild> task on the .sln file.

The documentation around the "automatic restore" (http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore) mentions absolutely nothing about how you'd do a package restore using anything besides Visual Studio. Maybe TFS does something automatic? I don't know, I've never used TFS.

So while not an argument to not remove this feature, I don't think it can be removed until at least the documentation explains how to restore packages in a (generic) continuous integration environment.

JeffHandley wrote Feb 10, 2014 at 11:45 PM

For TeamCity, they have updated their NuGet support to understand automatic package restore. I believe it's in TeamCity 8.1. With that, you should be able to commit a solution with its packages folder missing, and TeamCity would automatically restore the packages before calling msbuild.

The benefit this approach has is that packages that use msbuild imports themselves will work, whereas with the msbuild-based restore, that will fail.

Good point that we didn't document the TeamCity integration though.

akoeplinger wrote Feb 11, 2014 at 12:09 AM

+1 for removing the menu item, I've seen numerous people getting confused and enabling MSBuild based restore while automatic restore would be much better for them.

gregmac: If you can't upgrade to a TeamCity version that has built-in support for package restore just check in nuget.exe and call "nuget.exe restore" as the first build step, I'm using that and it works like a treat.

JeffHandley wrote Feb 11, 2014 at 2:22 AM

@akoeplinger Awesome, thanks.

Any chance you'd like to author a page on docs.nuget.org similar to this one, but for TeamCity?
Package Restore with Team Build

maartenba wrote Feb 11, 2014 at 6:57 AM

akoeplinger wrote Feb 11, 2014 at 1:58 PM

@JeffHandley: I could do that, but it would basically be the blog post @maartenba already mentioned ;-)

fritzjob18 wrote Feb 25, 2014 at 1:36 PM

Just wanted to throw it out there that I still use it the way that @dmarsh does, pretty much exactly the same way. That menu item does 90% of the work for me when integrating package creation into regular "F6" builds.

PhoenixHawk wrote Mar 7, 2014 at 7:15 AM

I'm strongly against removing this feature.

Here are the reasons:
1.) We want to be able to check out a repository and build the whole thing, including tests, with a single command.
2.) This needs to be done a virgin mashine with just the VS Build agent is a requirement. No VS, and no previous NuGet installation.
3.) The old way allowed to atomatically create packages from your build.

Now, one could argue argainst that:
1.) Simply call some batch file that downloads nuget.exe from somewhere, call it's restore and issue msbuild after that.

2.) One could write scripts that download nuget.exe from nuget.org before the build.

3.) Roll your own.

To those I answer:

1.) That is awful. MSBuild is THE tool for scripting the whole build process from end to end. Batch files aren't.

2.) It has happend, (and likely happen again) that nuget.org was down. Things fail. We would need to re-implement a lot of already existing and fine-working infrastructure for that.

3.) It's already perfectly there? Why would one need to rebuild such an intuitive and great solution and replace it with some sub optimal self-build solution?


Summary: The msbuild integrated automatic package restore is the perfect solution for the problem. The NuGet folks did great engineering when they built that. There is no need to remove this masterpiece of work with some other shit - sorry - that is a thousand times harder to get integrated in a fully functional fully automated build process with minimum requirements to it's environment.

The new way is extremely flawed, the old one is perfect. There is no need to change. I strongly object.

XavierDecoster wrote Mar 7, 2014 at 8:12 AM

A few comments in reply to @PhoenixHawk:
  • MSBuild is a tool which is great for the actual build step
  • A build server does more than building stuff, that's why most build servers work with "build steps" (of which MSBuild usually is only one step)
Given the strong feeling you express in your reply, do you:
  • checkout sources within MSBuild?
  • label your repository within MSBuild?
  • run unit tests from within MSBuild? (fairly sure you do that "after" the build)
    Just trying to point out that MSBuild is not the tool to script your entire Continuous Integration process in. Package restore is just another pre-msbuild step within that process and doesn't belong in MSBuild.
If your solution works perfect, by all means, continue to work that way.
But restoring packages within MSBuild is flawed as the msbuild targets being restored won't be picked up by msbuild until the next run.

I really hope to see more of these packages and eventually get rid of any SDK pre-requisites on my build server:
It's a great way to be explicit in defining dependencies, and have your build server just fetch what's need to do it's job.

PhoenixHawk wrote Mar 7, 2014 at 8:29 AM

Hi,

regarding your questions: Yes, yes and, well, yes.

For our full release process we have msbuild projects that:
  • check out the solution to release
  • update version information within it using info from the repo (svn revision as build number)
  • build the thing (with creating packages etc.) and runs unit, integration and UI tests
  • when that worked it deletes the folder just to restart:
  • it checks in the version update in the branch and creates a svn tag from it
  • it checks out the created tag
  • it builds that (again with tests etc)
  • it creates release notes from the checkin comments
  • it pushes the packages to our gallery
That is all a done by a single msbuild command. Reason is, that on those virgin build mashines we just can rely on OS + build agent (and mstest agent that comes with it). We're extremely strong advocates of automating our processes, and for building (and stuff directly related to building a release out of our sources IS our build) we use msbuild.

akoeplinger wrote Mar 7, 2014 at 9:36 AM

With such a large msbuild based process, why can't you just run "nuget.exe restore" too after checking out the solution from within your msbuild script?

Remember that this work item is not about removing the actual msbuild-based restore, but to remove the context menu in VS and make it a little harder for users to pick the wrong one (in my opinion for 95% of the users the automatic restore is much better). You can still use the msbuild-based restore as you do today if you want.

XavierDecoster wrote Mar 7, 2014 at 9:44 AM

I'm totally with you on the idea behind your approach, just not convinced this all should be a single (MSBuild) process.

Sounds to me you know what you're doing, and if this works for you and everyone on your team: perfect!

All I'm saying is:
  • people are confused by the presence of the "Enable Package Restore" context menu-item and are tricked into believing they still need to enable it manually somehow. That's not the case!
  • far more people are not going to take the road of putting everything into a single msbuild process, so keeping the context menu-item around for those who know how to use MSBuild anyway is imho not a good enough reason to justify the confusion it creates with the other 99%
  • since the majority of people don't know (or want to know) about MSBuild, they shouldn't be tricked into a restore option that is flawed due to MSBuild <-- these people will curse you for doing that and get stuck when the issue occurs, unless they migrate away from the MSBuild-restore option. So why not guide them into the "pit of success" in the first place?
That's why imho the non-MSBuild approach for NuGet package restore is the preferable default (and those who want to go MSBuild can do that, but the option should not be exposed nor part of NuGet).

Note: I'm not saying the NuGet.Build packages (and related) should disappear! You (MSBuild people) will need those :)

maartenba wrote Mar 7, 2014 at 9:57 AM

For everyone who needs it still, I would say let's revamp the PackageRestore package to support the "explicit" restore scenario? Everyone happy but the confusing menu entry would be gone at least.

fritzjob18 wrote Mar 7, 2014 at 3:31 PM

For those of us only attached to this for the "BuildPackage" target, not the restore target, perhaps we could make a separate, not installed by default, Visual Studio extension that would add "Enable Package Build" to our menus.

It could work just like the current extension except it would add <BuildPackage>true</BuildPackage> instead of RestorePackages.

maartenba wrote Mar 7, 2014 at 4:10 PM

Both options were part of the PackageRestore package, I still think it is relevant to keep an updated version of it around.

terje2000 wrote Jun 14, 2014 at 11:09 PM

I have released a utility to "Disable "Old" Nuget Restore", so that you get your project to support the new automatic restore.
The tool can be downloaded from http://visualstudiogallery.msdn.microsoft.com/b8ba97b0-bb89-4c21-a1e2-53ef335fd9cb
I have a blog post up here with details about it : http://geekswithblogs.net/terje/archive/2014/06/11/converting-projects-to-use-automatic-nuget-restore.aspx

The source code is here https://github.com/osiristerje/IFix, where you also can post issues. The source code is pretty brute force, but feel free to incorporate it whereever you like ( for example, a "Disable Old Nuget Restore" or "Enable New Automatic restore". It fixes up all four issues you have to do in order to restore a solution (or a set of solutions) back to the new automatic restore.

The command line tool cleans up all solutions, csproj's, nuget.targets files and deletes also all nuget.exe placed at the same place. It also moves all nuget sources (if any) from the nuget target file over to the nuget.config file.

JeffHandley wrote Jun 26, 2014 at 10:25 PM

Fixed with b598d6a3757f8d88a429ec1ecb37d09c994d927e

XavierDecoster wrote Jul 2, 2014 at 10:58 AM

Awesome! This just made my day :-)