I'm using Visual Studio 2019 and I'm debugging an angular spa app. The problem is that the 'Script Documents' section in the Solution Explorer that appears when you are debugging is really annoying.
I know why this is here and why it is sometimes useful, but 99% of the time I want to hide it.
The JavaScript debugging is working fine and I do not want to turn it off. I just want Script Documents to remain closed.
This problem is made worse when my angular app keeps rebuilding as I make changes. If I close Script Documents, it just re-opens when the app rebuilds. There has to be a way to hide it.
I've seen similar questions before but I haven't seen any clear answers.
So I have not yet figured out a way to do it. It was an issue in VS going back many versions and remains an issue today.
The work around I went with is the same one suggested in 2014 for VS2013, which is to right click on the project in VS that you are most interested in and click Scope to This.
This is a crappy solution but it works if you are having the problem, but you can't easily get back to the other projects in your solution.
https://stackoverflow.com/a/24116987/95041
As #Cory pointed out, there is a feature request. If this problem is affecting you, please upvote so it gets fixed.
https://developercommunity.visualstudio.com/idea/351537/provide-a-way-to-prevent-the-script-documents-fold.html
Related
The Basics
So I've been working with Xamarin a decent bit recently, and am looking for a solution to a current problem. I've been using the WoWonder script recently, and launched it on a site. i can confirm that the site is working well, without any hiccups. Although I've reworked some of the UI / UX, and basic functionality, I haven't delved extremely deep into it.
I'm currently using the Mobile Timeline applications to link into the network. I've had to debug a decent amount of problems so far with the NuGet packages, syntax errors, as well as authentication / decryption errors. I solved the first two, and solved the last by switching the SSL & TLS options in the Android Options area.
I would normally seek help from the author of said project, but given people in the comments haven't always gotten their answers, and instead got the runaround (Not to mention the broken english), I thought Stack would be the better option.
So far, I've asked around, and looked around, but haven't found anything. This is my last attempt before I start breaking everything down, line-by-line. I haven't found anyone else having a similar problem, other than the Xamarin > WP8 issue.
The Problem
Screenshots:
https://1drv.ms/u/s!Aub_kvZQCqk8ii7fW8ntcn4dxh-W
https://1drv.ms/u/s!Aub_kvZQCqk8ii9Ksd86tPIHLXMo
SideNote: The project does use 'Xamarin Components," and the syntax / order of things is a mess. It's nothing that breaks anything or issues too many warnings, it just parses a lot that it can't find, or isn't relevant / needed / is outdated.
Edit:
It's difficult to copy the context of the error in the emulator, since it doesn't seem to be showing up in visual studio. I'll transcribe it below.
Code Snippet:
System.Net.HttpRequestException: 500 (Internal Server Error) at System.Net.Http.HttpResponseMessage.EnsureSuccessStatusCode()[0x0002a] in <dcbf7ae3bce147228fa58d5bc31257ae>:0 at WowonderPhone.MainPage+<OnLoginClicked>d_2.MoveNext()[0x00252] in <1284583bda884ff38ca175979b310f47>:0
This has since been fixed. It was a problem on the server side, but had to do with the script, as the person previously mentioned. It wasn't a problem with Apache directives, or heightened security, just an inconsistency in the script syntax. Unfortunately, since another person solved this directly, I don't know the exact margin of error.
Just wondering my browser keeps asking if I want to stop debugging every time I hit browser link refresh very annoying as is slowing down devtime.
Has anybody else come across this?
cheers
Updated Answer, Root Cause Now Found
After what is now TWO years of seeing this error on and off I finally understand what's causing this. A BIG Thank you goes out to Damian Edwards for mentioning this in a community stand-up!
As a developer, we often do all of our development in Visual Studio in Debug mode rather than release mode. And it's very common for us to run our projects with F5. In this case VS runs the project with the debugger enabled, no surprise there.
So it turns out, the "Do you want to stop debugging? error dialog when you try to refresh via browserlink is saying is "Hey you made some changes that look like they might require recompiling the razor view in order to refresh the page, and in order to do that Visual Studio needs to stop the debugger session, is that OK?"
And the fix? This is gonna blow your mind. When you want to use browser link to rapidly refresh the page while doing html/css changes and never see this message again, do this: run the project using CTL+F5 instead of F5. This will run the project without firing up the debugger and you probably weren't gonna use the debugger anyway if you were planning on doing a bunch of html css work on a view using browerlink. :-) That's it, no more error message. Bam. You're welcome. (It took me T W O Y E A R S to figure that out. Hand against forehead, eyes rolling)
I have left my original answer below because it did seem to help in some cases and it has already received a couple upvotes, but in hind sight, I think it was more of a coincidental observation than a root cause..
Original
I have been struggling with this issue for nearly a year. I may have just discovered the cause. I was running two copies of visual studio, each with different web projects, at the same time. Then when I try to get browserlink to refresh the browser in one copy of visual studio it asks “Do you want to stop debugging”.
I then quit out of the 2nd copy of visual studio, and re-ran the web project in the first copy of visual studio and when I tried to get browserlink to refresh the browser it worked fine with no prompt. Yea. A better error message than “Do you want to stop debugging” might have been "It looks like you are running two web projects at the same time in different copies of visual studio. Browserlink does no support this, please close one of them."
You may want to check out this post: https://stackoverflow.com/a/21706524/4079626. If you are using an older version of IE (like IE9), then long-polling may be the issue.
Short answer
Browser Link will only use WebSockets on Windows 8 or Windows Server
2012
Longer answer
The following would explain the issue if you're using Visual Studio on
Windows 7, Windows Vista or Windows Server 2008:
IIS (Express) depends on the .NET framework implementation in
System.Net.WebSockets to handle WebSocket connections; as you
can read in the link to MSDN, you simply don't get an actual
implementation of the necessary classes when you install .NET 4.5 on
Windows 7.
So in that case, the server can't agree to the client's request to
change from standard HTTP to the WebSocket protocol, which forces the
SignalR client to use one of the fallback options (in your case:
long-polling).
I have been suffering from the all too common 'Waiting for a background operation to complete...' message in Visual Studio 2012 (Professional) for a while now but it has been fairly sporadic.
Lately though, I am really struggling to use Visual Studio as pretty much whenever i try and do anything with any Razor views (mostly clicking to move the cursor) visual studio hangs and the above message appears for about a minute at a time.
(If when its finished doing stuff i then click in the view again, the process repeats, and repeats, and repeats.....)
I have searched high and low, and read loads of articles regarding this and peoples suggestions and tried changing indentation settings, resetting settings, etc but none have worked.
Has anyone come across something else that may work as this is seriously impeding my ability to use visual studio and sadly provoking much cursing.
I also had the same issue with VS2012 and unfortunately I had to format my pc after trying all the following solutions:
Move/clean the symbols cache
Reset VS preferences
Install Upgrade 2
Uninstall/Reinstall VS
After formatting and reinstalling VS2012, it started working like a charm again (obviously).
Sorry for that.
I know I asked this question a while back, but I thought best to put up my findings as they may help others.
The exact reason for the Waiting dialog is still unknown, but I have since moved my project to a local disk and implemented Team Foundation server to perform the hosting and backup of the main project files.
Since moving to local disk and using TFS, I have not experienced any more of the VS Waiting dialog.
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS if it is
I've got a relatively small project written in ASP.NET MVC3. After working a while, Visual Studio 2010 becomes very slow in Razor views (other file types work fine). With "slow" I mean "every keystroke takes around 1 second to register". It doesn't matter what that keystroke was - typing a single letter is as slow as pasting a screenful of markup. During this slowdown VS2010 consumes 1 CPU core to 100%. After I restart VS2010, everything goes smoothly again for a small while. This happens in any and all Razor views.
My PC isn't the best, but it should be enough: Core 2 Duo 6700, 4GB of RAM (currently only 75% filled with VS2010 being slow and all, so it's not a RAM shortage), Windows 7 x64.
The project is close to an end, and I remember that for most time there were no problems. This has started only recently, although I cannot imagine what could have caused it.
Does anyone have any ideas about what could be wrong and what could be done to fix it?
It is plugins - TFS/AnkvSVN and ReSharper have all caused problems for me.
Turn them off one by one, to discern which one (if only one) is causing you grief.
When you find the culprit, make sure you keep up on any patches with it.
In extreme cases, turn if off if you have a long development session and don't need it the whole time (SVN for instance could be turned on when you are ready to do commits and check ins, etc.)
The issue is resolved for me, by installing the Mvc Html5 Templates.
After the installation, I picked XHTML5 and then back HTML5 from the "Target schema" combo box. After that, the paste was instant!
Edit: I uninstalled "Mvc Html5 Templates" and the issue didn't reappear. Perhaps it has something to do with the "HTML 5 Intellisense"
Have you installed sp 1 it fixed some performance related issues when loading IntelliSense for markup
Run the Resource Monitor (CTRL+SHIFT+ESC, click Performance tab then Resource Monitor button at the bottom). Pay special attention to disk I/O and perhaps CPU usage.
Sort disk I/O by Total B/Sec descending. As you type, see if it can identify a process which is causing the issue. Hopefully it's a virus scanner or some other famous performance destroyer and not the Visual Studio process itself, which wouldn't be very helpful.
Have you tried opening the same project on a different machine? This will give you an idea whether issue is in the project or VS install. Quite obvious, but is there anything in the event viewer. Are you connected to a domain while this is happening?
Well, for me the problem has turned out to be anti virus - we use (or are made to suffer) Sunbelt Vipre on our workstations and as soon as I switch off active protection (so that's basically disabling AV completely) all of a sudden all the performance issues in all windows are gone.
Sorry for adding another answer, but there seem to be lots of different causes, so - lets list all possible fixes here.
I tried disabling ReSharper and other addons - did not work. What did work - is reapplying the SP1 again.
PS. Weird, I know. Don't ask, no idea... My guess is - VS was "repairing" itself silently at some point and restored some non-SP1 components.
PPS. You might also want to try disabling "Productivity Power Tools" addon. If you have ReSharper installed - almost all the PPT features are already there, in ReSharper.
PPPS. I have a blog post with several performance tips for Visual Studio & ReSharper, might come handy..
Have you tried Cleaning the solution?
In my case, high CPU usage started out of nowhere (WPF project). Restarts of Visual Studio didn't help, neither disabling/uninstalling addons. But Cleaning the solution did help!
I was experiencing a very similar issue on a large cshtml file in VS 2015 and was solved for me by turning off all of the automatic formatting options in Options > Text Editor > C# > Formatting > General:
I then use the "Control+K,D" key combination to format the page once I have finished making the necessary code changes.
Hmmm, a new odd issue that has just started. Every now and then VS drops a whole bunch of projects from the solution. It will say at the top of Solution explorer "42 projects" when it is displaying only about 20 or so. Closing VS and re-opening it fixes this, although it is a bit of a pain as it takes a little while for the .sln to open again.
We run VS2005 and mainly work on a 42 project solution targetting the Compact Framework 2.00. I'm pretty much the only one using Resharper here (despite my recommendations to others and their occasional oOoing and ahhing at its beauty) so i use CTRL+T to find classes but when i've been hitting SHFT + ALT + L to select the item in the solution explorer (to view the history in TFS) it hasn't matched anything which is how i've noticed this issue.
Anyone experienced this before?
Though this doesn't address your problem directly, have you considered breaking it up into multiple solutions? I'd imagine VS chokes when it starts to get that large, and you're probably working in an un-tested (though not un-supported, I suppose) situation, since I doubt the MS testers created a solution holding 40 projects, all targeting CF.NET.
If you can break it up, that's what I'd advise, and I'll bet the problem goes away. Also, have you tried installing the Service Pack for VS? If not, here it is.
Well this question is super old now and according to my old self:
I think I just rebooted or something and I haven't seen the issue again.
This seems to be about as close as we'll ever get to a solution so I'll set this as the accepted answer for now.