I work in this scenario every day. I have two applications that have an
externally facing access point on our DMZ and one on the intranet. The
applications are identical internally and externally with the exception of
the authentication mechanism. While I have considered the idea of having a
single point for deployment, I prefer to redeloy the application for both
environments for many reasons including the ones that Rick discussed.
Firewalls complicate any deployment and with ASP.NET, IIS, and database
access, you're adding a lot of complexity and configuration for what would
notmally be a simple deployment. Keeping everything in sync between the
external site and the intranet site and ensuring that the firewall is
configured to allow communication between all involved machines using the
correct protocol(s) just to have a single deployment point can be a huge
undertaking. If your external application is a seperate deployment, you can
have the firewall opened for communication between the host machine and the
database server and leave it at that. Using a single deployment point in
this case means opening many ports to [possibly] many machines and firewall
administrators are often weary about opening some of those ports.
The other big problem is (as Rick said) what if something does need to be
different between the two environments? In my case, I have a different
authentication for each environment. How about if some pages contain
sensitive information that absolutely must not be available externally? If
anything needs to differ between the apps and you use the single deployment
point, you're hosed.
One other thig is what if the machine hosting the deployment point goes
down? Both access points are rendered inaccessible. Even if the deployments
are identical, having the seperate deployments will allow you to keep some
level of functionality should the need arise provided that your data stores
are on another machine than your deployment point.
HTH,
Dave Fancher
http://davefancher.blogspot.com
"Manohar Kamath" wrote:
Rick,
The assumption is that there is nothing that is URL-specific in the code,
the apps are identitical except for how they are called via URL. Even the
data they access are the same. I am trying to see if there is anything else
I might be missing -- e.g. FrontPage (my guess is we won't enable FP
extensions).
Thanks!
--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
"Rick Strahl [MVP]" <ri********@hot mail.com> wrote in message
news:uQ******** ********@TK2MSF TNGP12.phx.gbl. .. Manohar,
This sounds kind of like a scary scenario. it will work as long as the
pages will *truly* stay in sync and there aren't any other resources that need
to be used or configured separately on the two sites (ie. web.config, config
settings etc.).
I suppose you can figure which data to access based on the site name or
other pathing, but still as soon as there's something app specific in
either of these directories the whole thing will go bad.
Be careful <g>...
+++ Rick ---
--
Rick Strahl
West Wind Technologies
www.west-wind.com
www.west-wind.com/weblog
"Manohar Kamath" <mk*****@TAKETH ISOUTkamath.com > wrote in message
news:uI******** ******@TK2MSFTN GP15.phx.gbl... Hello all,
Consider that you have an ASP.NET application you have deployed as
www.somesite.com. If I would like to create an intranet site with the same code (say http://intranetsite/ for use within the company firewall) , I
could just point another IIS web site to the same code location, without
having to re-deploy. I have tried this, and it works fine.
However, I would like to know if anyone has run into issues in this
scenario. Assume that the code is not dependent on URL, and the two sites share the same resources, but are logically independent of each other.
Thanks!
--
Manohar Kamath
Editor, .netWire
www.dotnetwire.com
