Developing for EXE and ASP

[Sean]

Could someone give me a few bullet point notes on how I go about developing
a system that can be deployed both as an ASP intranet as well as a stand
alone EXE.

In essence we are aiming to provide both ASP/EXE to our clients, but to try
an minimise the amount of development work involved with maintaining the
applications. This would take over from a standard ASP Intranet and
stand-alone Access applications (of course, the latter being a key decision
to make this move).

The development would be completed with VB.Net and/or Visual Studio .NET

Regards,

Sean

[rowe_newsgroups]

On Apr 10, 11:32 am, "Sean" <sean.anderso n@[nospam]oakleafgroup.bi z>
wrote:

Could someone give me a few bullet point notes on how I go about developing
a system that can be deployed both as an ASP intranet as well as a stand
alone EXE.

In essence we are aiming to provide both ASP/EXE to our clients, but to try
an minimise the amount of development work involved with maintaining the
applications. This would take over from a standard ASP Intranet and
stand-alone Access applications (of course, the latter being a key decision
to make this move).

The development would be completed with VB.Net and/or Visual Studio .NET

Regards,

Sean

ASP or ASP.Net?

Thanks,

Seth Rowe

[Mythran]

"Sean" <sean.anderso n@[nospam]oakleafgroup.bi zwrote in message
news:11******** ******@kestrel. skynet.co.uk...

Could someone give me a few bullet point notes on how I go about
developing a system that can be deployed both as an ASP intranet as well
as a stand alone EXE.

In essence we are aiming to provide both ASP/EXE to our clients, but to
try an minimise the amount of development work involved with maintaining
the applications. This would take over from a standard ASP Intranet and
stand-alone Access applications (of course, the latter being a key
decision to make this move).

The development would be completed with VB.Net and/or Visual Studio .NET

Regards,

Sean

Well, this is one thing n-tier applications allow. What you need to do (if
you go this route) is to create ui-independent business and data logic
layers that contain most of your non-ui code. The Business Logic layer
provides the actual business logic (data validation, massaging, etc) while
the Data Access layer provides the meat for accessing
(fetch/update/delete/insert) of the data into the data store.

You still need to write two apps in this case...

Another way would be to make your app an HTML application (with the .hta
extension). This makes a single UI that can be used from Internet Explorer
but downloads and runs as an application. I've gone this route before, but
we did have hurdles/hoops to jump through.

HTH,
Mythran

[Spam Catcher]

"Sean" <sean.anderso n@[nospam]oakleafgroup.bi zwrote in
news:11******** ******@kestrel. skynet.co.uk:

Could someone give me a few bullet point notes on how I go about
developing a system that can be deployed both as an ASP intranet as
well as a stand alone EXE.

You have two main options:

1. Create the back end logic as a web service - this way all clients will
use the same logic for all critical functions (i.e. save, retrieve, etc).

2. Or place your application logic into a DLL... and use the DLL as the
foundation for your application (ASP, Desktop, etc).

Problem with #2 is that if a client has an outdated EXE... it's going to
use outdated logic. Also if you're deploying to hundreds of clients... it
could be a pain to update.

So it depends on how much logic you wish to keep control over ... but web
services is definately a consideration for your situation.

[Cor Ligthert [MVP]]

Sean,

First you have to ask yourself if your clients trust you.
(Let say the same as you trust Microsoft as it is about the Word Program).

If that is the fact, you don't need an HTML (by you called ASP) program, you
can supply everybody a nice EXE program in the same way as Microsoft does it
with word by using the inbuild Click Once deployment method.

Cor

"Sean" <sean.anderso n@[nospam]oakleafgroup.bi zschreef in bericht
news:11******** ******@kestrel. skynet.co.uk...

Could someone give me a few bullet point notes on how I go about
developing a system that can be deployed both as an ASP intranet as well
as a stand alone EXE.

In essence we are aiming to provide both ASP/EXE to our clients, but to
try an minimise the amount of development work involved with maintaining
the applications. This would take over from a standard ASP Intranet and
stand-alone Access applications (of course, the latter being a key
decision to make this move).

The development would be completed with VB.Net and/or Visual Studio .NET

Regards,

Sean

[Sean]

"rowe_newsgroup s" <ro********@yah oo.comwrote in message
news:11******** **************@ n59g2000hsh.goo glegroups.com.. .

On Apr 10, 11:32 am, "Sean" <sean.anderso n@[nospam]oakleafgroup.bi z>
wrote:

>Could someone give me a few bullet point notes on how I go about
developing
a system that can be deployed both as an ASP intranet as well as a stand
alone EXE.

In essence we are aiming to provide both ASP/EXE to our clients, but to
try
an minimise the amount of development work involved with maintaining the
applications . This would take over from a standard ASP Intranet and
stand-alone Access applications (of course, the latter being a key
decision
to make this move).

The development would be completed with VB.Net and/or Visual Studio .NET

Regards,

Sean

ASP or ASP.Net?

Thanks,

Seth Rowe

Proposed solution would be in .NET as I understand that it's possible to
have a .NET solution that could be deployed as both ASP.NET (for the
Intranet) and VB.NET (for the stand-alone application).

[Sean]

"Cor Ligthert [MVP]" <no************ @planet.nlwrote in message
news:uu******** ******@TK2MSFTN GP04.phx.gbl...

Sean,

First you have to ask yourself if your clients trust you.
(Let say the same as you trust Microsoft as it is about the Word
Program).

If that is the fact, you don't need an HTML (by you called ASP) program,
you can supply everybody a nice EXE program in the same way as Microsoft
does it with word by using the inbuild Click Once deployment method.

Cor

Trust with our clients isn't an issue, it's a bespoke system that is bought
on contractual terms with all the why's and wherefore's for security clearly
detailed in the contracts.

The project (as it presently stands) is in two parts, because of a few
details:

(1) Data entry is carried out (primarily) from one department of a big
organisation.
-- Either solution is viable

(2) Not all clients have a Web Server (or not one that we can utilise).
-- Only a stand-alone is viable

(3) Some clients wish to share data (in read-only format) to others in
the organisation.
-- Known prerequisite for an Intranet.

I am not sure what you mean by "the inbuild Click Once deployment method" ?

[Sean]

"Spam Catcher" <sp**********@r ogers.comwrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Sean" <sean.anderso n@[nospam]oakleafgroup.bi zwrote in
news:11******** ******@kestrel. skynet.co.uk:

>Could someone give me a few bullet point notes on how I go about
developing a system that can be deployed both as an ASP intranet as
well as a stand alone EXE.

You have two main options:

1. Create the back end logic as a web service - this way all clients will
use the same logic for all critical functions (i.e. save, retrieve, etc).

2. Or place your application logic into a DLL... and use the DLL as the
foundation for your application (ASP, Desktop, etc).

Problem with #2 is that if a client has an outdated EXE... it's going to
use outdated logic. Also if you're deploying to hundreds of clients... it
could be a pain to update.

So it depends on how much logic you wish to keep control over ... but web
services is definately a consideration for your situation.

#1 isn't possible as not all clients have a webserver that we can utilise.

For updates, there are (at most) only a handful of data entry clerks that
would use the stand-alone application and they're all in the same department
so easy to update.

Seems like a n-tier is the way to go, but from what I have read here (and
the other replies), I don't see a benefit here from using .NET and DLL's
over writing a solution with VB, ASP and DLL's. With the steep learning
curve that we will encounter on .NET ... seems to make sense to stick with
VB/ASP as this is well trodden ground from which there will be far fewer
hurdles/hoops to deal with.

[Sean]

"Mythran" <ki********@hot mail.comwrote in message
news:eu******** *****@TK2MSFTNG P05.phx.gbl...

>

"Sean" <sean.anderso n@[nospam]oakleafgroup.bi zwrote in message
news:11******** ******@kestrel. skynet.co.uk...

>Could someone give me a few bullet point notes on how I go about
developing a system that can be deployed both as an ASP intranet as well
as a stand alone EXE.

In essence we are aiming to provide both ASP/EXE to our clients, but to
try an minimise the amount of development work involved with maintaining
the applications. This would take over from a standard ASP Intranet and
stand-alone Access applications (of course, the latter being a key
decision to make this move).

The development would be completed with VB.Net and/or Visual Studio .NET

Regards,

Sean

Well, this is one thing n-tier applications allow. What you need to do
(if you go this route) is to create ui-independent business and data logic
layers that contain most of your non-ui code. The Business Logic layer
provides the actual business logic (data validation, massaging, etc) while
the Data Access layer provides the meat for accessing
(fetch/update/delete/insert) of the data into the data store.

You still need to write two apps in this case...

Another way would be to make your app an HTML application (with the .hta
extension). This makes a single UI that can be used from Internet
Explorer but downloads and runs as an application. I've gone this route
before, but we did have hurdles/hoops to jump through.

HTH,
Mythran

So, with the HTML application there's one UI ... one set of code, etc., ?

This sounds like what we could be looking for. Will investigate further.

If you have any pointers for getting me started, would appreciate it.

Could you advise of what development environment you would use.

[Spam Catcher]

"Sean" <sean.anderso n@[nospam]oakleafgroup.bi zwrote in
news:11******** *******@kestrel .skynet.co.uk:

#1 isn't possible as not all clients have a webserver that we can
utilise.

So where are you storing the data? Directly to SQL server?

Couldn't you just as easily deploy a web server?

For updates, there are (at most) only a handful of data entry clerks
that would use the stand-alone application and they're all in the same
department so easy to update.

Seems like a n-tier is the way to go, but from what I have read here
(and the other replies), I don't see a benefit here from using .NET
and DLL's over writing a solution with VB, ASP and DLL's.

n-tier is definately the way to go, but typically you'll need an
application server as the middle tier... and without a web server, you
don't have n-tiers.

With the
steep learning curve that we will encounter on .NET ... seems to make
sense to stick with VB/ASP as this is well trodden ground from which
there will be far fewer hurdles/hoops to deal with.

..NET is entirely OO which makes for easy maintainance. ASP.NET has a
nice event model which makes programming complex web apps MUCH easier
than ASP. Also VB/ASP is considered obsolete, so your app is already
obsoleted.

But if your team has significant learning to jump to .NET ... then yes,
it can be a pain. But it's the sort of pain you'll need to take sooner
or later? Perhaps this isn't the project to do so ... but you should
definately consider moving your team to .NET. The benefits of .NET will
be apparently once you move :-)