Every time I open a solution visual studio creates an extra folder "Visual Studio 2013" in the root directory of the solution.
How do I stop this from happening?
I've had this happen too a couple times (for me, it was because the VS settings etc. were all stored on a network drive that went down while VS was running, which messed up the config).
You'll need to:
Close all instances of Visual Studio
Open Visual Studio. In the options pages, go to Environment->Import and Export Settings and make sure the path there is correct. It should look something like c:\users\[user]\Documents\Visual Studio 2013\Settings\CurrentSettings.vssettings. Do the same for the three paths in Projects and Solutions->General. Save the options.
Close VS, and repeat step 2 if necessary (now that the settings are being saved in the appropriate location).
With VS closed, look in the registry at the immediate values under the key HKCU\Software\Microsoft\VisualStudio\12.0 for any other file paths that still aren't correct (they should all be full paths), and fix them. Be careful not to remove trailing slashes where present, they matter.
Some of these steps may not be completely necessary, or may need to be repeated (I'm not entirely sure which since I didn't have the time to debug this thoroughly the last time it happened -- I just brute-force fixed all the broken paths I found until it worked). This should be enough to get you on the right track, however.
You can safely delete the spurious Visual Studio 2013 folders that got created.
Related
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 am running Visual Studio 2017 on my laptop. I usually work on several different projects/solutions everyday, and there are one project and one solution "pinned" on the MRU list of start screen and file list (the Explorer one).
The problem is, they are both quite old (~2 months since last opened), and I have never pinned them. They just stuck there. So now when I open Visual Studio, the third item is actually the real most recently used one.
I tried to remove the two entries from start screen and file list, they would just automatically pop up the next time I launch Visual Studio. I also tried to stop synchronizing settings via cloud, but it does not help (so it seems like a local issue). I cannot stand it anymore. I did not encounter this problem in previous versions.
What is the possible cause? Is this a bug that I should report to Microsoft (well, it may be recognized as an unimportant one though)? And how can it be solved?
I've encountered the same issue under VS2017 and after few attempts I figured out a solution that may fix your problem.
First of all, after having closed all VS instances, delete the hex keys in your system registry that contains the path of your undesired projects.
In order to do that I've exported all the keys in a backup file, then searched for the occurences with a text editor.
Just for reference, in my case the path was:
Computer\HKEY_USERS\S-1-5-21-2840329424-3192507804-1387616012-2346\Software\Microsoft\Windows\CurrentVersion\Search\RecentApps{0D6B9660-F302-4C2A-82E4-FF89D03814E0}\RecentItems{AC7C50DF-34F3-4DA3-A6ED-45A6CF489220}
Then you have to remove from "ApplicationPrivateSettings.xml" file, the occurences of your projects that you want to remove.
The file is located here:
C:\Users{Username}\AppData\Local\Microsoft\VisualStudio\15.0_0dae6c36
At last, update your visual studio to the latest version with all those tricks done. You shouldn't see all your annoying projects anymore.
For some reason, Visual Studio 2008 keeps adding three folders to my solution folder. I always have to delete them so I don't accidentally add them to SVN. How do I prevent these from being created? This happens about once every couple weeks, but I haven't figured out when it happens. We're probably going to convert all of our projects to Visual Studio 2010 later this year, but in the mean time, I'd like to figure this out.
If anyone knows how to write a Windows folder (or file) creation listener, I'll be able to track this down faster. I'm imagining a Windows Service that displays a popup when a folder gets created somewhere in the Windows file system, and it's constantly listening. I've had other situations where folders and files get created in Windows (in different project types in Visual Studio 2008 or Windows for that matter), so that might be a cool resource to have in the arsenal.
That directory is probably set as your VS Projects location. If you open Tools>Options and then click Projects and Solutions, it should show you the folder paths. VS will recreate these paths if you delete them.
After installing VS, they are usually set to something like:
C:\Users\username\Documents\Visual Studio 2010
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.
I just had Visual Studio fail on a commit due to a merge conflict and when I was done I had about 10 files that it thought were checked in that in reality never made it to TFS.
I ended up having to compare every file I might have changed and adding a single space to the ones I did... quite tedious. I'm wondering if anyone knows of a way to tell which files have been changed in this situation?
Visual Studio will recheck all files when you change from offline mode to online.
If you don't mind losing the changes, you can also just re-checkout everything with the option to overwrite files enabled.