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.
Related
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.
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
My computer recently froze while debugging a project (on Visual Studio 2017).
No data was lost (because everything is saved and compiled before debug anyway), but now every time I open the project the Visual Studio environment looks like it did on the day it froze. The most recent session state is never saved, so I have to manually find and reopen all the pages I was just working on.
No data is lost and my work is still progressing as normal. It's just mildly annoying having to do this every time.
I presume there's a file somewhere that needs deleting. Not sure which one to safely remove though.
Thanks.
Found the answer here: visual studio not remembering open documents & startup project
Deleted .csproj.user file and everything in the .vs/[projectName]/v15 folder. It may be a hidden folder so be sure to tell your File Explorer to show hidden files.
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.
My visual studio 2010 crashed when some carelessness [bit of madness] mistakenly pressed start button and my Acer timeline got unstable. Two projects where open at the time, one in visual studio 2005 [I have both 2005 and 2010 installed]. Unfortunately I lost all the codes I had done at the time along with those coded even weeks before. Now the project files in both the solutions are those weeks older. Amazingly, the .aspx pages are intact and .cs files are gone.
What can be done to get the lost data? Help please.
Thanks.
Guys TAKE CARE if your Visual Studio crashes, you need to check the backup BEFORE you restart Visual Studio and check if your files are ok! Many people complain that they lost work after a crash, and then they restart Visual Studio, and upon discovering that their code cannot be found in Visual Studio they then check the backup at the location
%USERPROFILE%\Documents\Visual Studio 2010\Backup Files\\
The order is important. Check the backup FIRST, before restarting Visual Studio. If you start Visual Studio and then open your old project it's probable that Visual Studio will overwrite the backup files for that project.
Securing the backup is your FIRST concern. Then start Visual Studio and open your project to see how much damage there is.
You can check:
C:\Users\<username>\Documents\Visual Studio 2010\Backup Files\<ProjectName>\
C:\Users\<username>\Documents\Visual Studio 2005\Backup Files\<ProjectName>\
More information can be found here:
Visual Studio 2010 AutoRecover Feature
I just had the same experience -- losing a source file during a BSOD. Very annoying!
No backup file could be found, and I searched the hard drive for a file containing the class name, but no backup was unturned.
However I was able to get back something resembling my code by decompiling a DLL from the bin/Debug folder using DotPeek. So if you had previously compiled your code successfully, you can get the code (without comments, and with some weird local variable names, etc) via decompilation.
I Had the same problem, I lost code due to BSOD.
the backup folder should store files not saved until they are saved whenever you save the files there are deleted.
I think that maybe they don't remain after a restart as it was empty in my case.
A very good file recovery tool is Recuva. It helped me once, didn't help me second time, though, because I noticed the data loss too late, and all recoverable data got overwritten.
So I used DotPeek, though you'll have to do a lot of work on the disassembled files, they are pretty weird.
Now I put my source tree in Google Drive, because it has file versions and keeps deleted files. Dropbox would do, too.
Git or any other VCS are not solution for this thing, because you cannot have crazy amount of meaningless commits.