The project system monitors the project.assets.json file for changes, which usually occur due to a NuGet restore. When it changes we need to run a design-time build to acquire the updated set of references and pass them along to the language service. We also use these references to figure out what packages to show under the References node.
Consider what happens when the user creates a new project: the project is first created (from a template) in a temporary location and then moved to the final location. If the project systems asks for the location of the project.assets.json (captured in the ProjectLockFile property) file in between these two steps and we give it an absolute path then it will end up watching the wrong location for updates to the lock file. If the user then adds a PackageReference to the project (e.g. via the NuGet package management UI) we won't know to run the design-time build, won't pick up the new references, and won't pass them along to the language service.
The fix here is to make ProjectLockFile a path relative to the project file if we can. This relative path will still be valid after the move, and the project system already has logic to convert it to a full path when it needs to set up the file watcher.
Fixes VS bug 1163000.
The project system monitors the project.assets.json file for changes, which usually occur due to a NuGet restore. When it changes we need to run a design-time build to acquire the updated set of references and pass them along to the language service. We also use these references to figure out what packages to show under the References node.
Consider what happens when the user creates a new project: the project is first created (from a template) in a temporary location and then moved to the final location. If the project systems asks for the location of the project.assets.json (captured in the
ProjectLockFileproperty) file in between these two steps and we give it an absolute path then it will end up watching the wrong location for updates to the lock file. If the user then adds aPackageReferenceto the project (e.g. via the NuGet package management UI) we won't know to run the design-time build, won't pick up the new references, and won't pass them along to the language service.The fix here is to make
ProjectLockFilea path relative to the project file if we can. This relative path will still be valid after the move, and the project system already has logic to convert it to a full path when it needs to set up the file watcher.