Why does this not behave as stated, or at least, how can I achieve the expected behavior?
When I do a "Save All" command (Ctrl+Shift+S), it is reasonable to expect my pending changes information to be saved to my workspace, but when Visual Studio crashes, it reverts to how it was the last time I exited Visual Studio gracefully (but with newly checked-out files included in the Pending Changes list).
This has caused me to lose my check-in notes and associated work items/etc. numerous times now.
To clarify, if I close Visual Studio normally, my check-in notes etc. are preserved for the next time I open VS, but if VS crashes they are not, therefore they are saved somewhere, thus the "Save All" command is not behaving as clearly stated by its name.
The problem here is that you need to distinguish between the state of your files and the state of the Visual Studio IDE.
"Save all" will only ever write the in-memory changes of the files down to the disk. It does not have anything to do with the check-in comments or linked work items. These are part of the state of the Visual Studio IDE. That state is only saved to disk when you close Visual Studio.
If Visual Studio crashes, its state is simply not persisted which is why you just loose the state, in your case the comment and associated work items.
Its the same with the size and position of the Visual Studio windows. If you move a window around and close Visual Studio the position of the window is saved. Next time you open it the position is restored.
This is particularly an issue if you have multiple instances of Visual Studio open. Closing an instance will overwrite the state that was persisted by closing another instance before that.
Unfortunately I'm not aware of any way to save the state of Visual Studio other than actually closing it. It's unfortunate but that's how it is.
Personally, I maintain a dedicated text file where I write my check-in comments and just paste those comments into Visual Studio before I do a check-in.
We do not use "Save All" to save unfinished work in TFS.
If you have work in progress that you cannot finish now so you want
a backup copy that is stored on your server and available to other
team members who might need to access it.
Or you just want to backup your code before leaving office at
evening.
Under both situation, you should use shelvesets to handle this.
You can move your pending changes to a shelveset on the server and
then clean your workspace. The shelveset saves and stores not only
your file revisions, but also the Comment, the list of Related Work
Items, and check-in notes (if you evaluate policies before shelving).
When you are going to resume to work, you could simply unshelve the shelvest, just make sure "Restore Work items and check-in notes" checked
Then you will not lose any check-in notes and associate work items even Visual Studio crashed. More details about the shelvest, please take a look at our official tutorial here: Suspend your work and manage your shelvesets
Update:
According to your supplementary , it's more related to Visual Studio's design of crash and recovery. Which seems not related to TFS part.
What we could do is using shelvest frequently to protect your data losing. After all, totally cash in visual studio won't happen very often. This will also help to make lose reduced.
Related
TFS creates a shelveset when you suspend work in Visual Studios 2017. When you then resume the suspended work TFS deletes the shelveset. Is there an option to preserve shelvesets on the server when unsuspecting work?
All active Work Items and currently Pending Changes are considered In Progress Work. If the Suspend button is clicked, system will shelves the code along with references to the active Work Items, currently open files, breakpoints, etc.
Basically, the current state of Visual Studio is saved for later recovery. Modified files will be reverted to the Latest Version.
Then when you select ‘Switch’ or ‘Resume’ and the suspended work would be recovered along with the previous state of Visual Studio. The code can then be checked in. The shelveset will be deleted automatically.
If ‘Switch’ is chosen, then the current work is suspended before the selected work set is restored. After check-in is complete, then the previous work [for instance, 2 edit(s)] can be ‘Resumed’.
There is not any option to preserve shelvesets on the server when unsuspecting work. As a workaround you could first shelve your pending changes and work first, make sure check preserve pending changes locally, then suspend your work.
There will a shelveset which contain your previous work and record in server side.
I am getting an inconsistent error with Visual Studio 2015 that is severely hampering my productivity.
I am working on a very large application that I have pulled down from TFS. Sometimes when working I will try and save the file that I was working on, and have the asterix not go away and the file not save. This is despite running the application in Administrator.
Sometimes the solution is simply to rebuild the project and then try to save, however when this doesn't work I need close down visual studio and start up again, losing all my saves anyways.
This isn't too bad when I am working on .net files because the problem happens a lot less, and the solution is almost always to just rebuild, which is much better than having to re boot vs. However recently I have been working on javascript files within visual studio, and with them I get about one save, then the problems comes up, and rebuilding doesn't fix issue, causing me to have to reboot visual studio every save I make...
I have tried searching online for people who have faced a similar issue, or asked around my work, and no one seems to have ever had a similar problem. So hopefully, for my sanity's sake, someone knows what the heck is going on with my visual studio. Thanks!
I am currently running VS2019 16.7.2 and sometimes it just refuses to save no matter what I do. I try Ctrl + S, File -> "Save all", closing the window (which causes the changes to be lost) but nothing works.
Though for some reason when first I press the File -> "Save ... as" option in the menu and then cancel it, that releases the "save lock" and suddenly I am able to save again. Not really a satisfactory solution but at least all changes aren't lost. Maybe it will work on other versions as well?
I will give an answer to a problem which might not be exactly the same as the one reported by the author, but it is fairly close, and people searching for a solution to this problem are likely to arrive to this question.
In my case, in my entire solution containing thousands of files, there was only one particular file that Visual Studio was consistently failing to save when needed. As a result, after each commit, the "Git Changes" tab would not appear completely empty. All files would be committed, except this one file, which would appear as still uncommitted. So, I would have to manually save it and then amend the last commit in order to arrive at a completely empty "Git Changes" tab.
I thought that the problem might be due to some discrepancy between the letter case of the filename on disk (which is what the "Git Changes" view reports) and the letter case of the filename in the visual studio project file (which is what the "Solution Explorer" view reports) but it turns out that this was not it.
After much troubleshooting, I discovered that the following sequence of magical incantations solves the problem, I have no idea why:
In "Solution Explorer" locate the problematic file.
Rename the problematic file to something else.
Commit (with amend if you wish) the file.
Rename the file back to its original name.
Commit (with amend) the file again.
Restart Visual Studio.
The last step of restarting Visual studio is not strictly speaking necessary, but it is useful in case you have a letter case mismatch, because Visual Studio seems to be somehow caching filenames, (or at any rate not detecting that the capitalization of a filename has changed,) and restarting it makes it come to its senses.
I realize this is an old question but I had a similar problem with a solution file I had upgraded from Visual Studio 2015 to Visual Studio 2022. I was unable to save any changes to the solution, although the file was writable in notepad.
Deleting the section in the solution file as suggested by Richard Stanton's workaround fixed it for me!
developercommunity.visualstudio.com Workaround
Delete the following section from the solution file:
ProjectSection(FolderStartupServices) = postProject
{B4F97281-0DBD-4835-9ED8-7DFB966E87FF} = {B4F97281-0DBD-4835-9ED8-7DFB966E87FF}
EndProjectSection
I've been through all the Visual Studio Source Control documentation and so on but I can't find an answer as to whether it's safe to keep working in Visual Studio whilst it's doing a check-in?
We're using Visual Studio 2015 with Visual Studio Team Services source control.
Sometimes there's one or more files (like video files) that take a while to check in, sometimes an hour or more. I'm worried that if I keep working (specially if I work on the same files that are busy checking in) it'll corrupt the process.
Normally, it is safe as TFS won't check the changes again after you click check-in button. It just check in the changes you made before click check-in. So edit the file does not affect the check in process.
But in some case, for exmaple, the internet access is disconnected during check-in, then you click "Refresh" button to reconnect to TFS service. The changes will be refreshed too. That means the changes you made during checking is been included now. And there isn't any way to restore to the version that you'd like to check in.
So, you'd better avoid this as possible as you can and check in large files when you are not working with them.
I was just doing a find & replace in my project and unintentionally replaced some things in the Windows MFC header afxwin.h.
Visual Studio showed a star on the tab name, i.e. afxwin.h*, indicating that it had in fact been modified (side question: why are these headers not read-only?). I closed out of Visual Studio with afxwin.h* showing and it did not ask me if I wanted to save the changes or not. I went to the disk location for the header file and saw the changes had been committed without prompt.
Is this really the intended functionality? I get notifications whenever I close out of Visual Studio if there are uncommitted changes; why not for this? Now I'm a little worried that it's going to save things on exit without my choice in the matter.
Is there a way to tell Visual Studio 2005 to just ignore source control binding when opening a solution? I sometimes need to load a solution for which I don't have access to the source control server, but Visual Studio insists on trying to connect anyway, meaning I have to click "temporarily work offline in disconnected mode" for every project in the solution (of which there are about 20) as it loads. For some reason, it also tries to check each project out immediately after I've told it to work offline, so I have to click past that dialog box too.
As I will never need to edit anything in this solution, is there any way I can open it and have Visual Studio just ignore the fact it has source control bindings in it?
Edit: Ideally, I'd like a way to do this without having to change the project/solution files. They change fairly frequently, so I'd have to redo any changes every time there was a new version (otherwise I'd just unbind them once and it wouldn't be a problem).
Thanks for the replies so far.
The source control bindings are stored in Visual Studio solution file (.sln). For TFS for example, it contains a global section for TFS information and the solution projects added to TFS. You can edit the solution file to remove these bindings manually. I would suggest making a copy of the solution file first. However, I would recommend removing bindins via Visual Studio. Open your solution and go through the offline scenario. Then go to File/Source Control/Change Source Control (VS 2008) to bring up the UI that shows you the source control bindings in your solution. There you can manage the bindings including unbinding them. Once unbound, the next time you open the solution, VS should not have a need to access the source control.
I've been looking for a way to disable Integration between SourceSafe 2005 and Visual Studio 2008. We are forced to use SourceSafe being in a corporate environment and all. SourceSafe is fine on its own if you treat it like a baby. As soon as you try to do anything approaching useful it starts to break. God forbid you try to use the integration with Visual Studio. Being that I didn't want the "Bindings removed" so that it doesn't confuse other devs on the team I needed to be able to tell Studio to ignore the solution and project bindings and continue on it's merry way.
I followed the registry hack suggested in the following post
Removing SourceSafe Integration from Visual Studio 6
Studio did what I wanted...sort of. It removed the SourceSafe integration. However when I opened up a source controlled solution it asked me if I wanted to remove the bindings.
"the projects will be treated as not under source control"
No I don't want you to remove the bindings from the files, I want you to IGNORE them. This dialog pops up every time you open the solution/project file and there is no way around it.
My solution at the moment seems to have worked...for now.
File->Source Control->Change Source Control...->Disconnect
I hope this helps anyone else in the position of having to use SourceSafe but can't remove the bindings from the files themselves. WHY, Microsoft, WHY would you put the bindings in the files themselves?
/rant