I have a problem with Visual Studio 2015 Community.
It's a bit difficult to explain, but here goes.
It seems like Visual Studio is not updating the window when I e.g. Open a project, tries to write in command line, open a file.. or do anything. But a soon as I manually resize the window of Visual Studio, all the things I have pressed or typed appears.
I have Visual Studio installed on two computers. At first it was all fine and dandy on my laptop, everything worked as it should.
Then the problem started on my desktop computer, so I decided to go back to my laptop, but surprise! Now my laptop had been cursed with the same problem! (They use the same user in Visual Studio).
I have tried to re-install VS, repair VS and delete the cache folder inside "App Data"-folder, but no luck.
It seems like Visual Studio works fine, but it just won't show me. (Unless I resize the window)
Can anyone please help me?
Found the problem!
It was the voice communication app called "Mumble" that created all the fuss!
Mumble has a feature called "Overlay" - That feature makes VS go crazy, apparently!
Turning it off, makes all of my troubles go away.
Thank you all for the input anyways.
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
I've always used System.Diagnostics.Debugger.Launch() as a quick way to debug web services. I get a dialog asking me to choose a debugger, I pick "New instance of Visual Studio" and it fires up VS and lets me step through the code.
That has suddenly stopped working. Now I get the dialog, and choose Visual Studio, and the VS splash screen appears, and then it just hangs. The dialog window says "Not Responding" and I have to force it to close. Even then, a VS instance is left hanging around in Task Manager and I have to kill it manually.
I've tried repairing Visual Studio, and uninstalling and reinstalling Visual Studio, and nothing fixes it.
In desperation, I completely flattened my PC and reinstalled everything from scratch. It lasted about a day and then JIT debugging started hanging again. I was on Windows 10 and Visual Studio 17.4.1 before, and I'm on Windows 11 and Visual Studio 17.4.2 now.
To make sure that it's not a problem with some particular code, I created a one-line console app System.Diagnostics.Debugger.Launch(); and that crashes just the same.
Has anybody experienced anything similar, or have any idea what could be going wrong?
I don't know why that fails, but I suggest to attach to a running instance of Visual Studio instead. Start Visual Studio first, and then when the "launch debugger" window appears, select the running VS instance. Preferably, you should even open the correct solution/project first. If you attach to that instance, all your source code and the project structure is available for debugging.
Another alternative: Instead of using Debugger.Launch(), use a code snipped such as
while (!Debugger.IsAttached)
{
Thread.Sleep(100);
}
at the beginning of your program and attach the debugger from within Visual Studio (using the menu option Debug->Attach to process)
I had the same exact problem and after updated to VS version 17.4.4 the issue disappeared. All good now.
When I start VisualStudio it frezzes on the start screen. But when I start it a second time while the first instance is open the second instance works fine.
It's not that important but what could cause that problem?
Not sure. Sometimes some Visual Studio extensions are locking up Visual Studio.
I think by default Visual Studio tries to update these extensions
that have been installed automatically.
Recently I was trying to run Visual Studio (at Home) and it would freeze if I tried to open a specific project. But I was busy, so I didn't pursue it further and did other things. Then a week or a few days later I tried to run Visual Studio (at home), and it locked up when I ran it. I tried really hard to fix it.
There is a way I don't like where you can delete all or most of the
extensions from the place Visual Studio installs them, but this is
messy, and it is easy to get rid of something you need, and may hard
to get it back where it works correctly again. So I now recommend against this since there is a better solution now, below!
I searched to find a solution, and someone on a Microsoft board I think said to run from a command prompt as Administrator: DEVENV /RESETSETTINGS, I tried that and it didn't work for me. Then I thought, run DEVENV /? to see what I can see, and I saw :
DEVENV /SAFEMODE
So I tried that and it worked! Note: it was still being run from the Visual Studio Developer Prompt as an Administrator.
Visual Studio loaded up correctly, and I was able to look at the
installed extensions.
Eventually I noticed that they all or a lot of them were disabled (probably because of this SAFEMODE parameter), and I noticed that it the most recently updated were at the top of the list. I noticed that a lot of them had been automatically updated by Visual Studio and started Uninstalling a bunch of the more recent ones, and reverted at least one of them, then later uninstalled it. Eventually, after about 6 to 10 uninstalls, I got it to where Visual Studio would load normally, without the /SAFEMODE parameter! Cool!
So I turned off the automatic updates, so this will never happen automatically again. If I load a new extension or update and existing one manually, I should always exit Visual Studio and reload it after not doing too many updates or installing too many extensions to see if these extensions allow Visual Studio to load.
Sometimes an extension will not freeze Visual Studio, but will have errors. The ones that are the big problem are the ones which prevent Visual Studio from loading all the way and freezing it up. But with the above solution, you can eventually, cleanly, uninstall all the latest updates or new installed extensions until you finally get Visual Studio to load normally!
This workaround should be more widely known, so I am putting my solution to it here. Hopefully what I found should help someone else who is in a hurry, without having a lot of time to burn trying to get Visual Studio running again without freezing!
I use Visual Studio Community 2017, and I got this same issue on startup until I stumbled on this solution that deals with some corruption in the .suo file. Before I open Visual Studio for the day, I first delete the .suo file in my project folder, and it starts up just fine.
It's in a folder called .vs next to the .sln file. You may have to go to folder options View and check "Hidden Items" in order to find this folder. Dig down in that folder and you'll find the .suo file. Delete it. When you startup the project in Visual Studio, it will automatically create a new .suo file. So you'll have to do this every time you reopen.
I downloaded the emacs emulator for Visual Studio 2010, and everything seems to work fine and dandy -- except cut and paste!
I can delete regions by setting a mark (CTRL-Space) and then delete it with CTRL-W. But it seems that it never goes to the kill ring -- if I try CTRL-Y to yank it, then nothing happens.
Curiously enough, if I delete a line with CTRL-K, then the deleted line goes to the kill ring.
Visual Studio's keybinding menus suggest that CTRL-W should be cut and CTRL-Y should be paste, so this seems to be something wrong with the emulator.
Has anyone had a similar problem, or know how to cut/paste with emacs emulation on?
This is a known bug and Microsoft has declined to fix it. See: http://connect.microsoft.com/VisualStudio/feedback/details/672582/emacs-mode-cut-copy-paste-errors
This is the bug that I submitted. At one point I had Ctrl-w/Ctrl-y working internal to Visual Studio, but never externally. I was fiddling with exporting/importing settings and it started working. Now I've had to reset Visual Studio and it's not working again, and no amount of fiddling will get it back to where I was. Sigh.
So whenever I have to do some serious cut/paste work, especially between the code and some other window, I just save the file in VS and open up Emacs, do the editing in Emacs, then save the file in Emacs. When I go back to VS it asks if I want to reload the file. A click on "Yes" in I'm back working in VS, ready to compile or whatever.
I discovered that dragging and dropping text selections from other applications, into VS2010 with the emacs package installed, DOES work. Your mileage may vary.
Whenever I try to debug a Visual Studio 2010 web project, VS hangs, and ultimately crashes. This happens if I try to start the project using F5, or through Attach to Process, before the process list even appears.
Hitting F5 in, for example, a Windows Form project works fine, but attach to process fails here too.
Any ideas on what can be causing this? Obviously attaching to the devenv.exe process won't work as I can't get the Attach to Process dialog to appear...
Oh, running W7 (x64), VS2010 SP1 (had same problems without SP1)
In Solution Explorer there is a Show All Files icon (highlighted in the photo below):
Make sure it's turned off,
When It's turned on, Visual Studio tries to index all the files in the solution and if you have a giant Solution it could take forever!
I hope this has helped someone :)
Have you recently installed Mono and/or Mono Tools for VS2010?
I found that to be the problem it my case. Not sure why, but it somehow got in the way.
Matthew
In my case hangs when executable type was not correctly set, ex. Managed v4.0 and trying to attach to Native.