In Visual Studio 2015, when I save I sporadically get the following dialog after saving a file in source control (specifically, I am using TFS 2017).
This is a modal dialog that blocks any input into the application.
Regardless of whether I let it continue or if I press cancel (as I have done so here), it just hangs there indefinitely. My only recourse is to force quit visual studio and run it again.
What can I do to solve this?
Whenever I see problems like this, my first fall-back is to create a new workspace and start fresh. Sometimes the metadata gets in some sort of state, so it never hurts to start over with a workspace.
Related
I am experiencing this weird problem with Visual Studio 2022.
I created the skeleton of a new web application using individual accounts.
I have run the first migration, created some default accounts in the aspnet identity tables and
finally launched the application to test if everything was correctly setup in my PC.
Visual Studio compiles the application without problems and launch the defaul browser (Edge).
The standard Welcome page appears but immediately Visual Studio pops to the front doing nothing.
No errors, no messages nothing wrong. Just the code window here to obscure the browser window.
Now, I switch to the browser window and click on the Login link.
Again, the login window briefly appears in the browser but it is immediately obscured by Visual Studio.
Switch again to the browser, compile the required fields and click on login.
Again Visual Studio thinks that he is the best app on the planet and brings itself on the foregroud.
I have tried to switch to another browser, but the results are the same.
I have tried with an existing application written with Visual Studio 2019, but again the "pop in front of everything" still happens.
I have tried to search for this problem but probably I haven't find the right keywords to represent this problem correctly to a search engine.
I think that probably I have something wrong in the Visual Studio configuration, but it is practically impossible to find something there if you don't know what to look for.
The only option that seems to be related is "Bring Visual Studio to the foreqround when breaking in the debugger" but even after uncheking the option the "pop to front" persists.
So my question is simple. Has anyone experienced a similar behavior? If yes how have you fixed it?
Well, probably this situation is so messed that none will ever see this post.
Nevertheless I would like to share how I have finally resolved the question and leave here a warning for future readers.
The cause of Visual Studio 2022 hiccups is, probably, the import of Visual Studio 2019 settings.
I thought that it was a good idea to set 2022 with the same options used in the last 3 years so, after installing VS 2022
I used this very useful menu (Tools->Import Export Settings) to export all the Visual Studio 2019 Settings in an XML file and I reimported it in 2022.
I thought, if the file is not compatible with VS2022 surely it will abort the import. Right?
No, Visual Studio 2022 doesn't complain during the import of 2019 settings.
But something in that exported file should be very broken.
I have resolved the problem with these steps
Close Visual Studio 2022
Open a command prompt window with administrator rights
Change to the install folder for Visual Studio 2022 and then change dir to subfolder "Common7\IDE"
Finally execute the command
devenv /ResetSettings
After this everything started to work as expected without problems.
I have saved the broken VS2019 setting file and tried to compare it with one produced after the reset,
but they have too many differences to extract something useful to identify the specific problem area
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 having an issue where my Visual Studio randomly hangs. The issue does not occur during any specific task, but randomly throughout the day.
I have tried renaming %APPDATA%\Microsoft\VisualStudio\ folder to VisualStudio.backup\ to rebuild the folder from scratch. Also tried doing a repair.
Any help would be greatly appreciated.
This may not be the answer in your case but in my case the culprit was the service VSStandardCollectorService. I restarted this service without restarting Visual Studio and I was able to use Visual Studio 2015 again.
I found this out by looking in the Task Manager. Find the visual studio process then choose "Go to details" from the context menu. Then choose "Analyze wait chain" from the context menu of the details item. You will see all the stuff it's depending on in terms of wait, for any item that is hung. FYI: When something isn't hung (or waiting), it doesn't give a wait tree. This really takes the mystery out of hangs.
My work requires that I retrieve javascript files from a TFS repository in Visual Studio 2012, correct any errors or make necessary changes, then commit them back to TFS.
I recently had a colleague go on holiday, so I had to open a solution to run a C# program from the solution in his absence.
Since running this solution, I've now got all my javascript files opening in a new solution, which is annoying as I have to close the solution without saving it every time I want to do a commit.
How do I stop Visual Studio from opening the files in a new solution, and get it back to its previous behaviour of just opening the file?
I have a weird situation: Visual Studio 2010 will hang up indefinitely on me when opening certain websites. It prompts me for my credentials and loads up much of the project tree, and then just hangs at the "Preparing Solution..." dialog, which just then never goes away. In every case, the status bar of VS says that it is currently loading web.config.
It only happens on some websites, not all, but the websites that do fail, they all open without any problem in Visual Studio 2008. So it almost seems like 2010 is having some sort of problem parsing web.config files under certain circumstances (unless of course that web.config message was just the last file to load and it's actually crashing on the next step).
I've tried disabling all my add-ins and extensions, which did not help.
This turned out to be an extension which needed to be updated. In short, if VS says your extensions need updating, then update them. BEFORE trying to open a project, otherwise you may have problems.