CODEWITHSUNDEEP
.net.net-3.5deploymentinstallationclickonce
Arsen Mkrtchyan
Arsen Mkrtchyan

Reputation: 50712

Deployment and automating update

I have WCF client server application, and create msi setup projects for both projects. Server is a windows service that hosts WCF service, client is a WPF application. Now I have a requirement to automate client update mechanism. That is on client's open it should check is there updates in the server, if yes downloads and install and then run. Should I use click once deployment? Are there standart mechanisms to do this or I should implement it manually? What other suggestions?
EDIT
Investigating click once limitations,thanks to dear responsers, I found that click once is not sutuble for our application, Is there any other mechanism? what is the best practices to do that with web service..?
Thanks a lot

Upvotes: 0

Views: 487

Answers (3)

pete the pagan-gerbil
pete the pagan-gerbil

Reputation: 3166

This blog (http://coffeedrivendevelopment.blogspot.com/2008/09/clickonce-deployment-or-not.html) describes his decision not to use ClickOnce, and a simple mechanism for writing your own self-updating program. He uses source control to check for a new version, but you could theoretically check the location that you publish your new version to, with some other version indicator (text file, database, webservice call, whatever).

Upvotes: 1

codeConcussion
codeConcussion

Reputation: 12938

ClickOnce is a great tool. However, you should know it has some limitations before deciding on it.

  • It doesn't let you choose where apps are installed. It installs them in an obfuscated location under the user profile. Yes, that means ClickOnce apps are downloaded and installed per user, not per computer.
  • It simply keeps files on the user's machine in sync with files on a server, nothing more. You can't install 3rd party msi files, register dlls, install assemblies to the GAC, etc.

There are other caveats, but those two are the big ones for most people. If you can get around those then ClickOnce may be an option for you.

When trying it out, I would just publish your application from Visual Studio and use a self-certificate. If you decide to go with ClickOnce you're probably going to want to use MSBuild or MageUI to generate your deployments and you may want to look into buying a code signing certificate from a certificate authority (like Verisign).

Edit
Just wanted to respond to @Richard Dunlap's comment. He is correct, you can specify pre-requisites in Visual Studio and it will build a bootstrapper for you. The bootstrapper saves the user from having to download your prereqs individually, run them in the correct order, etc.

However, this is largely just a feature that VS provides and is, IMO, separate from ClickOnce. ClickOnce is limited to making sure an assembly exists in the GAC and then making the installation fail if it doesn't. There's really no connection between your bootstrapper and your ClickOnce install. You pretty much have to tell the user, "If you don't have product x, y, or z, please run this bootstrapper thing before you try to install my application". There's nothing ClickOnce can do to check for some 3rd party COM product and force the user to install it before running their app.

Upvotes: 2

Richard Dunlap
Richard Dunlap

Reputation: 1957

This looks like a straightforward use of ClickOnce. Whether you want to use the automatic ClickOnce updates or do programmatic updates depends on the following:

  1. If you set ClickOnce to check for updates before starting, you get first get a generic Microsoft box notifying the user that the application is checking for updates. If you're OK with this, great. If you'd like the user to see your splash screen first thing, or if you have some other startup activities you'd like to run in parallel with the check for an update, you might want a different option.

  2. If you set ClickOnce to check for updates after starting, you go straight into the application, but the updates will not be deployed until the next time the application starts; you can of course notify the user that an updated version is now available and give a restart option. If it's OK for the user to run the old version one last time, this works well.

  3. If both of those options cause you problems, then you can use the API to do programmatic updates. This is what we've chosen to do -- since our ClickOnce application is a presentation layer client communicating with web services, it's best for our customers to always be running the latest version of the software. However, we want to use the time while the application is checking for an update to do some other housekeeping (like checking connectivity to the web services) -- and we like for the users to see our logo and company name while they wait. :-)

Enough to get you started?

Upvotes: 1

Related Questions