I have about 8 production apps, all small functional ones like "Expense
Claiming", "Invoicing", "Reporting" etc.
They are all asp.net and some are 1.1 and some 2.0.
I want to bring them altogether in a way that you have single sign on for
all of them (or even just the 2.0 ones if it makes it easier). How do I do
this, do I create a new ASP.Net solution with multiple projects in it? Do I
use one website in IIS or can it handle the multiple websites I already have
?
I am thinking of creating a single home page with links to all the apps that
will save poeple logging in multiple times."NH" <NH@.discussions.microsoft.com> wrote in message
news:32CD03E9-6A17-40F4-8729-A565DE51647B@.microsoft.com...
>I have about 8 production apps, all small functional ones like "Expense
> Claiming", "Invoicing", "Reporting" etc.
> They are all asp.net and some are 1.1 and some 2.0.
> I want to bring them altogether in a way that you have single sign on for
> all of them (or even just the 2.0 ones if it makes it easier). How do I do
> this, do I create a new ASP.Net solution with multiple projects in it? Do
> I
> use one website in IIS or can it handle the multiple websites I already
> have?
> I am thinking of creating a single home page with links to all the apps
> that
> will save poeple logging in multiple times.
I guess it will depend on several factors:
1) do they all use the same database or, at least, the same database server?
2) how "similar" are they in terms of look and feel?
3) how much effort would be involved in bringing the v1.1 apps up to
v2.0...?
4) how much time would you save in terms of maintenance and future
development, apart from the initial work involved of course, if you had one
single web app...?
I was presented with a very similar situation a few months ago by a new
client. They had a corporate intranet (of sorts!) written in something
called eQuercus (http://www.equercus.com - an absolutely dreadful product!),
plus a handful of small apps e.g. corporate reporting (sales figures etc),
expense claim management, investment fund management, staff directory, old
DOS-based Sun accounts system (yes really!), health & saftey procedures,
staff handbook etc. You get the idea - fairly common corporate intranet
stuff - but, because everything was in separate apps, maintenance was an
absolute nightmare! Loads of data was duplicated across the various systems
and databases, and it was in a right old mess.
In the end, it became obvious that by far the best solution was to
re-architecture a new integral application consisting of a single
multi-schema SQL Server 2005 database, a load of reusable base classes (DAL,
ADSI, Encryption, Mail etc), and a MasterPage / ContentPages scenario for
the presentation layer. The app now consists of a collection of reasonably
discrete but totally linked modules all driven from a single menu, all with
the same look and feel (obviously!), all sharing the same web.config
(obviously!) and no duplication of data.
see answers below...
> 1) do they all use the same database or, at least, the same database server?[/colo
r]
They all use the same database server, and about 4 different databases on
that server.
> 2) how "similar" are they in terms of look and feel?
They are not totally the same in look and feel. There would be effort
involved to standardise.
> 3) how much effort would be involved in bringing the v1.1 apps up to
> v2.0...?
Not a huge amount. Nothing particualary amazing or complex going on in the
apps.
> 4) how much time would you save in terms of maintenance and future
> development, apart from the initial work involved of course, if you had on
e
> single web app...?
Not overly worried about this, I just want to enure the user gets the best
experience.
So anyways, you think the best approach may be to start afresh?
"NH" <NH@.discussions.microsoft.com> wrote in message
news:800B6730-01E9-4612-AF38-C9D695CE8DF6@.microsoft.com...
> They all use the same database server, and about 4 different databases on
> that server.
If you are using SQL Server 2005, I'd be looking to rationalise these
separate databases into one single database with multiple schemas.
> They are not totally the same in look and feel. There would be effort
> involved to standardise.
Sure, but probably not that much, right...? Especially if you were able to
use MasterPage / ContentPages... The "top-and-tail" of the existing pages
could probably drop right into a ContentPlaceHolder with minimum re-work...
> Not a huge amount. Nothing particualary amazing or complex going on in the
> apps.
Well, as you're already using v2 for some apps, you're (probably) going to
upgrade the others at some point - now seems like the perfect opportunity...
:-)
> Not overly worried about this, I just want to enure the user gets the best
> experience.
Don't you think that might be achieved by having all the apps in one place,
with a common look and feel...?
> So anyways, you think the best approach may be to start afresh?
Judging on what you've said, I think the best approach would be to
rationalise the separate apps into a single app. How much that involves
actually "starting again" will depend on how much of the existing stuff you
can re-use...
The single sign on can be accomplished if they are all the same framework
and they can use the same web.config.
And yes. To solve this you have to create a new VS solution with multiple
projects.
What you would have to do is:
1.Create a blank solution
2.Create a "Master App" (or the name of the complete solution) project wich
includes the sign on pages.
3.add all the apps to the VS Solution (note: all sub apps have to be in
subfolders of "master app"
4.Add a reference to every sub app into the "Master App"
5.Delete all web.config. files from all the included apps projects. Leave
only the master app web.config
Remove all subapps virtual folder from IIS. Make them regular subfolders.
When you compile your solution, you'll have only one IIS Application. the
root bin folder will include the dlls from ALL your sub apps.
you'll want to have something like this:
website
/Master App (IIS Application/virtual folder)
/bin (includes all dlls from every app)
/Sub App 1 (normal folder. no web.config)
/SubApp 2 (normal folder. no web.config)
..
/SubApp n (normal folder. no web.config)
web.config
loginPage.aspx
For this to be accomplished, all apps would have to use the same web config.
DOWNFALL: If they use different databases and you have the connection string
in a key in web.config, and that setting is in the same key for all apps,
you would have to make sure that each application uses a different key.
Also, the project names have to be all different (so dlls won't overwrite
each other in the master bin folder)
I've tried it successfully in framework 1.1.4322. Never tried it in 2.0, but
I don't see why it wouldn't.
Not an MCSDE, MVP, MCDE, MSFT or WTF
Not a single certification, besides my degree.
I'm just an engineer with more than 14 years spent in design and
programming.
... FYI
"NH" <NH@.discussions.microsoft.com> wrote in message
news:32CD03E9-6A17-40F4-8729-A565DE51647B@.microsoft.com...
>I have about 8 production apps, all small functional ones like "Expense
> Claiming", "Invoicing", "Reporting" etc.
> They are all asp.net and some are 1.1 and some 2.0.
> I want to bring them altogether in a way that you have single sign on for
> all of them (or even just the 2.0 ones if it makes it easier). How do I do
> this, do I create a new ASP.Net solution with multiple projects in it? Do
> I
> use one website in IIS or can it handle the multiple websites I already
> have?
> I am thinking of creating a single home page with links to all the apps
> that
> will save poeple logging in multiple times.
"Armando Canez" <acanezATintelexionDOTcom> wrote in message
news:uJtOFKJIHHA.3780@.TK2MSFTNGP02.phx.gbl...
> DOWNFALL: If they use different databases...
Which they do, according to the OP...
> Not an MCSDE, MVP, MCDE, MSFT or WTF
> Not a single certification, besides my degree.
Glad to hear it!
> I'm just an engineer with more than 14 years spent in design and
> programming.
Likewise, give a take a year or three... :-)
The problem happens when you have a key in your web.config that is used in
all apps and for each it has different values.
Since you use only one web.config, you have to separate them into different
keys.
If you want a single app, you can have a single web.config only.
Armando Canez
"Mark Rae" <mark@.markNOSPAMrae.com> wrote in message
news:%23PbUPfJIHHA.1784@.TK2MSFTNGP06.phx.gbl...
> "Armando Canez" <acanezATintelexionDOTcom> wrote in message
> news:uJtOFKJIHHA.3780@.TK2MSFTNGP02.phx.gbl...
>
> Which they do, according to the OP...
>
> Glad to hear it!
>
> Likewise, give a take a year or three... :-)
>
"Armando Canez" <acanezATintelexionDOTcom> wrote in message
news:%23LwYe5JIHHA.3952@.TK2MSFTNGP02.phx.gbl...
> The problem happens when you have a key in your web.config that is used in
> all apps and for each it has different values.
That's right.
> Since you use only one web.config, you have to separate them into
> different keys.
Yes, I know...
> If you want a single app, you can have a single web.config only.
Obviously.
NH wrote:
> I have about 8 production apps, all small functional ones like "Expense
> Claiming", "Invoicing", "Reporting" etc.
> They are all asp.net and some are 1.1 and some 2.0.
> I want to bring them altogether in a way that you have single sign on for
> all of them (or even just the 2.0 ones if it makes it easier). How do I do
> this, do I create a new ASP.Net solution with multiple projects in it? Do
I
> use one website in IIS or can it handle the multiple websites I already ha
ve?
> I am thinking of creating a single home page with links to all the apps th
at
> will save poeple logging in multiple times.
What I do is have a login app which has a drop down of all the apps
available (this is on a company intranet). User tries to log in, app
checks credentials which we already store in a database. If the user
has access, I store a random string in a table with the user ID and
application ID.
I then do a server.transfer to the destination application, passing the
user ID and random string in the querystring to a "login.aspx" page.
The login.aspx page checks to make sure the user ID, application ID and
app ID matches in the table. If not, someone has munged the URL and I
redirect them to the login again.
If it does match, then I store the user ID and whatever else you need
in the session of the destination app, and I clear out the random
string from the table and forward them (server side) to the home page
of the app. The user never sees the "login" page for added security.
Thursday, March 29, 2012
Many apps into One?
Labels:
apps,
asp,
expenseclaiming,
functional,
invoicing,
net,
production,
reporting
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment