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]

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]

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

 

[Guest]

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]

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]

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]

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]

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.

 

[Guest]

#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

 

[Guest]

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.

I should take the last comment back. I was thinking of SOA not n-tiers

 

[Guest]

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

Yes and no...

UI - 2 sets of code (ASP.NET/WinForms/PDA/etc)

Business Logic - one set (deployed on app server or as DLL)

Data Layer - one set (deployed as DLL, on app server, or on data base
server).

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.

We use VS.NET 2005. LLBLGen Pro is a great Data Layer Generator - saves
hand coding the data layer (DLs are very redundant to code).

 

[Guest]

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

Click one is a deployment method in .NET 2.0 (supports auto-download, auto-
update, etc). However, I believe Click-Once needs a web server which you
don't have.

BTW, is there a reason your clients don't have access to a web server? I
noticed your clients need to send read-only data files which are sent
through your Intranet?

 

[Sean]

So where are you storing the data? Directly to SQL server?
Couldn't you just as easily deploy a web server?

For those that don't have a SQL server, they work with an Access DB stored
on a shared folder.
Deploying a web server would be wonderful ... but, they wouldn't allow us to
do it.

.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.

The standalone application is an Access application ... so, yes we know
about obsolete.

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

Good point, perhaps a starter with a smaller project ... difficult as we
only really have this set of applications (our primary product) and a
development team of two.

 

[Sean]

Click one is a deployment method in .NET 2.0 (supports auto-download,
auto-
update, etc). However, I believe Click-Once needs a web server which you
don't have.

BTW, is there a reason your clients don't have access to a web server? I
noticed your clients need to send read-only data files which are sent
through your Intranet?

Not all have a webserver, some do, which is a growing number (thankfully).

Our standalone application has a readonly mode which is used when they don't
have a webserver, but in this environment the total deployment is much
smaller than when they have a webserver, but it's also fairly true that when
there is a need for a wider range deployment, the organisation is
proportionally bigger and more technologically up to date, with a webserver
and usually SQL.