** EDIT **
I since had this problem start reoccuring even after the changes I specified below. I finally came across a knowledgebase article on Microsoft's site that deals directly with this issue. I took the advice from that article and applied the required changes to BOTH the server and my workstation environment. It seems to have cleared up the problem and the speed of which I am able to compile over the network has also increased
If anything further changes, I'll edit this post again. Keep on reading for background information.
Here's the link to the Microsoft Knowledgebase article: http://support.microsoft.com/kb/810886.
--- Original Post ---
*Phew* What a long title for a blog entry. My apologies, but I know it will help to push this entry up in the search engines so that more folks can find this simple solution.
So, to start off I'll give a bit of background information on the platform I'm running:
I experienced this error in Visual Studio 2010 while working on several ASP.NET sites hosted on my virtual Windows Server 2003 system. I have my projects setup in such a way that I share my virtual server's \inetpub\ folder on my local network so that I can directly load the web sites I develop straight from the server into Visual Studio 2010 (I actually have the folder mounted as my W:\ drive in Windows 7, but that's beside the point).
In Googling / Binging for an answer I came across multiple posts stating that I should simply "not" host the web project on a UNC path and instead bring a local copy over to my development machine to work on. Since I've never had to do that in the past and since I find my setup works perfectly fine for me I didn't settle for that answer. I did, however, come across one poster who stated that he reset the Application Pool for the offending site and everything was back to normal.
So, I did just that! I logged into my virtual Windows Server 2003 environment, loaded up IIS Manager, stopped the web site hosting the solution, stopped the Application Pool hosting the web site and then retarted both in the opposite order (started Application Pool, started web server). Voila! All is well again. It really is THAT simple.
I hope this helps others fighting with this silly error! I had been experiencing it off and on for a couple of weeks and then suddenly it started happening every time I attempted to build any web project in Visual Studio 2010. I'm glad to see the error had nothing to do with Visual Studio and everything to do with the IIS environment.
Now, I realize that in a production environment this may not seem like the best solution (although it doesn't require a full reboot of the server). However, if you were experiencing this problem on a production server then you should really be asking yourself the question "Why on Earth am I accessing production copies of my web site source files from Visual Studio?". I've recently moved over to using SVN for most projects and designating production server file locations as check-out locations. This makes updating the production servers much easier... but that's a whole different blog post.