In VS 2010, after I would close my solution, and then re-open it the next day, all the documents that I had open, would still be open. Just what I wanted.
After installing SP1, every time I open my solution, all my documents are closed, no matter what state I left them in.
Is this expected behavior, a bug, or is there a setting I don't know about? How can I get my documents back?
EDIT 29-Mar
Re-installing VS2010 and SP1 did not resolve this issue.
Building on top of SteveBob's answer, just do a Window -> Reset Window Layout
This should fix the tab problem. There is of course the side-effect that you'll have to redo/re-add all the windows ( output, solution explorer, properties, find, watches, immediate, etc)
Backup your settings then do a devenv.exe /resetsettings.
It appears that there is not an adjustable setting that controls whether or not the open documents are remembered. By default, Visual Studio stores this data and then re-opens the documents that were open the last time the project/solution was closed. As pointed out by some links referenced by Stuart Dunkeld, it takes a Macro in Visual Studio to override this default behavior.
My problem appears to be that my 'Settings' had become bloated/corrupt. Based on the suggestion of Luke, I exported my settings, then did a reset. This restored the default 'Remember Open Documents' behavior. Then after much fooling around, I was able to import (almost) all of my old settings and still not mess up the proper document behavior.
When importing my settings, I selected everything except the 'Window Layouts' settings.
This restored my existing settings, while keeping the default Visual Studio behavior of remembering which documents were open.
I then re-exported my (fixed) settings so that I had a backup. That's when I noticed that my old, possibly corrupt exported settings file was 8.6MB, while my new, correct exported settings file was only 0.2MB.
After examining some of the differences between these two settings files, some of the information leads me to believe that the installation of VS2010 SP1 had a conflict with the 'Document Well 2010 Plus' feature in the Productivity Power Tools extension, but I cannot positively verify this.
Does it work OK with a new solution? If so, you could try trashing the .suo file attached to your solution.
I keep a lot of files open. Every so often, my VS2012 stops restoring the open files. Opening them again does not help the restore process.
I tried:
All the above suggestions, and all the suggestions I could find elsewhere
In particular: deleting .suo, .filters, .sdf, .opensdf, etc
Plus /resetlayout
Plus /resetsettings(ouch)
And none work for me. Or, at least not reliably.
But I just tried:
Install Productivity Power Tools
Enable Options / Productivity Power Tools / All Extensions / Custom Document Well
Restart Visual Studio
(the PPTools document well saves and restores properly!)
Disable Options / Productivity Power Tools / All Extensions / Custom Document Well
Restart Visual Studio
And now the builtin document well has resumed saving and restoring properly as well! At least for the moment.
I'm guessing that the builtin "document well" was derived from the one in PPTools, possibly causing the side effect of turning the PPTools on and off.
(I could simply use the PPTools document well all the time. But I can't get the colors therein to work to my satisfaction.)
Hope this helps someone.
Have you tried deleting the .suo file? It may have become corrupted.
Related
I previously used VS2010. Everything worked fine there. I like my intellisense to automatically accept the top entry when I press space or ;. This is part of a workflow that has served me well for almost 20 years.
With VS 2019, if I type
bool myValue=true;
Since I don't by habit capitalize true, Intellisense immediately replaces my line with this:
bool myValue=truespeechwaveformat_tag;
So... I don't want to kill of Intellisense's behavior-- I just want to say "never, ever, for any reason, suggest truespeechwaveformat_tag" since I have not in my entire career ever used this structure, and will not be starting now.
Is there a way for me to delete that permanently from Intellisense's database? Or put it on ignore?
Is there a way for me to delete that permanently from Intellisense's
database? Or put it on ignore?
truespeechwaveformat_tag seems to be a struct of the file mmreg.h which is from the head file mmreg.h. In VS2019, the Intellisense is a bit different from VS2010.
You can try these:
Suggestion
When you type some letters of true, such as t and r, then the intellisense will lock the true entry in the Intellisense, then use Tab key rather than Space or Enter, Intellisense will choose the entry that best matches. And it works well in my side without any trouble.
In additon, if you still face this abnormal behavior, i think it could be related to VS extensions or some your extra settings.
1) reset your VS settings by Tools-->Import and Export Settings-->Reset all the settings. It will also backup your current settings at the same time and you can 9import it as you want.
2) disable any third party extensions by Extensions--> Manage Extensions-->Installed.
3) delete the .vs hidden folder under the physical path of the solution
Hope it could help you.
I've noticed that my VS15 forgets changes I make to the settings in options and check boxes under Tools on reboot.
For instance, when I exchange a string in a document, I get the pop-up telling my how many substitutions have been made. There's the check box showing/hiding this message next time. I uncheck it and fairly enough the pop-up doesn't come up again. Until I restart VS, that is. After that, the pop-up is back!
The same goes for many other options (typical NuGet packages' suggestion based on the contents of CSHTML-file, for instance). However, all the settings I make in Resharper menu are remembered. Also, the key short-cuts seem to be remembered.
I restarted, updated and reinstalled - no luck there. Starting VS in admin mode gives no change, neither. I noticed that if I change the values in the registry, the changes are effective in VS. It's like VS won't write the modified settings to the registry by itself (and I'm damn sure too chicken and too lazy to horse around in the registry for that).
Has anybody else experienced that?
What more can I do to diagnose it?
How do I kill the problem?
In my Visual Studio instance, even if I just wrote a single line of return in a C# console application, it will take me a minute after pressing F5 to execute the actual code (I mean the time it takes to stop on the single return statement after pressing F5 -- I set a breakpoint on the return statement in the main function). What is wrong? Is there a check list?
I am using Visual Studio 2008 VSTS edition and debugging on Windows Server 2003 x64.
You may need to delete all your breakpoints---note that you need to click the "Delete all breakpoints" button (or use Ctrl + Shift + F9), NOT just delete them one by one. If Visual Studio has mangled your solution settings the latter will not work. You may need to add a breakpoint first, in order for this to work (clever, eh?).
If worst comes to worst, you may need to delete your .suo file and let Visual Studio start a new one from scratch. Note that you will lose your personal solution configuration settings, however (only for this solution, not any others). However, you may want to move/rename the file temporarily until you determine whether or not this is the problem; that way, you can always move it back. I have seen some online resources recommend deleting (moving/renaming) the .ncb file as well.
I have seen this before. Try deleting all your breakpoints and then set the ones you want. Hit F5. Is it faster now?
I just noticed that you mentioned setting up the .NET source debugging feature. Try to disable that. Your network connectivity to Microsoft's source server may be slow. Also disable any symbol server connectivity in menu Tools → Options → Debugging → Symbols.
Also try disabling "Enable property evaluation and other implicit function calls" in menu Tools → Options → Debugging → General.
Or remove your .suo file which can be found next to your solution (.sln) file.
This solved an issue I had with debug sessions taking a long time to start and stop.
I had this problem. After trying all the listed advice and removing all Visual Studio extensions, we finally figured out that somehow IntelliTrace was enabled. Disabling that fixed everything.
How to: Enable and Disable IntelliTrace
Do you have a lot of breakpoints set? Those can really slow down startup time. Everytime a new module is loaded into the process address space, they all need to be checked to see if they are valid.
Go to menu Tools → Options → Debugger → Symbols and check if you have public symbols set or UNC network paths set. Also check menu Tools* → Options → Debugger → General to see if you have source server set.
All of these can affect debugging based on slow network speed or unavailable servers. The 5 minute wait time is network timeouts.
If nothing in options is set, check to see if you have the _NT_SYMBOL_PATH environment variable set.
My colleague had a very slowly responding Visual Studio, and it literally took minutes to perform a step while debugging.
The root cause turned out to be an anti virus program (Threatfire) that went crazy while Visual Studio was running. Killing its process immediately fixed everything.
In my case changing the debug symbol "Automatically load symbol for" option from "All modules" to "Only specified modules" solved the problem. You can change this option from menu Tools → Options → Debugging → Symbols.
A different cause plus... How to find the problem
To me it was the option ShowOtherThreadIpMarkers. A value of 1 makes Visual Studio (2010) unbearably slow (3-5 seconds for each debug step. With a value of 0, it is fast again.
What is it that option? I have no idea. I could not find it through the Visual Studio user interface.
I unchecked all possible debugging options in there and nothing worked.
So I went to Import/Export Settings and loaded my old settings I've previously saved going backward in time until Visual Studio was fast again, then compared the vssettings files..., etc., etc.
I'd like to remark that if you load the settings while you are in debug mode stopped on a breakpoint, they become effective immediately. You don't have to stop the debugger and restart.
From ScottGu's blog linked by Travis: "One other performance gotcha I've heard about recently is an issue that a few people have reported running into with the Google Toolbar add-in. For some reason this can sometimes cause long delays when attaching the Visual Studio debugger to the browser. If you are seeing long delays with your web application loading, and have the Google Toolbar (or other toolbars) installed, you might want to try uninstalling them to see if that is the cause of the issue."
Running under the debugger for me was roughly 10x slower than running without debugging.
After trying every solution suggested here, I went through every debugger setting and enabled/disabled to see if it made a difference.
For me, it turned out that disabling Suppress JIT optimization on module load in the debug settings massively improved things.
Make sure you don't have any stale network mappings to servers that no longer exist (network timeouts will kill you). Or use something like Process Monitor to see if a network (or other file error) seems to be blocking for a long time.
Are you using a symbolsServer to download symbols for Windows DLL files?
If so, disable that as it can take some time, but I wouldn't expect that to cause long delays in a basic console application.
Menu Tools → Options → Debugging → Symbols.
I know this is an old topic, but for what it's worth...
I've found that if I've had a separate Internet Explorer window open for a long time it can take up to a minute to start debugging. Close all Internet Explorer windows and debugging starts immediately.
In my case Google Toolbar was slowing down my debugging.
gplus_notifications_gadget.html just kept going on and on overloading the debugger. I wanted to keep the Google Toolbar because I use it on a regular basis, so I just disabled the G+ notification button (the small button besides the profile button). It is happy now.
I had the same issue in Visual Studio 2010, with stepping in the code excruciatingly slow (between 3 to 10 seconds). However, none of the above settings modification did the trick.
I eventually found the ultimate solution, which would work in all of the above post issues: reset all your settings, as described here (essentially menu Tools → Import and Export Settings, Reset all settings, with saving existing settings to a file (for reverting)).
You may first want to save a particular part of your settings. For instance, I first saved my color theme (Solarized-like) and then restored it after the global reset.
For me, the setting that killed performance (Windows 8 even hanged except for mouse movement) was to uncheck "Break all processes when one process breaks" in menu Options → Debugging → General.
Just one more cause of a slow Visual Studio debugging experience...
Long time ago I enabled FusionLog to see what was causing an assembly binding problem.
Make sure you disable it after using it. Why? Because it writes a lot of logging data to the disk while enabled.
This is the FusionLog key on Window's Registry (regedit.exe):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Change the ForceLog, LogImmersive and LogResourseBindings values from 1 (enabled) to 0 (disabled).
I had this problem too, but it had nothing to do with breakpoints in my case. It was code shortcuts that I added in the tasks window:
http://www.customsoftwareframeworks.com/blog/longwaittimetoinsertoraddalineoftextbuginvisualstudio--tasklistwindow--onlywhenaddingandremovelines
I'm sure there are other ways you could see a problem like this, but there is a bug somewhere that caused this problem for me...deleting all my options would have fixed this, but that is something that I did not want to do. So, I debugged it and wrote about it in my blog...your problem sounds like mine.
Something that has worked for me is to make sure there are no conditional break points. Other than that, I have had success fixing slow debugging by simply restarting Visual Studio and only opening one instance of Visual Studio at a time.
I had a similar issue and none of the other guidance seemed to help. I had rebooted to no avail. I had removed all breakpoints, deleted the .suo file, checked that symbols weren't being loaded from external sources, and checked that no paths existed in the application that was unavailable.
Then, I thought to clean the solution. I noticed in the output window that C# IntelliSense reported an issue when cleaning:
There was a problem reading metadata
from
'{B0C3592F-F0D1-4B79-BE20-3AD610B07C23}'
('The system cannot find the file
specified.'). IntelliSense may not
work properly until the solution is
reloaded.
In this case, once you actually discover the error message, it tells you exactly how to resolve it. (Good job on the error text, poor job on discoverability!) I unloaded the solution's projects, then reloaded them. I was then able to successfully run clean solution. It worked, and the debugger did as well.
Closing the "Autos" window improved debugging for me in Visual Studio 2008 for a big native C++ solution.
Hiding it won't work. It needs to be closed.
I experienced the same slowdown and disconnecting from the network fixed the problem for me as some other comments and answers have stated (but of course that is not an ideal fix).
For my case this one simple change fixed my solution: In the project properties on the debug tab I disabled "Enable the Visual Studio hosting process" (I am running Visual Studio 2010).
Get more memory and a faster HD. More details are here.
Sometimes while developing in Visual Studio IDE, when you use "Find in Files" dialog to find something, the search fails and you will see the following message in the "Find Results" window.
No files were found to look in. Find stopped progress
Once this message shows up, all the subsequent searches will result in the same message. Nothing fixes the problem including restarting the computer except pressing Ctrl + ScrLk.
What causes Visual Studio to get into this state and is there a setting to permanently prevent it from happening?
According to this thread:
Posted by Microsoft on 10/13/2009 at
4:33 PM
Hi all,
Thank you for your continued interest
in this bug. We have been able to
reproduce the issue intermittently in
several versions of Visual Studio
running on several versions of Windows
and have identified the root cause as
external to VS. The Windows team
unfortunately did not have time to fix
this for their current release, but we
are working with them to hopefully
have this bug fixed for a future
version of Windows. At present, the
workaround (as many of you noted) is
to press Ctrl+Scroll Lock, Ctrl+Break,
or the Break key alone.
Again, thanks for all of the details
you provided about this bug. If you
have any further questions or
comments, please feel free to post
again here; although this issue was
closed quite a while ago, I'll make
sure it stays on our radar.
Thanks, Brittany Behrens Program
Manager, VS Platform - Editor
This bug has been around since at least 2004 and, as of the above post in 2009, had not been fixed.
Sometimes Ctrl + Break works, sometimes Alt + Break, sometimes Ctrl + Scroll Lock, and other times Alt + Scroll Lock.
Right now, nothing works. This has been a huge problem for me. Shame on Microsoft for not fixing this bug in the last nine years.
Apparently, for those for who the key combinations don't work (like me at the moment), deleting the following registry key brings salvation:
MyComputer\HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\[VS VERSION NUMBER]\Find
Of course, [VS VERSION NUMBER] should be internal version number of the IDE. Don't forget to restart your computer.
Mind you, deleting stuff in the registry is dangerous. Like anyone on SO cares but anyway...
I don't think there is anything you can do to prevent it.
It seems to occur after I have stopped a build with CTRL+Break...Maybe I am pressing CTRL+Scroll Lock during that time???
I have only had it happen to me 2-3 times, and that was several months apart.
What he is saying is that occasionally when performing a search within Visual Studio you get the mentioned error message. Even though you know there is stuff to find. It is some weird state that Visual Studio gets into. If you press the (CTRL+Scroll Lock) it will 'fix' the issue.
There are currently nine bugs on the Connect site related to this and marked as Not reproducible.
I created another one for Visual Studio 2010 SP1: "Find was stopped in progress" while performing search in Visual Studio
Please vote for it if you are unable to perform search.
PS: Microsoft claims that they fixed it in Visual Studio 2012.
I have had this problem and saw peoples' answers about the multiple Ctrl + Break/Pause Scroll Lock combinations.
I considered this, but I thought it a poor workaround (especially as I use a Mac Keyboard so those keys are not easily available).
So the solution I found was to do this:
Menu: Tools → Options → Environment → Find and Replace
Uncheck the top three check boxes (checked by default in my settings).
Re-check the top three check boxes.
Et voila, everything should work fine.
Well, it did for me anyway, which was a relief as I can't believe Microsoft would allow a weird key combination as a work around for a bug like this.
I submit this hoping it may help!
See if this Stack Overflow question helps:
Search stops working for "Entire Solution"
Short version of the solution:
You should try clicking inside the Find Results window, and once the blinking text cursor is visible, hit Ctrl + Break four or five times. That should do the trick.
My experience with this problem:
Steps to Reproduce
I just experienced this using Windows Server 2008 R2 Standard and Visual Studio 2010 SP1.
I was accessing Visual Studio remotely through Citrix Receiver (from my computer, A, to B) and through Windows Remote Desktop (from B to C). In this set-up (chaining two remote sessions), I sometimes have stuck modifier keys.
In B, I had pressed Windows+Pause to access the System Properties window. (This may or may not be related; I suspect there could have been a stuck key press or something.)
Later on, when I opened Visual Studio on C, I had this problem. Note that I always use Ctrl+Shift+F to access the Find All window.
Solution
I solved it by pressing Ctrl+Scroll Lock as suggested in other answers.
Cause
As for why this happens, I did notice that if I press Ctrl+Break while the text cursor is in the Find Results window but before any results are found then the search stops with the same message. This indicates to me that it's related to a keyboard problem.
As reported by others, apparently it's a Windows bug. Here's a discussion about this.
I encountered a very similar problem. I was searching a folder for all files for a phrase in all .cs files in my solution. Visual Studio kept saying "No files were found to look in". (It did not have the "Find stopped progress" part of the message.)
I searched for the message and found this question. The suggested keyboard commands in other answers did not work.
I like to use the keyboard for navigation. I had accidentally hit Alt+B and Space. Alt+B is the shortcut to jump to the "Include sub-folders" checkbox on the Find and Replace form. The space bar cleared the checkbox, and then Alt+A performed a Find All action. Because it was not searching sub-folders, no files were found. The message was correct.
After checking the "Include sub-folders" box, searches found the matching files in sub-folders. So if you're getting the message "No files were found to look in" without the message "Find stopped progress", ensure the search is looking in sub-folders!
I thought I was seeing this problem, but after two days of searching for a solution I figured out that the "Look at these file types" selector had changed and didn't include the file extension I needed.
I had this in Visual Studio 2015 yesterday.
In Find in Files, in the textfield Look in:, I typed
*.*
instead of Entire Solution, and that also caused No files were found to look in.
This is not a Visual Studio bug or Windows bug. It's a keyboard bug. Please see an answer in duplicate question https://stackoverflow.com/a/28219093/147805.
I can reproduce your issue.
There are some steps as following below you can try:
Check the setting Find and Replace (menu Tools → Environment → Find and Replace).
Open "Developer Command Prompt for VS2013" and paste
“devenv.exe /resetsettings”
Use the Visual Studio Setup Wizard (via Control Panel) to repair Visual Studio. You also can read the reference about Find in Files:
http://msdn.microsoft.com/en-us/library/dechx2tz.aspx
I have found another cause of this: Moving the solution folder to a new location, when CMake is part of the build process.
I was working with the Chromium Embedded Framework and moved the main CEF folder from e:\ to c:\ . This seems to break everything including Find because the CMake build scripts it uses hard-code the disk volume and full path (E:\folder) into the source paths.
To be clear, Press Ctrl + ScrlLck, with the Search Window open. That resolved it for me too.
I'm having a weird issue with Visual Studio 2008. Every time I fire it up, the solution explorer is about an inch wide. It's like it can't remember it's layout settings.
Every un-docked window is in the position I place it. But if I dock a window, it's position is saved, but it's size will be reset to very-narrow (around an inch) when I load.
I've never come across this before and it's pretty annoying. Any ideas?
The things I've tried:
Saving, then reloading settings via Import/Export.
Resetting all environment settings via Import/Export.
Window -> Reset Window layout.
Comination of rebooting after changing the above.
Installed SP1. No improvement
none of which changed the behaviour of docked windows. (Also, definitely no other instances running..)
I do run two monitors, but I've had this setup on three different workstations and this is the first time I've come across it.
I had the same problem. It turned out that if the VS window was non-maximized, it was really
small. So after making the non-maximized wider, the problem disappeared.
I occasionally get this bug, and others related to layout/fonts/colouring etc. A little trick I've found is use the Tools -> Import and Export Settings, export your current settings once you've got everything setup as you like, then close and reopen Visual Studio and import. Hopefully that'll sort you out.
In 2005 there were some little bugs with viewing Project/Solution property panels when the Solution Explorer wasn't in its default position, docked on the left of the screen - I don't know if that's changed in VS2008, but you might want to put it back there and see.
Now, when are we going to get decent MultiMonitor support?!
Maybe you're closing Visual Studio while some other instance is still alive. The settings of the last instance that is closed is the one that will be applied.