_From @dougbu on February 25, 2017 0:38_
Please read the following information before posting the issue.
NuGet product used: VS UI
Nuget Package Manager 4.0.0
dotnet.exe --version: 1.0.0-rc4-004883
VS version (if appropriate): 15.0.0+26222.1d15rel
OS version: Win10 v1607 (14393.696)
Worked before? Not positive but thing old package.config file was updated immediately.
xml
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.0.0" />
xml
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.0" />
xml
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.0.0" />
Please include verbose logs (NuGet.exe
Very helpful if you can zip a project and paste into this issue!
_Copied from original issue: NuGet/Home#4689_
_From @dougbu on February 25, 2017 2:33_
Not positive but thing old package.config file was updated immediately.
I am sure no similar problem existed when editing project.json files in Visual Studio 2015.
Save everything in Visual Studio
At step 9, Visual Studio and the NuGet Package Manager show no indication anything at all needs to be saved.
This behavior is actually by design, and matches all other manipulations to the project file, such as adding an assembly reference, project reference, source file, folder, etc. @dougbu Is there a reason that you expect the project to be saved in this case?
Is there a reason that you expect the project to be saved in this case?
I expect to be able to move back and forth between the command line and Visual Studio without these strange synchronization failures.
As it is, Visual Studio misleads users. The least I'd expect is an indication saving the project is necessary.
@emgarten said in the original issue
NuGet doesn't force a save here for perf reasons. With packages.config it was a much smaller file…
project.json files were actually larger than .csproj files, at least in the converted ASP.NET repos. Nonetheless, the experience has regressed with the move to smaller files.
It hasn't always been this with NuGet until it moved to PackageReference but every other feature in Visual Studio operates on an in-memory version of the project or source which isn't reflected on disk until the file is saved. Almost all Windows programs with a document model have this concept, for example, Word and Excel.
What kind of indication would you like? Maybe a * next to the project name in Solution Explorer? Would that suffice? In this case where the project is unsaved, we're also going to be putting a * in tab when you have the project file opened in the editor.
What kind of indication would you like?
Well, if I had the project file open, it would show a * in the tab. Suggest the NuGet Package Manager should behave similarly. It is after all another window into the project file.
Note however users get two very different behaviours when they choose to save dependencies in packages.config and the project file. How will that be reconciled?
Oops, meant to respond to this as well:
Almost all Windows programs with a document model have this concept, for example, Word and Excel.
All of those programs also provide a clear indication the in-memory copy is dirty.
I've filed a bug against the platform team here: https://devdiv.visualstudio.com/DevDiv/Managed%20Project%20System/_workitems?id=397504&fullScreen=false&_a=edit.
i have the same problem. nuget is not updating project references until i click "save all" button. your link is not valid or not accessible. what was the solution here?
There is an open feature request internally to show the dirty state in solution explorer, but you still need to save all files.
Any movement on this action? Not seeing any flag, and it creates hell when you are switching between branches in source control when you forget to do a save all.
@McGern How are you switching branches? VS should prompt you to switch if you use the in VS UI. Also, it has some performance optimizations based on the fact that it knows a branch switch is happening as opposed to just a bunch of files being changed on disk...
This is still an issue in Visual Studio 16.4.2 and the DevDiv link provided seems to be broken. Is there an update on this?
@collinprice that link is Microsoft internal unfortunately.
The change will not happen in this repo, so the best way to encourage action here is to file a ticket with Developer Community:
https://docs.microsoft.com/en-us/visualstudio/ide/suggest-a-feature?view=vs-2019
Once the ticket is created, link it back here so people who find this issue can vote and comment on your feedback ticket.
Thanks @drewnoakes. Posted to Developer Community.
@collinprice As per above the behavior you are seeing with Manage NuGet packages is by design per the document save model that inside Visual Studio. The internal bug that I opened was about adding an unsaved indicator to better indicate that the project file is unsaved.
I'm taking from the bug you filed that you would prefer that Visual Studio always saved the project? If so I'll turn it into actionable suggestion that folks can vote on - because the new one has the danger of being closed as _by design_.
@davkean Ahh that makes more sense. My team is in the process of upgrading our projects from package.config to PackageReference and this behaviour has only added to the confusion. Thanks for clarifying. If you could, please turn my post into an actionable suggestion.
Most helpful comment
I expect to be able to move back and forth between the command line and Visual Studio without these strange synchronization failures.
As it is, Visual Studio misleads users. The least I'd expect is an indication saving the project is necessary.
@emgarten said in the original issue
project.json files were actually larger than .csproj files, at least in the converted ASP.NET repos. Nonetheless, the experience has regressed with the move to smaller files.