How ClickOnce to multiple servers?

[Ronald S. Cook]

We have a VS2005 Team setup and are developing a Windows app (smart client).
We are in the cattle feeding business and have 10 distinct feedyards across
the U.S. When we wish to deploy an update to our app, we must change an app
setting in the project (the IP where the data access layer is) and also the
URL in the ClickOnce (to correspond to a server at a particular feedyard).
Once we publish, we have to change the app setting and the URL again for the
next feedyard. And then do it again and again (for a total of 10 times).

While we've given some thought to a central server for clients to install
from and pick up updates, it's not practical for two reasons. One, network
connectivity from the feedyards back to our corporate office (in Loveland,
Colorado) is not very reliable. Two, we might have a change that we don't
all feedyards to immediately pick up. I.e. we may want to publish to one
feedyard and make sure it works ok before deploying to the others.

In playing around with MSBuild I found where I can set a PublushUrl setting,
but it still puts the files in my local folder. I'm wanting to automate
publishing to all feedyards (i.e. 10 separate servers) through some sort of
script (i.e. pulling from a list of IP addresses).

Any help would be greatly appreciated.

Thanks,
Ron

 

[Daniel]

Well when i use click once i publish to a remote server which has high
bandwidth and they get the software from there. Then on connecting thats the
update location.

An update should always be froma central location, what is better however
is to make the update optional when it is in your beta phase and simply tell
the others not to install the update. Then after a week or however long of
the one that you tried it on working and you are happy, publish it again but
this time make the update non optional. So the others will update.

I believe click once can be quite customised but i haven't toyed with that
as i haven't needed to yet. Would th eabove not suffice for your deployment
needs and be easier to manage rather than trying to make 10 deployment
locations? What if you had 100 food yards you couldnt do that method. So i
STRONGLY advise the above method or similar.

good luck

 

[Ronald S. Cook]

Thanks for the reply Daniel. It's more that we can't trust the connectivity
from the client machines back to a server at corporate. Our app runs in
(among other places) feed trucks that drive around a feedyard delivering
grain to cattle. They're on wireless network to the LAN, but then the LAN
that ties that feedyard into the WAN (and thus back to a corporate server)
is not reliable. That's why we were thinking we should deploy to a server
at each feedyard.

Also, app settings at each yard will be different. How would you deal with
that? I think I read that ClickOnce could accept querystring parameters so
maybe a feedyard would pass Feedyard=Kuner to the corporate server and
ClickOnce would insert the approprate application setting for that
install/update. But then there's a chance for someone messing it up too and
typing the wrong thing in the URL I suppose.

Do you still strongly disagree with installing to each of 10 servers? Don't
forget also about wanting a new change pushed to only one feedyard to make
sure works before others get it. Just telling users not to accept optional
updates won't cut it either. Some will click it no matter what.

Thanks again,
Ron

 

[Daniel]

Yes i still do strongly disagree with your 10 server deployment but you seem
to have your heart set on it.

Yes you can pass a query string params to a click once deployment and you
could do that to ensure individual updates are deployed. As for the wrong
url being typed you would make a site and on your website have links to each
download which would pass the string. Unless they intentionally retype the
url they wont have a problem. Why would they intentionally retype the url
and change the string?

I understand staggering a deployement but if you tested the software
correctly before deploying the update you shouldn't have a problem post
deployment (part of testing is usually to test on a mirror of one of your
live sites that you have running locally for example). And if you do have an
issue, and its major, you upload a previous version and have them connect
and overwrite with the old version and you look at where you screwed up. -
downtime would be minimal and remember this is worst case scenario.

BUT....if you really don't trust your test department to get it right then
you only need 2 servers. One for your main, ready to go product and the
second as your Beta server. You upload the update to that beta one and tell
the one foodyard to download from there, check that it works, if it does now
upload the update to the main server and the others will pick it all up.

As for the connection not being reliable, you need to explain further. Which
part is not reliable, the trucks wireless connection or the LAN side? If its
the lan side then this is a separate issue and needs to be addressed. For
the lan check your cabling, routers etc. If its your internet connection
speak with your isp and get it to be reliable. If its the wireless
connection to the trucks find a way to amplify the wireless range and if
this cant be done have them boot the software while the trucks are docked so
that they update while connected to the lan or in a strong area for the
wireless signal, and if they never dock back and stay out on the field then
as said before you need to improve your wireless connection quality. if this
cant be done a different form of deployment needs to be considered as the
internet is not reliable sue to your hardware shortcomings, so a CD sent out
for example may be more appropriate.

D