asp.netNOW Q&A
LANGUAGES: None
ASP.NET VERSIONS: 1.0 | 1.1
Connect to Your Server With Shares
Unable to access your Web server using shared drives? Here's how to fix that problem.
By Josef Finsel
Q: I've been using Visual Studio .NET for some time now. I used to be able to connect to the intranet server for new projects using shares, but now the only way I can connect is through FrontPage Server Extensions. I would prefer to use the network share. Why did it suddenly stop working? And how can I fix this?
TC, Mason, Ohio
A: Before answering this question, let's look at the two methods of putting data on the Web server through VS.NET: FrontPage Server Extensions and File-Share Access. The simplest way to define the difference is to say that FrontPage Extensions use HTTP to send files back and forth, making it far easier to maintain Web sites no matter where you happen to be. File-Share Access, on the other hand, requires you to be in the same domain as the Web server you're working on. Other than that, what are the advantages or disadvantages of using one over the other?
If you're using a source-control program such as Visual Source Safe and you have multiple developers, you're better off using File-Share. With FrontPage Extensions, there is only one project that exists, so each developer is working on a single project, checking out and locking a file so they can work on it. The advantage of File-Sharing is that individual programmers can work on files together. According to MSDN, "Using FrontPage Server Extensions as your access method is not recommended for a multiuser development environment."
So unless you're working on a multiuser project, you might as well use FrontPage Extensions. But because this addresses the need to use the File-Share method, let's look at some of the things that might prevent you from connecting to the server.
When Visual Studio is installed, it creates a group on the server called VS Developers that has all the necessary file, share, and IIS permissions required to develop Web projects on that machine. So that's part of what we'll need to check. First make sure the VS Developers group exists and that the developers are members of it. It should have a share named wwwroot$ that probably points to C:\inetpub\wwwroot. The VS Developers group must be granted full access.
The first step, then, is to see if the share exists. Log in to the server locally, go to a command prompt, and type the command NET SHARE. This lists all the shares on the machine, and one of them should be wwwroot$ c:\inetpub\wwwroot (or some other directory). If you don't see this, you need to create it. Open Windows Explorer and find c:\inetpub\wwwroot (or whatever directory you want to use). Now, right-click on it to get a menu, select Properties, and click on the Sharing tab. Name the share wwwroot$. Then click on permissions and remove the group Everybody. Finally, give VS Developers full access to it.
Provided that the developer can use NET USE to invoke a share, VS .NET should be all set. If the developer can't connect using NET USE, you might have other networking/security issues to resolve; you can check out http://msdn.microsoft.com/library/en-us/vbcon/html/vbconWebApplicationSecurityAtDesignTimeInVisualStudio.asp for more information.
But what can cause a functioning file share suddenly to stop working? From my testing, several monkey wrenches can be thrown into the works. Here are a few:
- Adding an additional Web site to the server hosting multiple domains on the box
- Certain security-tightening functions can remove the share due to a security risk
- Moving to NTFS on the Web server that didn't have it installed to begin with
- Changing Active Directory Services to move computers into or out of a domain
Any or all of these seem to wreak havoc on the VS .NET instances. And if you've moved to Win2003, there's another issue you need to be aware of. When VS .NET is creating a new Web site using File-Share Access, it creates a .tmp file in the directory (which, by extension, creates the directory in which the file is created). IIS 6 has tighter security, however, and doesn't allow any file types that haven't been allowed explicitly. VS .NET 2003 gets around this by instead creating an HTML. You can read more about this at http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B327283.
Keep your ASP.NET questions coming to me at [email protected].
Josef Finsel is a software consultant with a global consulting firm and specializes in .NET and SQL Server. He has published a number of VB, .NET, and SQL Server-related articles, and when he isn't hanging around the aspnetpro forums, you can find him working on the syntax for FizzBin.NET, a programming language that works the way programmers have always suspected. He's also author of The Handbook for Reluctant Database Administrators (Apress).
