Cathi’s topic is maintaining applications with clickOnce. Click once allows deployment off applications without having to uninstall and reinstall apps on the system. Also deployments do not require administrative rights.
Cathi mentions that there are two variants: launched and installed. Launched apps are opened via a URL and will not appear in add/remove programs. Installed will be deployed to the system and show in add/remove programs. A launched application will not be available to offline clients.
In the build menu select publish my app from visual studio 2005 will launch the deployment wizard. The wizard will then compile the app and deploy to the server selected in the wizard. The wizard will create the vdir on IIS and even a launch page if so desired (The launch page will just have some assembly info and a run button). When you click run a security warning is given (more on this later) and then boom the app is loaded. The wizard thankfully remembers your settings so when you need to redeploy you do not have to keep entering your settings. By going to Project properties and selecting the Publish tab you can see more info about the deployment and gives you more control/options than the wizard.
A really cool feature was that you can group parts of your application into groups and download those separately or as required. If you had an accounting program you can group accounts receivable functionality into one group and accounts receivable into another. This minimizes the time to download as well as bandwidth unnecessarily consumed.
The update options are huge. You can check before or after the application starts (or not at all). You can set the frequency of updates (i.e. every 7 days). You can also specify a minimum version for the application to run so you are not forcing an update on people for minor changes to the app. If you changed the underlying data schema or something to that effect you would force the min version to be the current one and force that update on the users.
The publish version # is different from assembly version. This allows you to keep the same assembly version number but have a different one so every time you publish it will be a different version and allow clients to detect a new deployment.
Add remove programs will allow you to restore the application to a previous state (i.e. the last version) or remove the application. ClickOnce always maintains the current version on the computer and the last version installed. A more common way to rollback from a centralized point is with an app called MAGE (I assume it ships with 2005 but have not confirmed). By using Mage on the webserver where the app is deployed from (the webserver maintains every version on the server) you can open the manifest file and change all the settings you could from the visual studio deployment screen. From here we can also change the version that is current and allow us to rollback our deployment from a central location. The next time a client opens the app (depending on the update options) the application will update and rollback to the version selected via the Mage tool.
ClickOnce defaults to full trust which brings up the earlier mentioned prompt when using the launch model (i.e. via a url). There is a permission calculator within visual studio somewhere that will allow you to calculate the security level necessary. You can also debug in different security settings so that you can test how the app behaves in different permission levels. To drop the permissions down go to the project properties and select security; from there you can change the settings (as well as the perm calculator and debug in zone setting).
For full trust you can sign the app with a cert from someone like VeriSign. Then configure each computer to trust any assemblies signed with that cert will not prompt the user when they run any app signed with that certificate.
I asked Cathi a few questions after:
Q: Back in the old no-touch deployment days changes to the app were done by the file modified date. Is this still present with clickOnce?
A: It is but it is not recommended. There are lots of issues when you start crossing time zones, daylight savings differences, and even having a computers clocks set wrong. It is a really good idea to just use the built in published version number option.
Q: Can you still strong name an assembly and then configure each client computer to fully trust anything signed that way?
A: Yes but again its not the Microsoft best practice. I will be showing how to do that in the advanced session.
This was a great intro to clickOnce and was way better than trying to read up on it. And lets face it my illiteracy limits my reading.
Recent Comments