New ASP.NET proj/multiple IIS Websites

[Sammy]

On a Windows 2003 Server machine that has multiple IIS web
sites, how does one control which web site the new web
application gets created under?

Thank you,
Sammy

 

[Ron Weldy]

You are not alone. I have been wading through the docs myself for the last
few hours trying to understand this better as well. I don't get why this
would be so find documentation on.

- Ron

 

[Ken Cox [Microsoft MVP]]

Not sure, but this might help you with that setup:

Configuring IIS6 for Team Development

http://weblogs.asp.net/kevinha/archive/2004/01/06/48077.aspx

 

[Ron Weldy]

I found this article as well:

http://support.microsoft.com/default.aspx?scid=kb;en-us;320265

I intend to try this technique as soon as I configure my Dev. web server. I
finally found a note buried in the VS.NET readme about configuring a
separate web Server Computer:

http://support.microsoft.com/default.aspx/kb/312779/EN-US/?

I hate when this info is buried in the read me files, especially since I
have had VS.NET installed for a long time now but not used it for serious
ASP.NET development until now.

 

[MWells]

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

 

[Sammy]

Where did you learn this method?

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