IUFITS
asked on
Visual Studio 2005 - Very Slow Save Times
I have an issue in Visual Studio 2005 where I save a project (typically either VB.NET or ASP.NET) and the Visual Studio front end locks up for as much as a minute as a time (with only small changes). Sometimes it locks up with every save and sometimes it will do it every third or fourth save. It's very inconvient and time consuming. Typically, all of my projects are saved on network shares (the network is running fine, no other application has these issues).
Does anybody know of a resolution for this? I've read content on it in the past but was unable to find those articles I had read before.
Does anybody know of a resolution for this? I've read content on it in the past but was unable to find those articles I had read before.
ASKER
That's a great link though the MRULIST registry setting didn't help the issue. I did post a question in response to the thread.
What happens if you save to your local drive C instead? - is it still slow? If it is, then that again adds more credence that the network share is ok. If it's nice and quick, then the problem is likely to be directly related to the network share you're saving to.
It's likely that the problem is a similar one to that described in the first link (ie. network resource resolution) - One potential line of investigation would be to install a packet sniffer such as EtheReal (http://www.ethereal.com/) to get a better understanding of what your machine may be attempting to speak to as you do the VS save - this may quickly tell you exactly what remote DNS name/IP address can't be found.
cheers,
It's likely that the problem is a similar one to that described in the first link (ie. network resource resolution) - One potential line of investigation would be to install a packet sniffer such as EtheReal (http://www.ethereal.com/) to get a better understanding of what your machine may be attempting to speak to as you do the VS save - this may quickly tell you exactly what remote DNS name/IP address can't be found.
cheers,
Hi IUFITS,
Try searching through your project and workspace files (they are text files but DONT edit them directly). Look for references to files that are in an inaccessable location on your network. Perhaps they will refer to a location to a mapped dtive that no longer exists.
If you find any, look at the other settings around it and take a guess where the document is referenced in any of the project settings files.
Essentially, VC does a lot of file checking at project save time so if it tries to check a file that is inaccessable there may be a long timeout before it regains control.
Paul
Try searching through your project and workspace files (they are text files but DONT edit them directly). Look for references to files that are in an inaccessable location on your network. Perhaps they will refer to a location to a mapped dtive that no longer exists.
If you find any, look at the other settings around it and take a guess where the document is referenced in any of the project settings files.
Essentially, VC does a lot of file checking at project save time so if it tries to check a file that is inaccessable there may be a long timeout before it regains control.
Paul
I work with VS2005 on the daily basis, and never encounted slow saving problem, but I'm not saving it to a share either. I would think saving to the share is the problem. I would try to move all the files to the local drive and see if it is still a problem.
On a side note, why are you saving it to a share? Are you using the share as your "source control" replacement? If so, you should use a real source control instead. You can download Subversion for free and use TortoiseSVN with it, it's pretty nice and very easy to use.
You can get Subversion here:
http://subversion.tigris.org/project_packages.html
TortoiseSVN here:
http://tortoisesvn.tigris.org/download.html
Cheers,
Aaron
http://aaronfeng.blogspot.com
On a side note, why are you saving it to a share? Are you using the share as your "source control" replacement? If so, you should use a real source control instead. You can download Subversion for free and use TortoiseSVN with it, it's pretty nice and very easy to use.
You can get Subversion here:
http://subversion.tigris.org/project_packages.html
TortoiseSVN here:
http://tortoisesvn.tigris.org/download.html
Cheers,
Aaron
http://aaronfeng.blogspot.com
ASKER
Aaron,
Thanks for the response, I'm saving to a share for two reasons:
1.) Though when I click play it runs locally however the share it saves to is actually on our development IIS server where other non-programmeres can look at features we're adding.
2.) The share is backed up nightly as well as the server running Shadow Copy. It's not really for source control as much as to not lose a days work if my hard drive would fail (which we happened to get a bad batch of drives from Dell 6 months ago and had every local drive in the department fail at one point or another).
Paul/fostejo, thanks for the suggestions, I'll get on those as soon as I get in tomorrow. Thanks for the responses thus far.
IUFITS
Thanks for the response, I'm saving to a share for two reasons:
1.) Though when I click play it runs locally however the share it saves to is actually on our development IIS server where other non-programmeres can look at features we're adding.
2.) The share is backed up nightly as well as the server running Shadow Copy. It's not really for source control as much as to not lose a days work if my hard drive would fail (which we happened to get a bad batch of drives from Dell 6 months ago and had every local drive in the department fail at one point or another).
Paul/fostejo, thanks for the suggestions, I'll get on those as soon as I get in tomorrow. Thanks for the responses thus far.
IUFITS
Hi,
Sounds a problem not related directly to VS, but to windows instead.
If you notice in Windows Explorer that Windows take a time to open the combobox for Address, it is a sympthom of excess of things to Windows execute. Probably old applications, even unisntalled, rest register and paths that are time consuming and not necessary at all. As this and other time consuming unuseful settings remains, mostly in machines that we receive from elsewhere from other users, the best is to clean your PC. A definitive and racdical cleaning. The only that guarantees that your machine will be really clean:
Reinstall windows and visual studio. And, if possible, dont use the PC to any other function that code development.
I had a similar problem and that was the definitive solution.
Jose
Sounds a problem not related directly to VS, but to windows instead.
If you notice in Windows Explorer that Windows take a time to open the combobox for Address, it is a sympthom of excess of things to Windows execute. Probably old applications, even unisntalled, rest register and paths that are time consuming and not necessary at all. As this and other time consuming unuseful settings remains, mostly in machines that we receive from elsewhere from other users, the best is to clean your PC. A definitive and racdical cleaning. The only that guarantees that your machine will be really clean:
Reinstall windows and visual studio. And, if possible, dont use the PC to any other function that code development.
I had a similar problem and that was the definitive solution.
Jose
IUFITS:
From what you are describing it sounds like you are using the tools in a way they were not intended.
1.) Though when I click play it runs locally however the share it saves to is actually on our development IIS server where other non-programmeres can look at features we're adding.
A build script would be a much better way of handling this, it can easily be integrated into a continuous integration server if you have many programmers working from the same directory. The main reason Is ay this is that when ytou broke your local copy you would not break the copy they were viewing as well.
2.) The share is backed up nightly as well as the server running Shadow Copy. It's not really for source control as much as to not lose a days work if my hard drive would fail (which we happened to get a bad batch of drives from Dell 6 months ago and had every local drive in the department fail at one point or another).
Again a continuous integration server combined with source control is much better suited for this. Generally you make a "volatile" section of source control that only has the requirement of compiling, then people check in often (once they have a version that compiles) .. this allows true source tracking as well as back ups etc. You then promote this volatile section once it is agreed that "we think it should be working"
As aaron has pointed out the most likely problem is the share. When you are dealing with resources off of a network there is alot of overhead added and the build process should be moving quite a few files (it also adds security overhead). The biggest problem I think you will run into has to deal with file locking if having multiple developers working concurrently .. there are all sorts of funky things that can happen.
From what you are describing it sounds like you are using the tools in a way they were not intended.
1.) Though when I click play it runs locally however the share it saves to is actually on our development IIS server where other non-programmeres can look at features we're adding.
A build script would be a much better way of handling this, it can easily be integrated into a continuous integration server if you have many programmers working from the same directory. The main reason Is ay this is that when ytou broke your local copy you would not break the copy they were viewing as well.
2.) The share is backed up nightly as well as the server running Shadow Copy. It's not really for source control as much as to not lose a days work if my hard drive would fail (which we happened to get a bad batch of drives from Dell 6 months ago and had every local drive in the department fail at one point or another).
Again a continuous integration server combined with source control is much better suited for this. Generally you make a "volatile" section of source control that only has the requirement of compiling, then people check in often (once they have a version that compiles) .. this allows true source tracking as well as back ups etc. You then promote this volatile section once it is agreed that "we think it should be working"
As aaron has pointed out the most likely problem is the share. When you are dealing with resources off of a network there is alot of overhead added and the build process should be moving quite a few files (it also adds security overhead). The biggest problem I think you will run into has to deal with file locking if having multiple developers working concurrently .. there are all sorts of funky things that can happen.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Oh one last thing, check out your task manager and ensure you have enough physical memeory compared to the amount of actual memeory usage. Unless you have AT LEAST 512MB ram the vshost process will end up thrasing your hardrdive.
Check you have defragged your drive and prefreably have at least 1GB ram.
Check you have defragged your drive and prefreably have at least 1GB ram.
I've read that if you leave the 'dynamic help' window open it slows things down a lot. I'm not positive but you can try it out, if you often leave it open.
ASKER
Disabling Symantec Anti-Virus (built on the same engine as Norton I believe) on those directories while I was using them fixed the issue. Thanks everyone.
Yeah you are correct, Norton=Symantec (one of them bought the other one at some point but they never truly merged the names).
I have seen this issue in hundreds of poorly performing networks... Other Sys-admins take note! If you have AV on Every machine you dont need each AV scanning other machines files!
Thanks IUFITS, glad to be of help..
I have seen this issue in hundreds of poorly performing networks... Other Sys-admins take note! If you have AV on Every machine you dont need each AV scanning other machines files!
Thanks IUFITS, glad to be of help..
It could be that VS is attempting to look for a network based location in the ProjectMRU list as described here: http://forums.asp.net/thread/1184416.aspx
cheers,