Project-system: Support reloading targets/settings/props in legacy project system

[tmeschter]

Related to 490432.

Currently, once an imported targets/settings/props/project file has been loaded by the legacy project system it will never be reloaded, even if it changes on disk. In the past imports generally came from MSBuild, VS, or the framework itself, and those would never change. A user could certainly create their own .targets project (or .props, etc.) and import it into their project, but this was rare enough that there wasn't a need to support editing that file while the project was open.

Now, however, NuGet generates *.nuget.g.props files under the obj directory to pull in the props/settings/etc. included in the packages. This generated file could change every time a package is added, removed, or updated. This can lead to weird or inconsistent behavior of various forms in the IDE until the solution is closed and re-opened, with no way for the user to know what has gone wrong.

We should support reloading these targets when we see them change on disk.

[davkean]

This is a non-trivial feature that will eat into time to get UWP over to the new project system. We'd previously scoped out from every doing this.

[Pilchie]

Moving to 15.7, as we're out of time to do this for 15.6

[Pilchie]

Moving to 15.8 - we have a prototype implementation, but the risk of introducing new UI delays is to great to take this late in 15.7.

[Pilchie]

Also reported at :link: https://developercommunity.visualstudio.com/content/problem/248037/defaultbuildprops-with-langversion-is-not-used-by.html - for Directory.build.props in that case.

[davkean]

@tmeschter We reload NuGet props/targets now in 15.8, right? We should leave this to tracking reloading other sorts of targets, in which case, this milestone looks incorrect.

[tmeschter]

That's correct; support for reloading the .props and .targets created by NuGet is in 15.8. Extending that to Directory.build.props/Directory.build.targets wouldn't be too hard.

[tmeschter]

Tom's triage notes: recommend we do nothing for this and close the issue.

[j3parker]

So this bug won’t be fixed? Where I work we have a workaround where we delete everyone’s .vs folders every time we change Dirctory.build.targets (which is pretty frequent, we use that to define common constants etc. ) which is pretty annoying for our developers

[j3parker]

Oh, this is only for the legacy project system. So it’s not a problem in the new one? We’re in the process of migrating now.

[tmeschter]

@j3parker I believe the new project system will automatically reload Directory.Build.props/.targets files that are next to a project file or in a subdirectory, but not those "above" the project in the file system (e.g. next to the solution). However, at this point we're much more likely to address that limitation of the new system than we are to make any changes in the old one.

[davkean]

Slight clarification, the new project-system will hot reload any targets file in the graph of the project. I use it all the time, we change this file https://github.com/dotnet/project-system/blob/master/build/Packages.targets which contains all the package versions across the solution and every project automatically picks it up while VS is open.

[tmeschter]

We have decided to _not_ implement this feature request for the legacy project system. Closing.

[j3parker]

Cool, thank you! Great news RE: the new project system. It totally makes sense to me that this wouldn't be fixed in the legacy one.