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
"Ronald S. Cook" <rc***@westinis.comwrote in message
news:63**********************************@microsof t.com...
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" <Da*****@vestryonline.comwrote in message
news:er**************@TK2MSFTNGP04.phx.gbl...
>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" <rc***@westinis.comwrote in message
news:9C**********************************@microso ft.com...
>>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