Since IIS does a great job with host headers, I skip the virtual directory
approach altogether. If I'm creating a new website, called "foo.com", my
new project setup approach is generally;
DNS config (internal)
+ Create new internal DNS entries pointing at the dev box, for
convenience.
In the foo.com example, the two entries would typically be "foo"
(representing DEV), and "test.foo" (representing TEST).
DNS config (external)
+ Create new external DNS entries, pointing at production. Typically
"foo.com" and
www.foo.com in the above example.
+ Optionally, create new entries for TEST and DEV, e.g. "test.foo.com",
and
"dev.foo.com", for client access. Point these as the DEV and TEST boxes.
Webserver configuration
+ Create new directories, usually c:\inetpub\dev\foo.com,
c:\inetpub\test\foo.com, c:\inetpub\prod\foo.com
+ Create a new website (not a new virtual directory) on the server.
Typically I create three versions, one each for DEV, TEST, and PROD. They
point at the directories identified above. The hostheader for DEV is
"foo";
the hostheader for TEST is "test.foo", and the hostheaders for PROD are
"foo.com" and
www.foo.com.
Project creation
+ Create the project. Identify
http://foo as the develoment site, locate
its network directory (e.g. \\devserver\inetpub\dev\foo.com). All is
good.
I've settled on this approach for a lot of reasons;
+ Easy to work with. Anyone on the network can type "foo" in their
browser
and arrive at the DEV site, or "test.foo" and arrive at the TEST site.
That's convenient.
+ Easier to move sites across servers when necessary. Simply update the
DNS and the project files weather it reasonably well.
+ Avoids virtual directories completely. Virtual directories always
seemed
a bit of an anomaly to me, because I'd rather setup a website called
"foo.mydomain.com" than
www.mydomain.com/foo. It makes more sense to me,
I
get to have multiple domain names for the same site; it generally feels
more
flexible.
Food for thought;
/// M