I had about 20 files pending changes in my solution in Visual Studio 2015,I had a problem with repository so clicked on "Undo pending changes" thought I had already had shelved my changes. After undoing pending changes I noticed that I hadn't created any shelveset of those change.
I googled a bit about it and I found this link How can I get my changes back after clicking “Undo pending changes…” in Visual Studio 2013 and TFS
I tried the solution mentioned in answers of link above but there is no TFSTemp folder in my AppData\Local\Temp folder do notice that I'm using Visual Studio 2015 but the user asked this question is using Visual Studio 2013. Maybe vs 2015 store TFSTemp in different location but where ???
Any Idea about how I can get my changes back???
Any help would be greatly appreciated
The TFS Temp folder should be the same path "AppData\Local\Temp\TFSTemp". It's not related to VS version. If you could not find it in your own account, give a try with Admin account (If the VS run in Admin mode)
You should be checking in frequently or setup some sort of backup system to avoid mistakes like this. If the files are gone from your file system, they're gone. Maybe a file recovery utility could do the trick, but the solution is too complicated. Besides past that, there's no way to get them back.
Related
I was using TFS fine with Visual Studio 2013. I've switched recently to VS 2015 and have an annoying issue (bug ?).
I have a bunch of excluded pending changes that I do not want to commit but that I want to keep locally (bad dev environment, don't ask).
My issue is that everytime I re-open VS 2015, all excluded changes are back into the included changes and I have to manually re-exclude all the stuff I do not want to be committed.
If I open VS 2013, included/excluded changes are still in the perfect state !
Anyone knows what is causing VS 2015 to be such a mess ?
I just tested this under Visual Studio2015 Update2 and TFS2015 Update3 with about 300 files in excluded list. Everything works prefect.
It's may related to the your VS. First shelveset your excluded list and try to clear TFS and VS cache. Then just unshelveset the files and adding them back to excluded list again. If it's still not work, try to uninstall and reinstall your VS.
I had this problem with Visual Studio 2013. To fix it, all I did was:
Make sure all my intended changes were shelved
Undo all pending changes
Close Visual Studio
Wipe out the TFS cache at C:\Users\Username\AppData\Local\Microsoft\Team
Foundation\5.0\Cache (where Username is your Windows login username)
Reopen Visual Studio
Unshelved my previous changes back to my workspace
Voila! No more extraneous files showing up in my Excluded Changes list!
I've been working with several projects I have hosted on GitHub, but recently I haven't been able to check in any changes. Every time I save a file, VS treats the file as if it's checked in, lock icon and all. I can't make any commits because of this. I've had this occur in VS2013 Community, VS2013 Pro, and VS2015 Ultimate CTP. While restarting VS works in the 2013 versions, it does not work in 2015.
While searching for an answer, I came across this SO question. The answer did not work for me, as I am using GitHub, not TFS with a Git project ("Connect To" wouldn't show my project). In addition, I have not renamed any of the projects that have had this glitch. Is there anything I can do besides report the bug to MS?
To all the people which have this kind of problem using Visual Studios Git Source control.
One solution which worked for me since all other i found failed was to create a .gitignore file via Visual Studio. This somehow stopped the automatic check in which happened during a filesave.
Team Explorer -> Settings -> Repository Settings -> Ignore & Attributes section -> Ignore File -> Add
I am currently using Visual Studio 2015 update 1.
Earlier today the TFS server where I work went down. As a result, when I tried going into visual studio 2013 to work on a project that managed though TFS Visual Studio detected that TFS was inaccessible and accessed the solution in offline mode. Later on in the morning the server was rebooted and was online and operational. However, when I try to go online with the solution I get the error message stating "Unable to determine the workspace for this solution". So I went ahead and verified that the workspace is correct with all the bindings from the associated source control folder to that of my local folders. So to try and fix the issue I did the following steps:
I completely disassociated the solution from source control even though its offline.
Rebinded the solution to source control. At this point all locks were visible on the solution and the files that were checked out.
I got the latest version for the project and and updated my local solution.
Rebinding the solution worked to fix my initial issue. However, every time I exit visual studio 2013 and go back into the solution it loses all the bindings and it's unable to determine the workspace for the solution. Has anyone ran into this before? Is there something that I am overlooking? Any help will be greatly appreciated.
Please Note, I have read though some of the posts already on stack-overflow and I have not found one that addresses the issue with Visual Studio losing the bindings on each start-up.
Quit Visual Studio.
There is a Registry-Entry
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\TeamFoundation\Instances\\[[NameYourOfTFSServerHere]]\Collections\\[[NameOfYourProjectCollectionHere]]
Change Reg_Dword Offline from 1 to 0
Delete the .suo file of the Solution
Reopen your Solution should fix it.
Make sure "show hidden files" is enabled, then delete the .suo file in the solution's folder (while VS is closed, of course)
Quit all Visual Studio instances and delete TFS cache at "c:\Users\\AppData\Local\Microsoft\Team Foundation\5.0\Cache"
We have a really big solution with more than 200 projects and thousands of files. Despite of that the solution used to load pretty quickly in Visual Studio 2010 as well as 2012. However, after copying the whole SVN repository to another location, loading and closing the solution suddenly took extreeeemly long. (I am talking about 30-60 minutes here!)
I found a solution myself and I wanted to share it here, hoping that it might save someone quite a few hours of research and staring at the "Preparing solution..." dialog.
When inspecting the devenv.exe process with Process Monitor, I found out that it is pretty busy with accessing the .svn directory. Here is what I did (and this somehow solved the problem):
Kill Visual Studio
Open Visual Studio without loading a solution
Disable AnkhSvn as Source Control plugin (Tools->Options->Source Control->Plug-in Selection->None)
Disable "Document Well 2010 Plus" (VS2010) or "Custom Document Well" (VS2012) in Productivity Power Tools (Tools->Options->Productivity Power Tools) - I read that somewhere and it might have helped as well...
Close Visual Studio
Delete the solution's *.suo file. This is located in the same folder as the solution itself. NOTE: You will lose several settings for your solution, like currently opened files, breakpoints, bookmarks, current solution configuration & platform (e.g. Debug x86) etc.
Restart Visual Studio
Load the solution - it was much faster now!
Close Visual Studio
Open Visual Studio without loading a solution
Re-enable AnkhSvn and the "Document Well"
Restart Visual Studio
Open the solution - it was still loaded in seconds!
I do not know which of these steps actually solved the problem. Probably, not all these steps are required, but I did not want to reproduce the problem to find out which steps may be omitted. :)
None of those helped me, what I did... I watch with ProcMon of sysinternals, filtering for devenv, and I saw a lot of entries of fussionlog. I had enabled fussionlog for debugging purposes some weeks before and didn't think in disabling it. I just had to disable fussionlog and the solution opened faster.
You can open the Visual Studio in the Safe Mode, and then check your plugin and source control settings after opening the project.
Safe Mode means "Starts Visual Studio, loading only the default environment and services."
How :
devenv /SafeMode
Or according to your path
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /SafeMode
source : https://msdn.microsoft.com/en-us/library/ms241278.aspx
In my case, the following worked without any of the intervening steps suggested:
Kill Visual Studio.
Start Visual Studio directly (i.e., not from the .sln file).
Then, from within Visual Studio, open the solution.
In my case this was all it took to make the problem solution load quite quickly, without the need for me to change any settings or delete any files.
fwiw, I realize this is a late entry, but I found that simply removing (deleting) my large number of breakpoints resolved the excessive load time and compile time.
This action reduced the size of the .suo file from 214MB to 977KB. Let VS handle the .suo file itself.
Compiling and loading now takes < 1 minute instead of 5-10 minutes for a solution with 35 projects. Visual Studio 2012 Pro, update 4.
None of the other answers worked for me. CI compile times were fine, but loading my solution in Visual Studio was taking almost two minutes. VS would then operate just fine until I closed and opened the solution the next time. Different versions of VS all showed the same problem and both safe mode and deleting the suo didn't help.
I ended up following the advice in http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx to use Windows Performance Recorder to instrument VS and find the problem. By looking in Windows Performance Analyzer under the "CPU Usage (Sampled)" section and adding the "Stack (Frame Tags)" column, I was able to dig into the usage of devenv.exe.
Turns out the hot path by count had Microsoft.VisualStudio.Platform.WindowManagement.ni.dll 23 calls down, and below that eventually Microsoft.VisualStudio.ServerExplorer.dll and Microsoft.VisualStudio.Data.Package.dll. That pointed me to look in Server Explorer in the UI and open the Data Connections tab. There I found hundreds of mistakenly added connections that came from the debug web.config's ConnectionString section. Removing those from web.config reduced the load of that individual project from 90+ seconds to almost instant.
I have a different cause for the slow loading of the projects.
My situation is utilizing Git and found that even switching branches was slower than it should be with project load.
Solution: Run Visual Studio as Administrator
Reason: Something with the Corporate laptop is not providing the needed Git tool access (it doesn't recognize that a git repository is in use).
I have not seen any issues with Git or my personal access to any of the project files or Git objects.
I tried the above, but it didn't solve my problem.
Here's how I got around this problem, hopefully it will work for some of you as well:
Open Visual Studio 2013 with no solution.
Create a new C# Console application and save it.
Close Visual Studio.
Reopen the Console solution created in step 2.
Close Visual Studio.
Reopen the solution that was previously hanging on the Preparing Solution dialogue. Mine opened right away, no more hanging.
Using Visual Studio 2015, I ended up creating a new solution, adding the existing projects.
Deleting the *.suo from gehho's answer helped in the past, but didn't help me in this case. There's also another .suo file in a hidden .vs folder at the root of the solution.
There are other answers here for Visual Studio 2015 Visual Studio 2015 is extremely slow
For my case it was due to TFS issue. It thinks that there are more than 5000 pending changes.
The fix is to force TFS to recheck. Go to Team Explorer -> Source Control Explorer and do "Get Latest" on the projects that have pending changes. For things that are already matching TFS, Visual Studio will actually not download anything to your PC. For things that are different with TFS, Visual Studio will let you know and ask you to reconcile the difference.
This is VS 2019 Professional.
In my case there were <import ...> entries in the project files that pointed to
paths no longer available making the loading of the solution hang indefinitely without any form of information give (Shame on Microsoft!).
I encountered this problem only recently (Mar 2021), using VS 2019. It literarily takes 30+ seconds to load the file (each).
It only effects the Layout files. I believe it could be to do with the links within the files. I have not had time to investigate them.
However, I am writing this to suggest that regardless of the cause of the problem, a simple solution is to right click on the file and open it with Notepad to get your work done.
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.