It occurs to me that for nearly a decade now Microsoft has been championing the 'thin client.' Saying things like "the network is the OS" and wanting businesses, developers and others to move to heavy-hitting powerful server platforms that would contain most of the programs and information, and the users would have more watered down desktops which would access most of their applications (office, mail, etc) from the server.
So imagine my shock, surprise and stream of words filthy enough to make a sailor blush when I kept getting this error while trying to publish a website:
Error 5 An error occurred loading a configuration file: Failed to start monitoring changes to '\\[machinename]\[drive]$\[directory]\[website]\bin\ko' because the network BIOS command limit has been reached. For more information on this error, please refer to Microsoft knowledge base article 810886. Hosting on a UNC share is not supported for the Windows XP Platform.
WTF? Hosting on a UNC share is not supported? How the hell can this be? Microsoft touts how Visual Studio 2005 is such a great development platform. How collaboration and all that jazz is great and easy and built right into it. What kind of crack are they smoking? If hosting on a UNC is not supported, how in God's green earth are we supposed to develop web applications? On our desktops? Sure, ok, but what about all that great built-in collaboration? Oh, I guess that baby gets thrown out with the bathwater in this one.
What makes things worse is that this seems to be a rather sporadic error. On top of that, I can run the publish command, get this error with a fold like "ko" (as above) and run it again, making no changes, and it gives me a different folder. Seems almost totally random. Thankfully, all the folders it was complaining about were either 1) localization folders added by their AJAX control toolkit, or 2) App_Theme folders that we weren't using anyway. So I was able to delete all those without causing undue issues with the site.
Checking the KB article the error instructs you to (http://support.microsoft.com/?kbid=810886) doesn't really do much for me. First off, the development server we are using didn't have these keys at all in their registry. The KB article is for windows 2000 server, and we are using Windows Server 2k3. So this article is pointless. Every Google find points back to the same damn MS KB article.
AAAAAAAAARRRRRRRGGGGGHHHHHHH!!!!!
I just had to rant a bit.
Sorry.
17 comments:
I had the same exact problem. VS2005 would get caught up on either my _css or _script reference folders (in any order...) Odd, that neither folder actually contains managed code...
The only fix I found was to temporarily remove the offending directories before the build, then add it back in after the fact.
We can never get even the simplest ASP.NET websites to build/compile/publish across the network. We tried SourceSafe as the "solution", but this was even worse and we had some code get shredded. It shouldn't be this damned hard. For very simple, very quick "contact form only" miniwebsites I still use classic ASP. The resulting code is easier to maintain and publish to our various servers. This isn't the way it should be...but it is. The siren call of Rails is becoming louder and louder for me..
What I've ended up doing is developing on my own machine, then publishing to the server. Which isn't really my choice. We are supposed to be able to hook up to Source Safe when the site is opened from HTTP, but we have never been able to get that to work. I have recently installed VS 2008, but haven't tested this out. I'm hoping we will be able to save/build/publish across the networks much more easily - but I aint holding my breath.
Hi, not sure if you still have the issue, but I found a KB article that appears unrelated but actually solves the "Hosting on a UNC share is not supported for the Windows XP Platform" issue.
If you look at the way ASP .net handles file change notifications (FCNs), its default setting is to create a SMB (Server Message Block) for every directory which soons eats up connections to a UNC server. If you "pool" the SMBs as described in the article below, you don't reach the limit and don't get the error. I use setting 2 to still receive file change notifications:
http://support.microsoft.com/kb/911272
Thanks for the heads up thinster, I'll definitely take a look at that!
Try this: http://www.net-aspect.com/Articles/BIOS-command-limit-error-when-compiling-using-Visual-Studio-on-a-network-share.aspx
Thanks Alejandro! Another possible solution. I need to check these when I have some extra time.
Alejandro's link solved it for me!
Thx.
Ok, it works also for me!
What was the FIX? The link is broken....
Thinster's solution worked for me. Thanks!
I'm having the same problem but the link no longer works that was posted as the solution. Does anyone know what the link contained for instructions?
thinster's link (http://support.microsoft.com/kb/911272) works for me.
thinster's link also worked for me! :D
The link for Alejandro is broken but here's the gist:
Add the following DWORD value to registry key on your local XP development machine:
HKLM\Software\Microsoft\ASP.NET\FCNMode
The following lists possible values for the FCNMode DWORD value and the behavior that is associated with each value.
0 - or greater than 2 - This is the default behavior. For each subdirectory, the application will create an object that will monitor the subdirectory.
1 - The application will disable File Change Notifications (FCNs).
2 - The application will create one object to monitor the main directory. The application will use this object to monitor each subdirectory.
I used 2 and the problem is gone!! Finally!
Brian, excellent comment, too worked thanks!!!!
Hi, this error also occurs while using a network drive mapped to a local computer.
Example: X: => \\mylocalcomputer\wwwroot (refers to c:\inetpub\wwwroot in local machine)
Post a Comment