Related
In Visual Studio 2013 Professional, the keyboard shortcut which is supposed to toggle to the previous tab, bound through Window.PreviousTab, seems to be toggling the Design/Split/Source views:
I went ahead and tried to isolate the problem by removing everything connected to the default keybindings of CtrlPage Down and CtrlAltPage Down. I also completely removed all keybindings for Window.PreviousTab and Window.NextTab so that nothing changes the windows.
I then bound CtrlTab to Window.NextTab and it worked fine for going to the next tab. Then I removed that and bound CtrlShiftTab to Window.PreviousTab and it toggled the Design/Split/Source view instead of the tab. I removed that and bound it to CtrlTab and it had the same effect. There are no other bindings using CtrlTab or CtrlShiftTab.
What is causing this, and how can I fix the problem? Is it a bug?
The only extension I have is PHP Tools for Visual Studio.
I had to look for it for a while, this was intentionally removed. For a good reason, this is legacy. It didn't get any love at VS2010, just the minimum to still make it functional, WebForms is not Microsoft's priority. Very high odds that you can't fix this and the keybinding was hard-coded in the extension.
But don't take bad news from an SO user, nobody ever likes that, get it from horse's mouth. Also a basic way they find out what their customers care about. Post the issue at connect.microsoft.com
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.
Do you wish to reload the project? Where's the Reload All option.
Vote for this question and hopefully MS will implement a fix in VS2020.
With pleany of projects in a solution I for one dread doing an svn update.
This has been an issue from VS2003 but after a decade of clicking mindlessly on buttons it's getting on my wick.
Does anyone have a hack / registry entry / secret way of saying yes short of saying ignore (quick), closing and reloading the solution?
There are a couple of options you can tweak for this scenario. Both are under the Documents Options
Tools -> Options
Environment -> Documents
The first option is to just uncheck "Detect when files changed outside the environment". This will stop the reload dialog but will force you to manually reload.
The second option just below it is a bit better "Auto-load changes, if saved". This will just automatically load the changes without prompting you for every project.
Personally though I would go a slightly different route here. The problem is occuring because your managing your source code control outside of Visual Studio. If you switched to using an addin to manage within Visual Studio it would remove these problems altogether. For svn there are several free packages available including Ankhsvn which is fairly popular
http://msdn.microsoft.com/en-us/library/ms165643(VS.80).aspx
DetectFileChangesOutsideIDE
Get/Set (Boolean)
Determines whether the environment automatically reloads files opened in the IDE when the operating system notifies the IDE that the files have been modified on disk.
EDIT:
Some clarification, as that page isn't immediately obvious.
Tools Menu->Options -> Environment->Documents->Uncheck Detect when file is changed outside the Environment
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.
I still have to use the VB6 IDE.
Unfortunately every time I start the IDE one of the buttons of the toolbar disappears. Almost always it's the Run button which goes first. Sometimes also items from the menu bar or the context menus are missing.
I have to reset the toolbars almost every time I start the IDE (Which is quite often during a typical work day). Recently I bought an IDE plugin which modifies the menu bar and requires a restart after every reset of the menu bar. (Otherwise it would crash)
I could live with just the resetting, but the restart is really annoying.
Is there something I can do?
To solve this problem:
Unload all add-ins.
Right-click on a toolbar and select the Customize... menu.
For each toolbar click the Reset... button (6 times in total).
Reload the add-ins.
For me action 3 was enough.
cf. MZTools faq (thanks to Andrea Bonafini), but these steps are originally from MSDN
It sounds like you recently bought a bad add-in. Can you get your money back? Every time I've had problems with disappearing controls in the IDE it has been due to a bad add-in. You can find out which one it is by disabling them, one by one, each time using the IDE for a while, then re-enable it and disable the next one, until the problem stops.
I still use one problematic add-in. It exhibits behavior similar to yours in that it makes the run button disappear. I avoid the problem by only loading the add-in when I need it, use it (it formats code), then I immediately unload it. If you don't use the functionality of the add-in that often, this could be an acceptable workaround.
Yea, i have this same problem with one of the add-in. But if you reset it. Shut the IDE down and open it back up again without doing anything, the IDE shouuld be able to retain the previous clean setup.
It's just guest, but:
Each graphical element on IDE (like button) is kind of resource (i.e. GDI handle).
Maybe your VB app doesn't manage these resources good enough and after sometime VB IDE cannot redraw elements like buttons (run is used often).
Also, maybe some IDE add-in is in conflict with some other add-in/application and breaks something -- I have this problem with Clip-X and MZ-Tools.
I had a similar problem when I was setting up the IDE to use for the first time, though it may not be helpful if you've been using the same IDE for a while. When I first started using the IDE, I would modify the toolbars and then close the IDE. When prompted if I wanted to save the open file I always said No, since the file was just a dummy file I was using to open the IDE with. Turns out the IDE was saving the toolbar preferences with that file, so they never got saved.
Try opening a file, customizing the UI, saving the file, then closing without modifying the code. This was the solution for me.
I've tracked down the problem and as suggested it was an add-in.
The problem went away as soon as I disabled the Visual Basic 6 Resource Editor.
How to restore your VB6 IDE without reinstalling:
Run Regedit
Find the entry for Visual Basic 6.0
Export your settings in case things
go wrong
Delete the 'UI' setting
Run VB and you will have your popup
menus back
The 'Find' button disappeared from my VB6 toolbar forcing me to select the Edit menu to use Find. I had two add-ins enabled: vbCodePrint and ResourceEditor; so I did away with both of them, turned VB6 off and back on, then put both add-ins back in and my button returned.
If you're still using the VB6 IDE, and I do amongst others, then this problem is not likely to have gone away. I use VB6 in Windows 10, and the problem is still there. But it doesn't affect me anymore.
I have had this problem a few years into using VB5 and VB6. Today, if I start VB6 directly, it may work fine the first time, but buttons will go missing the second time -- ALWAYS.
My solution, which I developed from day one:
Do whatever needs to be done to restore all your buttons. Save the Visual Basic 6.0 registry settings to a file, as suggested previously, and only keep the UI entry. Sometimes, you have to exit VB6 for it to post changes to the registry. So if this doesn't work the first time, try exiting before saving the settings.
I use my own program to launch VB6, which automatically copies my VB6 registry backup back into the registry -- by calling "RegEdit.exe /S D:\VB\IDE_Fix.reg" -- before I launch the IDE . This works every single time, and requires no action on my part.
If you read this, that means you are a programmer. You can make this work by yourself.
Mike
Reinstall,clean registry and update with SPacks etc....