Better handling of restore in VS with floating versions

[clairernovotny]

Right now if a solution has any projects with floating versions, the NuGet restore process happens on every build. This is a huge annoyance as it greatly slows down the build process.

Instead, I propose the following logic:

1. A Rebuild should always run restore and check for new versions
2. Build/F5/Clean-Build should not check for new versions. The thing to keep in mind is that versions don't usually change that often. Adding the following options to VS should address when Build triggers a new version check

• First build after opening a solution (default: yes)
• After switching solution/platform configuration (default: no -- unless absolutely required for correct functionality)
• Every build (default: no) - for people that really want it for CI, etc
• Every x hours (default: no) - not sure this is needed when a rebuild could have the same effect

[yishaigalatzer]

We always had support to turn off restore on build. And we added a restore context menu in 3.2.

This suggestion needs to go through a design discussion, before we decide what to implement. My concern is that building too many options in the UI is going to drive confusion rather than goodness.

There is a related ask to make the turning off restore on build to be a solution level setting rather than global. Again this needs to be included in the design.

Last we want to add support for restore on opening a solution (in the background), and restore on editing and saving project.json file.

Last #1275 tracks adding an API in visual studio to trigger restore for project.json scenarios.

CC // @Pilchie @jaredpar

[yishaigalatzer]

Looks like this is not going to make it to 3.3

[clairernovotny]

That's unfortunate. Can it be top of the list for 3.3.x or 3.4?

[yishaigalatzer]

I can't promise that. The list is super long and there is a reasonable work around for that today (turn off package restore and right click->Restore menu option is there)

[clairernovotny]

That workaround is really not acceptable. It's too easy for users to forget to hit restore on every solution. If the "off" setting were applicable to a single solution, then that's one thing. As it applies to VS all-up, it's not.

[yishaigalatzer]

I understand what you are saying, as someone that is using * dependencies every day on my project, I actually don't see it as a huge deficiency. I agree we should improve it, I just can't justify prioritizing it over basic failures, bad error messages when things go wrong and improving the basic UI.

That's why it falls lower in the list, when I say I can't commit, I mean I can't commit to when it happens. This doesn't say it won't happen, just not when it will.

I'm open to having an open discussion and agreed upon design, then make it a "will take contribution item" if you or someone else wants to make it happen faster.

[yishaigalatzer]

The behavior today hits the cache first, so the first 30 minutes actually shouldn't do any annoyance. Once every 30 minutes we will go live and check. That's why I don't see any major annoyance on my side.

[clairernovotny]

When you say "hits the cache first", what do you mean by that?

There are two issues I'm trying to avoid:

1. Breaking incremental rebuilds. If I just built and hit debug without any code changes, I don't want msbuild rebuilding everthing.
2. That dialog should be quick.

[yishaigalatzer]

We are caching the results of the http calls in memory, so within 30 minutes we are not going out to the internet, so you won't see any changes, which also means things are quick (disclaimer: quick for what I'm doing regularly which is: clone or open command line, force a restore, open vs and work).

[clairernovotny]

What version includes this cache? I've avoided * in my versions since discovering the cost.

[yishaigalatzer]

3.2.1-RC is what I’m working with (well I’m really using 3.3, but that’s not public yet, you will have to build it yourself)

Also note that we are spending lots of our time on further optimizations for restore (well at least all my dev time goes there), and you should see some improvements in 3.3, and more as we keep moving forward.

From: Oren Novotny [mailto:[email protected]]
Sent: Tuesday, October 20, 2015 4:09 PM
To: NuGet/Home [email protected]
Cc: Yishai Galatzer [email protected]
Subject: Re: [Home] Better handling of restore in VS with floating versions (#1256)

What version includes this cache? I've avoided * in my versions since discovering the cost.

—
Reply to this email directly or view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fNuGet%2fHome%2fissues%2f1256%23issuecomment-149727370&data=01%7c01%7cyigalatz%40microsoft.com%7c4b24869c6913480bcabc08d2d9a36b62%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NvO5EYYOtseG4Li%2fQoq5S0s%2f2TWVQvv1rBCTUvpvglY%3d.

[nkolev92]

Thanks for filing this issue.

Since it's been a while since this issue has been filed, a lot of details have changed.

NuGet restore now has a no-op implementation, which means Solution Restore Command and on build restore no-ops and does not update the floating version.

On rebuild the restore reevaluates floating versions.
In addition http caching has been implemented, which also affects the reevaluation if the cache has not been cleaned.

In #5602, we are reconsidering the floating version experience, so please comment there if you have any further feedback.