Related
Not to bore you, I'm gonna make long story short. Two machines, identical systems on them, identical programs (mostly). One has Visual Studio installed, one has ... uhmm, something else.
Sometimes when I try to install applications from let's say a CD, Visual Studio's Just-In-Time Debugger pops up, reports an "unhandled win32 exception in ..." and asks whether I want to debug using "New instance of Microsoft VIsual Studio 2010". If I choose Yes, it runs VS, if I choose No it closes the thing, and I'm back in Windows Explorer.
Which would be ok, except I know the application is perfectly all right, and this way I cannot install it (in this latest cast it was the client from my bank for internet banking and paying bills and such).
So, how do I get rid of that thing (just-in-time debugger)?
I don't want to uninstall VS since I'm using it daily, of course.
Edit 1 :: I tried disabling Just-In-Time debugging in VS's Tools/Options/Debugging/Just-In-Time, then unchecking all three checkmarks, but that just gave another error when trying to run the executable installation program.
An unhandled win32 exception occurred in autorun.exe [some number]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from ...
Check the documentation index for 'Just-in-time debugging, errors' for more information.
Very informative :/
Edit 2 :: The application runs fine on the other machine that doesn't have VS installed. To a large extent software on both machines is the same, with just some minor differences (systems installed from image). Minor differences: notepad2, ++, git, ... some small stuff that is left to dev's own choosing.
I don't want this to sound as rant against VS, since I realize it's taking that tone, but I extremelly dislike software that is not self contained and messes other software up. And I had the same problem before with other applications as well. So for now, I'm blaming VS.
If necessary, I'm willing to disable all kinds of debugging for this thing to work permanently (mostly use print statements anyways), if that will help. And if it possible.
I just had this problem today with Visual Studio 2013. This MSDN article:
Just-In-Time Debugging in Visual Studio works for me. In my case, I just rename Debugger to Debugger_del and DbgManagedDebugger to DbgManagedDebugger_del.
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
I am adding this response even though this is an old topic because I have just spent most of the day on this very issue and finally solved it. Every solution I found focused on disabling or turning off JIT debugging in Visual Studio, deleting keys from the registry or changing IE script debugging settings. But if you don't have a registered copy of VS, you have a problem. Of course, many of the solutions work in different ways but then you are left with the error above "no installed debugger has just-in-time debugging enabled" which no-one seems to have an answer for. However, the answer is not to disable JIT but rather stop server side debugging in your application. Unless you actually want to do server side debugging it is not necessary for it to be on.
It makes complete sense to me now because I had server side debugging turned on in ASP. Before installing VS, it made no difference because no debugger was assigned to handle the bugs so they were sent to the browser. Once I installed VS, JIT took over and did what tit was supposed to do.
So the quick answer, open IIS, click on default sites or your sites and in your application settings, ASP in my case, turn off server side debugging!!
It may not be everyone's answer, or even the solution to the above problem, but hope it provides more insight to this problem and help someone else.
regarding the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and SOFTWARE\WOW6432Node\Microsoft, I could only change the Auto value from 1 to 0 and it worked.:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
REG ADD "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
If you're running the same software on two machines and it's crashing on one(which is what's happening if the debugger is starting) then you probably have something else going wrong on your machine. It could be that you've got driver incompatibility issues, or that some of the other software you have installed on the machine has incompatible versions of dll's...
You need to try to eliminate as many of the differeces as you can (easier said than done, I know)... If you copy the contents of the CD onto a local disk, does that help? If you shutdown your virus checker while you install the software does that help? Does it help if you turn the network off? You've said that both machines have 'mostly' the same, software, what happens if you uninstall some of the differences? Have both machines been patched to the same level?
As Visual studio is trying to start up when you have issues, have a look at the call stack and see what dlls are loaded, print it out... run some of the other software that crashes on that machine and do the same thing... look for any common libraries and do a comparison between the machines to see if they have the same version of the libraries...
Of course it could also be that it's a hardware issue (I've had intermittent failures before now because one of my drives was getting ready to fail and others because my graphics chip was running too hot)...
As I said, not really an answer, but some things to consider...
If all else fails... you're probably stuck doing your bills on the other computer (although another experiment might be to create a VPC on the broken pc to see if it worked then)...
Right click on Project--Properties. Select the 'Web' tab. Under Debuggers, check 'Silverlight' (beside ASP.NET that is already checked).
Now visual studio won't debug your javascript because fortunately it can't debug Silverlight and javascript at the same time. You can now attach your javascript to the browser debugger.
This problem was appearing when I started pdf viewer. I reinstalled this program in other folder (another disc in comp) and in my case it worked.
Occassionaly, but fairly often, for no apparent reason, VS 2012 will lock up with a dialogue that says, "Waiting for a background operation to finish". E.g. this may happen during a plain old code edit, not on explicitly invoking any IDE command.
What causes this, and is there anything I can do about this?
I am running ReSharper 7, and I am not the only one I know experiencing this.
I was having the same problem, especially in cshtml pages. I found this page: https://devblogs.microsoft.com/aspnet/visual-studio-11-beta-razor-editor-issue-workaround that suggests changing the indent option in Tools > Options > Text Editor > HTML > Tab to Smart instead of Block. In my case it was already set to Smart and changing it back to Block fixed the problem.
Update: I was wrong, that didn't fix the dialogue, it just delayed it until I copied or pasted. What finally worked for me was to go to Tools > Import and Export Settings... > Reset all settings.
Possibly related question: Visual Studios 2010 - Asp.net MVC 4 Beta - long delays on paste and frequent crashing
It is a very generic diagnostic. It is triggered by COM, heavily used in Visual Studio to implement extensibility. The underlying trigger is the IMessageFilter interface. The trigger occurs when COM marshals a method call to another thread and that call doesn't complete for 60 seconds.
There's little value in the actual notification, it is telling you something you already know. By the time 60 seconds have passed, you typically already have noticed things are not working well. Short from the wee bit of useful knowledge that Visual Studio isn't actually completely dead. The call however has to complete before VS gets usable again. There's little you can do but tap your foot and wait.
This problem is almost always caused by an add-in. Resharper is certainly a good candidate. You find the trouble-maker by disabling the add-ins one-by-one until the problem disappears. It is the kind of problem that's common with new versions of Visual Studio, it takes the add-in vendors a while to get the bugs and hangups ironed out. Contact the vendor for support and in general look for updates that may solve the issue.
Deleting the Solutions "suo" file worked for me.
I was having the same problem and in my case it was DevExpress.
It seemed to hang Visual Studio everytime I did a copy or cut operation, bringing up the message:
"Waiting for a background operation to finish".
Turns out it was actually doing a one off task in the background and it really was taking a while to do it (over 5 minutes).
Perhaps if I had waited normally, it could have gone away, but what finally fixed it was to bring up the Toolbox into view (was hidden/collapsed), which in turn brought up a window saying:
"adding [SomeDevExpressAssemblyNameHere].dll"
this kept updating itself with the name of every dll required by DevExpress to populate the toolbar.
This way I could see the operation progress and after it finished I could use copy/cut paste again as usual.
Hope this helps.
For me the fix was to update the Web Essentials 2012 to version 1.8.
The problematic version was 1.6
Tools > Options > Text Editor > HTML > Tabs -> Identing -> None settings solved this problem for me.
This fixed it for me:
Tools > Options > Text Editor > HTML > Miscellaneous
Uncheck the option "Auto ID elements on paste in Source View"
I will post an update if the problem comes back.
I had this problem for a couple of days, tried uninstalling and reinstalling my visual studio 2012 ultimate edtion SP3...
Still didn't work.
So I deleted all my extensions (git tools for VS 2012 and Nuget Package downloader),
restarted my VS and it worked liked a charm again!
Hope it works !
Good luck!
I experienced this problem while running visual studio in a virtual machine - Virtual Box 4.2 running on Mac OS X Mountain Lion, hosting a fresh Windows 7 install with nothing else installed but Visual Studio. I found that the problem was caused by 2 separate issues.
Firstly, my project was on a folder shared from the host OS. In other words, on the Windows Guest, my project appeared on a network drive. So opening the project in Visual Studio from a network drive seemed to cause this problem because the problem went away when I copied the project onto the C drive of the Windows VM and opened it in Visual Studio from the copy on the C drive.
Secondly, I began to experience the problem again when the hard drive on the virtual machine was getting full. I had about 1GB free space available on the hard drive. When I increased the size of the hard drive on the virtual machine, this issue went away.
Just reproduced similar problem with Codemaid add-on. Found this conversation:
There's a lot of details in this issue, but to try and recap the issue
is that the VS2012 C++ API introduced a deadlock issue when the API is
accessed from a UI thread (e.g. a WPF context like Spade). It wasn't
an issue in VS2010, and Microsoft has fixed it going forwards for
VS2013 but they will not be patching it for VS2012.
Seems to indicate that a fix (for Codemaid) should be coming:
Please keep an eye on this thread for the ongoing resolution of the
issue. It ties in to that larger rewrite so I've been building towards
it by adding a lot of unit tests first to help ensure functionality
remains consistent after the changes.
For me it seemed to be related with the razor syntax, since I only had it on one particular file.
For example if I put the following code in one line I had the described issue.
#section BodyClassName {note}
But when putting the closing parenthesis on the next line the issue went away
#section BodyClassName {note
}
Kind regards
Stijn
Far from an ideal solution, but please trying running visual studio in administrator mode
i tried virtually everything, and this was the only thing that worked for me
Open Visual Studio, create a new MVC application, close the new application, open the old application and it works!
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS or the other process if it is
http://geekswithblogs.net/sevenfortytwo/archive/2006/11/23/97947.aspx
RUN> iisreset
Now it is working fine with VS 2012
i think i have found a clue! Every thing is ended to dcomcnfg.exe!
Open it and go under following path:
Component services>computers>my computer>dcom config
after click on dcom you'll see many warnings depend on amount of components on your pc.
Click yes on each message box in order to add correct record for dcom.
I found that VS also loads packages during the "background operation". You can remove unneeded extensions to make the operation faster.
I have it fixed weeks ago after I turn TeamViewer 8 Clipboard Sync off! now it appears back with no reason so I tried reset all settings and it worked for me.
I was having the same problem and running VS as an administrator seems to have done the trick for me (I had posted a similar question at Visual Studio 2012 Express Hangs with Message "Waiting for Background Operation to Complete" on Format Document Command that was marked as a duplicate for this one so I figured I would share here as well).
For me, it was Resharper addon opening a dialog which didn't show. I only found the dialog icon in the hidden icons menu on the task bar. When i got rid of the dialog, Visual Studio returned to normal immediately.
Not to bore you, I'm gonna make long story short. Two machines, identical systems on them, identical programs (mostly). One has Visual Studio installed, one has ... uhmm, something else.
Sometimes when I try to install applications from let's say a CD, Visual Studio's Just-In-Time Debugger pops up, reports an "unhandled win32 exception in ..." and asks whether I want to debug using "New instance of Microsoft VIsual Studio 2010". If I choose Yes, it runs VS, if I choose No it closes the thing, and I'm back in Windows Explorer.
Which would be ok, except I know the application is perfectly all right, and this way I cannot install it (in this latest cast it was the client from my bank for internet banking and paying bills and such).
So, how do I get rid of that thing (just-in-time debugger)?
I don't want to uninstall VS since I'm using it daily, of course.
Edit 1 :: I tried disabling Just-In-Time debugging in VS's Tools/Options/Debugging/Just-In-Time, then unchecking all three checkmarks, but that just gave another error when trying to run the executable installation program.
An unhandled win32 exception occurred in autorun.exe [some number]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from ...
Check the documentation index for 'Just-in-time debugging, errors' for more information.
Very informative :/
Edit 2 :: The application runs fine on the other machine that doesn't have VS installed. To a large extent software on both machines is the same, with just some minor differences (systems installed from image). Minor differences: notepad2, ++, git, ... some small stuff that is left to dev's own choosing.
I don't want this to sound as rant against VS, since I realize it's taking that tone, but I extremelly dislike software that is not self contained and messes other software up. And I had the same problem before with other applications as well. So for now, I'm blaming VS.
If necessary, I'm willing to disable all kinds of debugging for this thing to work permanently (mostly use print statements anyways), if that will help. And if it possible.
I just had this problem today with Visual Studio 2013. This MSDN article:
Just-In-Time Debugging in Visual Studio works for me. In my case, I just rename Debugger to Debugger_del and DbgManagedDebugger to DbgManagedDebugger_del.
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
I am adding this response even though this is an old topic because I have just spent most of the day on this very issue and finally solved it. Every solution I found focused on disabling or turning off JIT debugging in Visual Studio, deleting keys from the registry or changing IE script debugging settings. But if you don't have a registered copy of VS, you have a problem. Of course, many of the solutions work in different ways but then you are left with the error above "no installed debugger has just-in-time debugging enabled" which no-one seems to have an answer for. However, the answer is not to disable JIT but rather stop server side debugging in your application. Unless you actually want to do server side debugging it is not necessary for it to be on.
It makes complete sense to me now because I had server side debugging turned on in ASP. Before installing VS, it made no difference because no debugger was assigned to handle the bugs so they were sent to the browser. Once I installed VS, JIT took over and did what tit was supposed to do.
So the quick answer, open IIS, click on default sites or your sites and in your application settings, ASP in my case, turn off server side debugging!!
It may not be everyone's answer, or even the solution to the above problem, but hope it provides more insight to this problem and help someone else.
regarding the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and SOFTWARE\WOW6432Node\Microsoft, I could only change the Auto value from 1 to 0 and it worked.:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
REG ADD "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
If you're running the same software on two machines and it's crashing on one(which is what's happening if the debugger is starting) then you probably have something else going wrong on your machine. It could be that you've got driver incompatibility issues, or that some of the other software you have installed on the machine has incompatible versions of dll's...
You need to try to eliminate as many of the differeces as you can (easier said than done, I know)... If you copy the contents of the CD onto a local disk, does that help? If you shutdown your virus checker while you install the software does that help? Does it help if you turn the network off? You've said that both machines have 'mostly' the same, software, what happens if you uninstall some of the differences? Have both machines been patched to the same level?
As Visual studio is trying to start up when you have issues, have a look at the call stack and see what dlls are loaded, print it out... run some of the other software that crashes on that machine and do the same thing... look for any common libraries and do a comparison between the machines to see if they have the same version of the libraries...
Of course it could also be that it's a hardware issue (I've had intermittent failures before now because one of my drives was getting ready to fail and others because my graphics chip was running too hot)...
As I said, not really an answer, but some things to consider...
If all else fails... you're probably stuck doing your bills on the other computer (although another experiment might be to create a VPC on the broken pc to see if it worked then)...
Right click on Project--Properties. Select the 'Web' tab. Under Debuggers, check 'Silverlight' (beside ASP.NET that is already checked).
Now visual studio won't debug your javascript because fortunately it can't debug Silverlight and javascript at the same time. You can now attach your javascript to the browser debugger.
This problem was appearing when I started pdf viewer. I reinstalled this program in other folder (another disc in comp) and in my case it worked.
I have a brand new VS2010 installed on a Win2008R2 machine.
I started getting this error when debugging a WCF service project:
"Attempted to read or write protected
memory. This is often an indication
that other memory is corrupt."
When I started developing a web site a week later, this became consistent - I can't debug it.
The stack dump reads:
at
Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection
conn) at
Microsoft.VisualStudio.WebHost.Server.OnSocketAccept(Object
acceptedSocket) at
System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object
state) at
System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback
callback, Object state, Boolean
ignoreSyncCtx) at
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at
System.Threading.ThreadPoolWorkQueue.Dispatch()
at
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I tried searching online, and some recommend turning off the "Suppress JIT Optimizations" in the Debugging options - this dos not seem to make a difference.
Clearly the problem is with the built in web server. But am I doing something wrong? Is there something I can do? Or is this a known bug?
Thanks for your time,
Guy
Update 12/31: Today I tried using CassiniDev as a replacement to the original VS2010 WebServer - exact same result. My suspicion is that there's some internal conflict between VS2010, Windows Server 2008R2 and maybe the fact that it's a 64 bit OS. I switched to using IIS as my debug server - and that seems to work, with some annoying side effects.
My conclusion: do not use a 64 bit server system as your dev machine. Develop on 32bit - deploy to 64bit.
Side conclusion: there are some scenarios Microsoft's QA doesn't test.
Well, here's the sad truth, and I verified it with someone who works for Microsoft, with these very same technologies. I just triggered some sort of Cassini bug. He suggested I try installing VS2010 SP1 beta (which I cannot do since my code is due in production). His other suggestion was to try IIS Express. MS is trying to move people over to IIS Express and provides it as part of their web platform installer - so it stands to reason they will not be spending too much time plugging Cassini bugs.
Since I was using a 2008 server, I just added IIS (takes less than a minute), created a virtual directory (the VS project page allows you to do it with one button click) and I'm now successfully debugging on IIS. Not the result I wanted, but you can't always get what you want :)
Installing .Net Framework 3.5 fixed this exact problem for me.
Hope that helps! Sorry I can't offer any additional insight as to what exactly was going wrong with cassini, but I suspect it was missing a library or two.
====
Update:
Seems to have helped (no longer crashes on the first request), but upon further use I've come across another place where the same error crops up.)
====
Update:
And now I can't recreated it anymore. Best of luck, and if you discover any more please post!
The thing that gets my attention is Win2008R2 and Cassini.
I'm just guessing, but it makes me think that it could be a permission issue.
Is it possible that your Win2008R2 machine is locked down more than your average developer machine (the average developer machine being XP / Vista / Win7 etc).
Perhaps Cassini when launched under your user account on Win2008R2 does not have enough permission to do its thing. Perhaps it cannot open ports? But I wouldn't think a port issue would cause a crash. Or perhaps it doesn't have access to the temporary directories it needs?
Perhaps your user account is denied the permission to debug on the local security policy? But i'm not an admin, so i'm not certain on this.
Maybe try launching visual studio as an Administrator (just incase, to help you investigate the problem).
Or perhaps try starting your site without debugging to help see if it's some sort of permission issue with debugging processes.
I came across this, it's from some time ago talking about Windows 7 and Cassini. http://msmvps.com/blogs/rfennell/archive/2009/01/24/problem-hosting-wcf-using-cassini-on-windows-7.aspx But it may not of been fixed.
We have tremendous problems with Visual Studio (2008, if that matters) locking up and slowing down when accessing projects over a network drive. It can take several minutes to open a large Web site project through a mapped drive, and saving even a single file can take a minute or more.
I fired up Wireshark and watched the traffic. VS, it seems, requests massive amounts of files from the network -- there's an enormous amount of SMB traffic. I've done some research, and this traffic seems to stem from two situations.
VS has to have everything in its own process to provide Intellisense.
VS needs to have all the source in order to compile the project.
All the advice I've read seems to boil down to the same thing: work locally, not on a remote machine, then push your code to an integration server via source control.
This would sure solve our problems (VS is quite fast working locally), but what if you can't work locally? What if the project and the infrastructure required to run it is too large and complicated to be replicated on everyone's individual machines?
We've gone 'round this problem a couple times, and the only way we can figure to work on these projects is direct access via a mapped drive. However, the VS slowness and lockups are really becoming a problem.
One solution: we installed VS on the server and work on the projects directly on the servers via RDP. Seriously.
So, I ask:
What does everyone else do? Do you work via the network, or do you replicate projects locally? If remotely, do you suffer from VS performance issues.
We work locally and use SVN to keep all our code on the server.
I find VS 2008 quite slow working locally sometimes so I wouldn't fancy working on a network share.
Trying to compile over a network share is horribly slow using visual studio. Your start times will be bad as the intellisense database is regenerated. Each compilation has to go over the network multiple times. Linking takes forever.
If you need the output of your compilation on the network, I'd recommend doing your compile locally and defining a post-build command to copy the results to your share.
If, as you say, you cannot pull everything locally then I'd suggest your project is too big and needs to be broken up into more manageable chunks. For a multi-tier application, break it up by tier and invest in some form of continuous integration (e.g. CruiseControl) to automatically build individual pieces. In this way you can work locally on an particular piece and pull the pre-build portions from CI for the other pieces of the application.
I'm not terribly surprised that using VS to load projects over a network share has performance issues. VS (in any language) is constantly getting information from files in the project. Once you start loading this over a network you're at the mercy of the underlying network connection. All lags and access issues will directly translate into VS having an issue loading file contents.
I would advise copying the solution locally and using some form of source code control to sync the project on the share.
If the code is too complicated to install on everyone's machine, then don't put it on everyone's machine. Does everyone need to have everything in order to do productive work?
I have 79 projects in my solution that I work with. Several hundred thousand lines of code. I pull my source down everyday from TFS and build it; it's a lot of code, but it's a far better solution than trying to work over a network share.
A more legitimate situation of having the source code on a share is when one has a non-Windows host on which a (number of) virtual Windows machine is running.
I have this exact situation where my desktop machine (the host) is running Debian and I use VMware to run various virtual Windows machines (the guests), including one that has Visual Studio installed so that I can target Windows OS's. Having the source code on a Samba share on the host machine has the following pro's:
The source is not duplicated, so there is no way to confuse different copies while working on several virtual machines at the same time.
I have full control over the source from my preferred OS.
I can turn on and off any of the virtual machines, or roll back to a snapshot, without the risk of loosing changes.
I can build (etc.) from the same source on several machines without having to commit changes before the source fully tested (reason: I have to use Subversion <1.5).
The only problem with this setup is that Visual Studio (6,7,8,9) is painfully slow.
I have mounted the partition (on which the share lies) with "relatime" and this works in as far as the disk activity on the share moderate, but Visual Studio keeps the (virtual) network card occupied all the time.
Any solutions to this would be very appreciated.
I encountered similar problems everytime I worked (work = anything else then just copy / paste files) over a network drive. The problem occured with ZendStudio and Eclipse.
Why not use any kind of source control?
When working on Windows based projects I've always worked locally.
Once at a unix shop (AIX iirc) developers would work via NFS mount and checkin/checkout via RCS...
I'm using VS2005 across to a network share and not having any performance issues. However, it is a new server (Windows Server 2008). I don't have any other data points for VS since using it at work is relatively new for me.
However, some datapoints from using Netbeans for previous projects on a network share... Local build time for my project was 2 minutes on Vista, on a fast dual-core AMD 64-bit machine. For a network share project, on a Server 2003 box, it was 20 minutes. Building that same project from an ancient Tablet PC (1ghz, single core) running XP locally was around 5 minutes. Interestingly enough, the Tablet PC could build on the Server 2003 box in the same 5 minutes.
For those asking "why" on the network share. The network share is automatically backed up, archived, etc. Also, that way I can very easily look at the same projects from multiple machines without having to worry about pushing back into the repository, etc. Once you've gone to having your dev stuff on a device where you can get to it from anywhere/anything, you'll never want to do local storage again!
I have performance problems via network anything, they just aren't good enough yet.
I thought it was common knowledge that disk-speed is one of the major "slowness" factors when it comes to using VS in Windows. Most dev machines I've built have had projects located on 10k RPM RAID0 drives, or at least a single 10k RPM drive. And even then it seems slow sometimes. Just the way it is, I suppose, until VS2009/VS2010 fixes it? :)
From my experience, this lag when working on a network share is 99% due to Intellisense. Disable it and you'll see.
disabling Intellisense indeed speeds up saving and opening files trough a UNC share dramatically
http://blogs.msdn.com/saraford/archive/2007/12/03/did-you-know-how-to-turn-off-intellisense-by-default.aspx
but then again, as stated in other comments, you might as well use a good text editor
I've also experienced the problems with performance mentioned above. It seems to vary from project to project, but I did find one way of speeding up performance significantly for some project types.
Following the advice in this article made a previously unusable project on a network location (it would take minutes to open one file) perform almost like a local project. The basic gist is that you need to grant FULL TRUST to the network location:
To grant permission to all your projects in your Visual Studio Projects folder located on the network, follow these 8 steps:
Open Microsoft .NET Framework 1.1 (or 2.0) Configuration which you'll
find under Administrative Tools in the Control Panel.
Expand Runtime Security Policy | Machine, | Code Groups | All_Code |
LocalIntranet_Zone In the right-hand pane, click Add a Child Code
Group.
In the dialog that follows choose Create a new code group and fill in
a Name like Visual Studio Projects.
Optionally, provide a Description for the Code Group. (You'll see the
description when you click a Code Group in the left tree, helping you
identify the various Code Groups you may have) .
In the Condition Type drop down, choose URL
For the URL field, type something like this:
file://YourServer/My Documents/Visual Studio Projects/*
Under Use existing permission set, choose FullTrust (that is, if you
trust your own applications. If you don't, choose a different
permission set or create a new one).
Not sure why this works, but it made a previously unusable NET 2.0 project perform significantly better.
Original article: http://imar.spaanjaars.com/364/how-do-i-allow-my-visual-studio-net-projects-to-run-from-a-network-location
I was having the same problem. I have a local copy of our build system, which expects certain drive letters, and was also experiencing slowness.
I have solved the problem by adding the following registry keys:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices]
"R:"="\DosDevices\D:\devel\build
"S:"="\DosDevices\D:\devel\src"
Note that the double '\'s above are part of the .reg file format. When using regedit use single '\' throughout.
My build times were divided by 3. :)
I found the info in the wikipedia article on the SUBST command.