Architecture for a distributed app

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all,

I could use some advice really, as I'm a developer who works on my own in a
company with no-one else to talk to who can understand me :-(

I've been asked to write a production managment and planning tool for the
horticulture industry (wholesale suppliers growing plants to be sold to
garden centres). The system will deal with the purchase of good inwards
(pots, compost, etc) and will allow the users to create batches which are
treated (sprayed, washed, etc) and eventually become ready for sale.

This application will be deployed to 6 different growers and must be easy to
deploy and update. First off, I was thinking of hosting a web application at
our head office but that's not going to be feasible for a number of reasons
and I'd like the users to have a rich UI to deal with, probably an MDI. All
the sites have/will have 2000/2003 SBS (including IIS, SQLServer, etc), so
that cost is not a factor in my decision.

I've heard a great deal about "one click" deployment to help the process of
rolling out/upgrading an application. However, I believe this is only going
to be available in Visual Studio 2005. The project, or the first phase of it
is due to be rolled out in August 2005 and I don't know if I can wait that
long for MS to deliver VS 2005.

A few things I'd like advice on:

1) does anyone know of the most recent release date for VS2005
2) Should I consider using the Microsoft Updater application block (is it
easy to use/clumsy/ reliable/unreliable etc)
3) Should I go back to the drawing board? If so, can anyone suggest a
different model that I could use?

Your help, advice and experience would be greatly appreciated.

And whilst we're on the subject, are there any .NET programmers in the West
Sussex area of the UK who could use a bit of networking?
 
Tim,

With your 6 clients I would not bother to much about the updating.

In your situation would I make a small webservice program that gets a
current needed install fill wherein are the programs that should be on the
client computer.

Than check those with the same program and download than using that seeme
program the needed files.

In dotNet are enough classes (or available on internet) to make this what I
write not too difficult.

(The only problem you have is when you want to refresh that upgrader
program.)

I hope this give some idea's

Cor
 
Thanks Cor

I understand what you're saying. However, this project is going to roll out
in at least 4 phases, with minor releases along the way. Each new version
will require a site visit because there is no-one there who is IT literate
and so, if I only go out for the major releases, that's 24 site visits, and
an awful lot of time. The thing I like about the Updater application block is
that, I think, if a user downloads an updated version of the app and it
doesn't work correctly, he can easily roll back to the previous version.

Keep those suggestions rolling in.
 
Hi,

Sounds like you haven't yet left the drawing board ;-)

I'm afraid I don't know the latest release date of VS2005, but
experience has taught me not to wait for such things are they are
invariably very late! 2003 now has the advantage of being around for a
while and so quite stable.

I've not used smart forms myself, but I'd say it's definately something
worth looking into. Maybe a very quick and simple prototype into one
location will give you an idea on whether the technology and customers
can work together reliably.

Other factors that I would consider are things like; how often and
complicated are updates likely to be (maybe posting a CD with explicit
instructions is another viable option), are the number of customers
using the system going to grow (if you're hoping for 50 sites on the
system within a year, automatic updates would be a god-send and worth
spending a lot of time looking into).

Are the sites all connecting to a central database, or running entirely
locally? If the data is held centrally I would certainly consider the
web option. The webpages are probably lighter than data access and
you'd be surprised how nice and functional a web page can be.

Then there's always older, clunky methods like remote dial-up access
which comes with SBS. Handy for updates - and that invariable situation
of users deleting things they shouldn't!

Sorry for no answers, just thought I'd give you some more options and
advise you to look at ALL the factors, both now and down the line :-)
Regards,

Peter Chadwick (MCP)
(e-mail address removed)
 
A link that may interest you. Note: the author is using the current
framework.
http://www.code-magazine.com/Article.aspx?quickid=0307061

And now, make sure to read this rant. The author makes some good points.
Keep in mind that some of his problems won't apply to you, since you can
visit each site for the initial setup.
http://west-wind.com/weblog/posts/154.aspx

Note that zero-touch deployment exists in .Net Framework 1.1, but has been
criticized as being clumsy and sometimes buggy. The new version of the
framework has a new approach that (assumably) works better. Not having used
either, I cannot recommend one over the other.

It is actually quite common to do what Cor suggested. Have a "bootstrap
loader" that you install, in person, on the machines of each of your
clients. Provide a link to this app in your menus. When the user starts
this up, it checks a web service for a list of assemblies that must be
installed on the computer, and checks a little log (that it keeps) of what
has been installed. If you don't have all the current stuff, download the
stuff you need.

Then, start the app from the bootstrapper.

To be honest, I'd also give the user the ability to start the app without
running the installer. That way, if your internet connection is down, your
customers aren't being held up by an app that has to wait for a timeout
before starting up.

HTH
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Back
Top