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.
LVL 3
IUFITSAsked:
Who is Participating?
 
lojk.Net and Infrastructure ConsultantCommented:
If you are using something like Norton Antivirus (or any AV for that matter) client AND server, ensure that you either omit .exe and .dll from the scan or better still disable scanning of network files from the 'Advanced' Button on the client and server side.

Also Sysadmins often forget to defrag their whizz-bang raid arrays, bringing their average performance way below what they should be (and forget to disable scanning of network files on the server side AV too)

Shadow copy is notorious for locking files and slowing down drives. Get the sysadmin to check that the shadow is done only out of hours where possible.

All that said however i would still recommend running your source locally (and yes there is no substitute or excuse fot not using proper source control) and copying over as required. I know what you are saying about ensuring your source is regularly backed up but heres what i do...

I have a scheduled task that runs approximately every hour that executes a batch file containing the following line

xcopy "C:\Documents and Settings\MYPROFILE\My Documents\Visual Studio Projects\Company Apps\*.*" "\\server02\C\Binaries\Company Apps\Source\*.*" /s /e /d /c /h /y /r

And i also have a link to that batch file in my quick launch menu that allow me to run it on demand as well.

So i get the benefits of running it locally with the added security of automatic backups in case i forget to hit the backup button.

The other perk to this is that you effectively get upto 1 hour 'RollBack', usefull if you start slashing and burning on a form then wish you hadnt... ;-)
0
 
fostejoCommented:
IUFITS,

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,
0
 
IUFITSAuthor Commented:
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.
0
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

 
fostejoCommented:
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,
0
 
PaulCaswellCommented:
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
0
 
aaronfengCommented:
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
0
 
IUFITSAuthor Commented:
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
0
 
Jose ParrotGraphics ExpertCommented:
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
0
 
gregoryyoungCommented:
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.
0
 
lojk.Net and Infrastructure ConsultantCommented:
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.
0
 
prosh0tCommented:
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.
0
 
IUFITSAuthor Commented:
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.
0
 
lojk.Net and Infrastructure ConsultantCommented:
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..
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.