views:

253

answers:

3

When creating new web sites with Visual Studio .NET, the projects are created at the default web site location, e.g. c:\inetpub\wwwroot\myapp. Likewise, when creating msi packages for such applications using a Visual Studio Web Deployment Project, a custom action will be used to determine the folder location of the default web site and the files installed to that location.

When I look at other virtual directories in my current IIS installation, I see these logical paths:

IISHelp: c:\windows\help\iishelp Reports: c:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportManager ReportServer: c:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer crystalreportviewers12: C:\Program Files\Business Objects\Common\4.0\crystalreportviewers12

My question is: Is c:\inetpub\wwwroot really the correct location to use, even if the virtual directory is created under the default web site? Would it not be more appropriate to install the files to c:\Program Files\myapp, create a virtual directory, and then point that virtual directory to that folder (making sure that the proper permissions have been assigned to the folder, as it will not inherit any permissions from c:\inetpub\wwwroot)?

Any links to official guidelines on this topic would be most welcome.

A: 

It really doesn't matter as long as you tell IIS the path. I stick to the inetpub/wwwroot directory. That way I can apply certain security sites to that path. It also helps establish various security users such as ASP.net and the network user account.

JonH
I am not sure what you mean by "that way I can apply certain security sites to that path". This is a deployment situation and we are just talking about a folder location, so if there are any security settings that need to be applied, then surely those should be set by the installer and not rely on any default settings on the parent folder?
Joergen Bech
A: 

One of the main reasons to stick to the standard c:\inetpub\wwwroot\ directory for placing your applications is Windows has set up the permissions properly on this directory to propagate to subdirectories for web applications. I would recommend sticking with this standard so you have a logical central point for your various sites/applications. It's really just organized.

Now I won't deny that you can set up additional root directories, and sometimes this is needed at various client/customer sites if you have separate hard drives for particular sites, etc. Here's a link regarding setting up root directories for .net:

http://msdn.microsoft.com/en-us/library/ha2y9493.aspx

sw
A: 

I tend to keep vdirs pointing to the same folder as the source code, something like C:\source\mywebapp. This way everything is in the one folder and source control is much cleaner.

Another reason could be that your server admin (or you) prefer to keep just OS stuff on C: and keep data or inhouse apps on D: (or some other drive). This can make it easier to maintain or might just be policy.

I suggest not concerning yourself about where your vdirs are pointed, they are only "virtual" after all. Just make sure that your content is stored in a safe and logical place.

AUSteve
Yes, I point them elsewhere at development time. The question is about best practices at deployment time. I guess I am just accustomed to seeing the files at the default location when using all the defaults in Visual Studio (+ deployment projects), but seeing that major packages doing something different gave me reason to challenge those assumptions.There are plenty of guidelines for file placement when developing Windows client applications, but I have yet to find any guidelines dealing with this issue.
Joergen Bech
File placement is far more important for client apps since they will be deployed to to a large number of machines which are often not fully under the control of the developer. Websites are generally only deployed to a small number of machines which are tightly controlled by the developer (or admin team). Choose a strategy, follow it for every website you develop and document for those who follow.
AUSteve