Enable Package Restore - Selective Projects

Dec 28, 2011 at 9:09 PM

Enable Package Restore is a great feature. One enhancement I would like though is if it would only update those projects that actually use NuGet. Or alternatively allow me to select which project(s) I want package restore enabled for.

 

In my current solution I have 37 projects, only a couple of which use NuGet. I was thinking that only they would get updated. It took a little bit of time to undo pending changes on the project files for the other 35 projects.

Dec 28, 2011 at 9:33 PM

Yes, I agree. It's a bit annoying to have it modify every project one only one or two need it.

I'd say it should just update projects that use NuGet, without any UI (which is more painful to implement). If you later start using NuGet in other projects (or add new projects), you can always rerun it.

Dec 28, 2011 at 9:34 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Dec 29, 2011 at 7:07 AM

This is another area that would benefit from a setting in a project property pane IMHO.

Dec 30, 2011 at 5:24 PM

Sounds like a good idea to me. If it was not set then maybe it could only update the projects that use nuget, otherwise a true/false value could take precedence.

Dec 31, 2011 at 2:01 AM

I'd rather not add settings for things like that, or we'll soon have 100 of them. I think we should just change the behavior to only affect projects that use NuGet, and not make that configurable. Not everything needs to be a config switch :)

Dec 31, 2011 at 6:33 PM

Why is this a concern? If a project does not have any package installed, the pre-build action is almost a no-op.

This change if done would be a breaking change from 1.6. People would not expect to re-run the "Enable Package Restore" command every time they install packages into a new project.

With the current behavior, they only need to enable it once and forget about it. IMO, the convenience far outweighs the added pre-build action to other projects. You can still undo the changes if you don't like.

@thnk2wn: I like to know why it takes you "a little bit of time" to undo the changes? All you need to do is select all those projects and select "Undo pending changes". Shouldn't take more than 15 seconds.

Dec 31, 2011 at 7:15 PM

You did bring up an important point. When I add new projects to my solution, I will need to call enable package restore for them. Could be something people may not see if the other projects use the same packages and build before. So it might make for some perplexing scenarios due to the nature of it not not always breaking in every project. Perhaps we should include this in the documentation if we don't already have a note.

Dec 31, 2011 at 8:22 PM

@ferventcoder: yes, that's exactly why the current feature is broken. It's not a 'turn on once and never worry about it' thing, as you still need to rerun it for new projects.

I think this can be improved in two phases:

  1. The change mentioned above, to only affect the projects that use NuGet. That removes the short term churn issue.
  2. In addition to that, we could later preserve a solution level flag that tells NuGet to automatically turn the feature on for any project that goes from not using NuGet to using it. This would nicely cover both the existing and the new project case.

#2 is the ideal solution, though it's debatable whether the dev cost is justified, given everything else it's competing against.

Dec 31, 2011 at 8:39 PM

No, the current feature is NOT broken. When you add a new project to a solution that has enabled package restore, AND if the NuGet extension has been loaded by VS, NuGet will automatically inject the pre-build event into the new project. Try it :)

Dec 31, 2011 at 8:41 PM

@dotnetjunky - it's not the end of the world to me if this feature adds a couple lines to each project file even if many don't need it. However it is an annoyance as it is additional changes that have to be checked out (possible dialog prompts), get merged (project files often generate merge conflicts w/TFS) or rolled back. It wasn't a great deal of time to undo but maybe a minute or two as project files are scattered across solution and physical folders and there were a lot of them; also there were existing pending changes, some to project files, so some analysis on which project files to undo checkout on.

 

Additionally we have one project (company common library) that resides outside the project / app root, rather than it being branched to all the apps that need it (not a good practice IMHO but the way it is). It is a bit problematic because nuget will add a path to the common library project that refers to a specific app path using it. The next app using the library that enables the feature will change it.

Dec 31, 2011 at 9:50 PM

@dotnetjunky: ah, I didn't know it did that. I just tried it, and while it does work, it's not very reliable because it needs nuget to be loaded. That misses a very common scenario: you launch your solution from the shell and add a new project to it. When I did that, it didn't work since nuget wasn't loaded. And at that point I think the option to Enable Restore was gone, so that project was pretty hosed.

The alternate solution I suggest above fixes both issues:

  • You never pollute projects that don't need it. And I agree with @thnk2wn that it's painful to hand clean when you're not super familiar with the feature.
  • When a project is transitioned from not using NuGet to using it, by definition NuGet is loaded, so it should work very reliably.

But let's keep things in perspective: none of this is a huge issue, and there are certainly many things that come before fixing that :)

Dec 31, 2011 at 11:37 PM
davidebbo wrote:

@dotnetjunky: ah, I didn't know it did that. I just tried it, and while it does work, it's not very reliable because it needs nuget to be loaded. That misses a very common scenario: you launch your solution from the shell and add a new project to it. When I did that, it didn't work since nuget wasn't loaded. And at that point I think the option to Enable Restore was gone, so that project was pretty hosed.

While it's true that there's nothing nuget can do if it is not loaded, the moment it is loaded, however, it automatically scans the current solution and adds the pre-build action to all new projects.

Try this:

  1. Launch your solution from the shell and add new project to it. At this time, nuget is not loaded, so the  new project is not enabled.
  2. Now perform any action that will cause nuget to load, for example, install a package to the new project.

At this time, when nuget is loaded and BEFORE the package is installed, nuget adds the pre-build action to the new project.

I believe that will cover 95% of the cases that customers need.

Jan 1, 2012 at 12:13 AM

Yes, that works! So at least we don't have that correctness issue. That leaves the original issue, which the alternate proposal would address. But given the way the current feature works, that would probably be a big change to address it. So maybe we can live with this for a while...

It's still an awesome feature to have the way it is now! :)

Jan 1, 2012 at 12:23 AM
Edited Jan 1, 2012 at 5:22 AM

Though thinking back about your previous comment that "You can still undo the changes if you don't like": won't NuGet end up re-adding everything the next time you open the solution? If so, people who are really trying to get rid of those unwanted entries might find that pretty annoying :)

Jan 1, 2012 at 4:11 AM
That's true :)

So instead of undoing the changes, we should advise people to manually change the EnablePackageRestore property to false.

Sent from my Super Windows Phone

From: davidebbo
Sent: 12/31/2011 5:23 PM
To: Luan Nguyen
Subject: Re: Enable Package Restore - Selective Projects [nuget:284405]

From: davidebbo

Though thinking back about your previous comment that "You can still undo the changes if you don't like": won't NuGet and up re-adding everything the next time you open the solution? If so, people who are really trying to get rid of those unwanted entries might find that pretty annoying :)

Jan 17, 2012 at 8:21 PM

David, I think I'm going to go ahead and implement your suggestion above, as part of my bug fix for #1846