I'm having a bit of problem debugging in VS for our web application, basically all requests are painfully slow, requests that used to take <1s are taking over 15s which as you can imagine makes developing a nightmare!
This is on my newly installed laptop (done it twice recently and the problem is the same both times on both laptops).
I've tried the following without success:
Run without debugging (ctrl+F5)
Run in release mode
Disable diagnostics panel in VS
Disable unused debugging options in VS
Different browsers (Chrome, FF, Edge)
Disable Antivirus
Disable ReSharper/Uninstalled
The solution is a mix of WebForms, MVC, WebAPI, Classic ASP with standard SQL connections (calling stored procs) and Entity Framework.
I have also tried Visual Studio 2017 and I'm getting the same issue there too.
Does anyone have any idea what could be causing it? I've googled and tried several things people have suggested without any success.
It turns out that the issue was down to have the Data Source value of the connection string set to (local), where as on my old laptop I know that in some instances this was set to the computer name.
I'm not sure which connection string was a fault as we have several in a fair few config files (about 20 connection strings in total) and I just changed them all.
However I'm still unsure why there is a noticeable difference in using computer name and (local) in this situation.
Related
I have been facing some weird connection timeout issues in Visual Studio Code.
I am writing a simple web crawler to read a website using the requests and beautifulsoup4 packages in Python. I don't have any problem opening the URL in my web browsers (opens fine in Edge and Chrome), but when I say request.get(url), then the request always times out. Also, when I try to install some additional packages using pip, it always times out. But the corresponding PyPI page opens fine on my web browser.
The funny thing is - I am facing this issue only when I work out of my company's office. I don't have this issue at all when I am working from my home. There shouldn't be a system-wide firewall or a network firewall, because if there is, then the sites shouldn't be opening on my browsers too, right?
I went to VS Code Preferences and checked the settings there. There's no proxy set up. There is nothing specifically that would block network requests from inside VS Code. Here are some screenshots showing what VS Code Settings looks like.
I looked online and couldn't find much, since every question out there is regarding timeouts in SSH connections, which isn't relevant to me here. This official site here gives a bunch of URLs that need to be allowed by the firewall for VS Code to be able to connect to the network, but I don't know where to add them.
Is there something that I am missing? Any leads on how I can debug this issue? Or is it something that I'll have to take up with my company's network administrator?
TIA.
Has anyone seen the issue when debugging an Asp.Net 5 (core) application where the application seems to just go to sleep. Selecting another function/page in the browser just says "Waiting for LocalHost" (as I am running it locally on IIS Express).
We have a staged version of the Asp.Net app and it has no such problem. It runs wonderfully, but in Debug mode, it can have serious delay issues in executing code. Nothing is reported in the output window, during the time it appears to be doing nothing. Nothing on the Diagnostic tools windows either
A lot of the time - it will ultimately come back if you let it do its thing. But sometimes it can take up to 15-30 seconds.
The issue seems to become more prevalent when you change the Razor or javascript client files while the app is running?
Soemtimes pressing F5 on the web page makes it get out of its sleep mode (but not always, and it seems the more times you do this it, the slower it gets). Is it perhaps rebuilding the page that changed? but why the delay?
Again this works fine in Staging or Production (as none of the back end client side files would be changing). But it can be very annoying
Any ideas?
For me it was my Anti Virus. As soon as I disable AVG all requests get immediately run by the debugger.
So I found I didn't have the web tool extensions even installed - and after I installed it - the Freeze disappeared, but a colleague of mine still has the problem (as he already had the extension loaded and there is no way to uninstall it once its loaded
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.
Using Visual Studio 2010 on Window 7 64bit. I'm trying to test a website project (not a web application project) using the built in dev server (cassini). The problem I'm having is that when I make a change, I now have to actually stop debugging, kill cassini, and restart before I can actually see my changes in the browser. I used to be able to edit and refresh. One of my fellow developers here is able to do this just fine with an identical setup (same project/vs version/os - and settings near as I can tell). I'm beginning to suspect some sort of permissions issue. I've been all over google trying to find an answer to no avail. Any ideas?
As it turns out, this was my fault... I had experienced the dreaded "network BIOS command limit has been reached" issue. I found a post that recommended doing a regedit hack "HKLM\Software\Microsoft\ASP.NET\FCNMode = 1", well this basically turns off File Change Notifications. Changing this value to 2, and applying the changes recommended in knowledge base 810886 fixed both problems.
I'm having a performance problem on my company's web site using a specific version of IE 8 to load a page using https. Here's what I know.
Server:
Virtual machine running on VMWare ESX
Windows Server 2003 Enterprise Edition SP 2
Tomcat 6.0.16
Client:
Windows XP and Window 7
Internet Explorer 8.0.7600.16385IC
Page loads/refreshes in under 1 second using HTTP.
Page loads/refreshes in 15-16 seconds in HTTPS using this version of IE.
Problem reproduced on multiple client machines with same IE version.
Problem reproduced on multiple client machines with different Windows versions (XP and 7).
No performance problem using Chrome, Firefox, Opera, or Safari from same machine.
No performance problem using other versions of IE 8 on other machines.
Slow load causes virtually no CPU, memory, or I/O spike on server or client machine.
No performance problem on other sites using HTTPS on same client machine.
The pages in question use JavaScript and innerHTML to replace the contents of div elements to create a collapsible menu, and an iframe to display some content. A couple of the div elements contain images. If I remove the iframe and the JavaScript, the performance issues go away. However, rewriting the entire site to make these changes would be very time consuming. We're in the process of replacing the whole site, but it may be 2-3 months before we do so and we really cannot live with this slowdown that long. I've already looked at several IE tuning options, such as disabling add ons, running IE-rereg, and resetting IE, with no luck.
Does anyone have any suggestions?
The version you mention is the version that shows in Windows 7, is it not (i.e., in Windows XP, it should show like 8.0.6001.18904)? Have you applied all recent patches? More particularly, have you applied the KB980182 security patch?
That particular patch was an "out of band" patch, which means it has been brought to the public in haste and outside of the normal upgrade cycle. It came out April 22, 2010, or about. If you have installed the patch (either automatically, or by hand), try uninstalling or rollback using the Backup and Restore Center and select the restore point that mentions that fix.
While KB980182 caused quite some trouble and weird behaviors, you may try the same approach with other patches if rolling back to before KB980182 didn't help: rollback using Backup and Restore Center to an earlier moment in time, and check if the problem goes away.
This type of testing is a nuisance, I know, but I'm afraid there's little else you can do.