Saurabh Pant's Weblog : ClickOnce

Live From Redmond: Configuring ClickOnce to best work for your deployment scenario

Saurabh — Mon, 06 Nov 2006 20:19:00 GMT

[Update 11/27]

The talk is now available online here [Click here for zipped download]

[Update 11/07]

Attaching the Slide Deck from the presentation to the post.

[Original Post]

Continuing with our highly popular "Live from Redmond" series I shall be presenting the following ClickOnce talk on Nov 7th ...

Live From Redmond: Configuring ClickOnce to best work for your deployment scenario

7th Nov 2006 [Click here to register]

The “ClickOnce” feature in .Net 2.0 brings the ease of web deployment and update to Smart Client Applications in an enterprise.

Are you an enterprise developing Line Of Business applications inhouse and want to know how best to deploy them internally using ClickOnce?

Are you a vendor and want to know how best to package your applications using ClickOnce so that they can be deployed by multiple enterprises?

Is the cross browser support important to your application and you want to know what ClickOnce offers in this space?

This webcast will discuss recommendations from the ClickOnce team on how ot best leverage ClickOnce for common deployment scenarios like above.

It will discuss the options available with the current release of ClickOnce and how these scenarios are even better enabled in Orcas.

ClickOnce coverage in the 'Windows Forms User Education' team blog

Saurabh — Mon, 29 May 2006 05:56:00 GMT

Jay Allen of the Windows Forms User Education team has some good coverage of ClickOnce issues on their team blog. Definately worth checking out ...

http://blogs.msdn.com/winformsue/archive/category/11821.aspx

ClickOnce and FireFox

Saurabh — Thu, 02 Mar 2006 13:26:00 GMT

Firstly sorry for the delay in this messaging from ClickOnce. Judging by the passionate opinions I have heard around the community on this issue, this is a blog we should have posted a while back.

[Hanselman's Blog - http://www.hanselman.com/blog/PermaLink.aspx?guid=7ce42ccd-e531-4d43-a93f-73483c0afd3d]
[Sven Groot's Blog - http://channel9.msdn.com/ShowPost.aspx?PostID=138273]

[Lady bug - http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=5b309bf8-370d-4571-8ce2-aaebb525488b ]

Geting to business; In the V2.0 release of the Framework, ClickOnce does not have support for FireFox.
- I do discuss later in this post how application publishers can use the ClickOnce shortcut files to allow FireFox users to install Clickonce applications.

ClickOnce does work on machines where FireFox is the default browser, if the user clicks on the deployment manifest in IE.
- There is an issues users hit here if their application carries a bootstrapper package, again a workaround is mentioned later in the post.

And yes we are actively looking into remedying this in the next release of the Framework.

What happens when I click on a ClickOnce deployment in FireFox?

ClickOnce provides an implemention of the IE mime handler interface for the mime type application/x-ms-application which is associated with .application files on servers hosting ClickOnce application. Hence when a user clicks on a .application in IE our mime handler is invoked which downlods the .application file and fires up the ClickOnce install.

When a user clicks on a .application in FireFox the FireFox equivalent of the Open/Save dialog comes up. Once the .application file is downloaded to the local macine (to the FireFox cache on Open and to a user specified location on Save) it is run form there firing up ClickOnce. ClickOnce now parses the locally downloaded .application and tries to download the actual application manifest it refers to. If the .application contains a relative path to the application manifest ClickOnce will try to find it relative to the .application in the FireFox temp folder and fail. If it is a full Url to the application manifest ClickOnce fails anyway, this time due to a security check we have that does not allow the .application and the corresponding application bits to be in different security zones.

There have been Plugins written by the FireFox community
[e.g. http://www.softwarepunk.com/cohelper/] where they parse the application after it has been downloaded and read the deploymentProvider Url from it. They then use the undocumented Apis for invoking ClickOnce with the URL as a parameter [rundll32 dfshim.dll,ShOpenVerbApplication URL ]. I have never tried the approach above, but would believe it works.

From the ClickOnce teams perspective we would advise users against parsing the ClickOnce manifest and relying on its format for we could inadvertently break you in future manifest updates. Also since the <deploymentProvider> tag is only needed in Shell Visible installed ClickOnce applications this solution does not work for Online ClickOnce Apps.

For out next release we are looking into what we can do to provide a simple public way for the FireFox community to build plugins for ClickOnce support. Stay tuned ...

How do ClickOnce Shortcuts help me get ClickOnce support on FireFox?

Anytime a shell visible installed ClickOnce App is downloaded to a machine, we create a ClickOnce shortcut (.AppRef-MS) for the application under Progrmas->Publisher->Product.AppRef-MS.
The contents of this shortcut file look something like this -http://Foo/Bar/Dummy.Application#Dummy.app, Culture=neutral, PublicKeyToken=XXXXXXXXXXXX, processorArchitecture=msil
As you can see it contains the Url to the .application and the identity of the deployment manifest modulo version.

These ClickOnce shortcuts are designed so that they can be emailed to people and when ckicked on, on a machine which does not have the corrsponding application already installed they cause the application to be installed and launched.

Now asuming you have an ClickOnce application (Shell Visible Installed App - Not an Online App) you want to publish to your clients who use FireFox, all you need to do is generate the shortcut file and publish it on your server (If you have both IE and FireFox users you could have a seperate link saying "FireFox users click here" so that IE users still get the default behavior). Once the user click on an .appref-MS in FireFox the Open/Save dialog comes up. Once the .appref-MS has been downloaded to the local machine and run it will invoke ClickOnce, which in turn will download the .application from the URL specified in the shortcut and install the App.

This solution works with out any FireFox changes. Remember though that .appref-MS files can only be generated for Shell Visible Installed ClickOnce Apps.

What about client machines where FireFox is the default browser but the user clicks on the .application in IE?

This scenario just works.

There is one caveat though. If your Application carries a bootstrapper along with it to install prerequisites before the actual ClickOnce install, then your scenario might be broken. The bootstrapper after it has installed the prerequisites starts the actual ClickOnce install by launching the .application URL in the default browser (in this case FireFox) even if the user had originally clicked on an IE session to launch the bootstrapper.

There however is a easy workaround for this [http://channel9.msdn.com/ShowPost.aspx?PostID=138879] which I have recommended to users earlier with good success.

Again in closing let me reitterate, we are actively working on having a better XBrowser story for our next release.

Comments are welcome as usual.

ClickOnce and permission elevation prompting in the internet zone

Saurabh — Wed, 01 Mar 2006 01:36:00 GMT

The Decision -
With the .Net Framework V2.0 release of ClickOnce, any ClickOnce App deployed from the internet zone can prompt the user for permission elevation.

For the earlier Beta2 release of ClickOnce, prompting had been explicitly disabled for internet applications that were not Authenticode signed. We consciously reversed this decision for the final release.

This decision of Microsoft has been questioned by a few in the ClickOnce/Security community. Though they do not agree with our decision, most of these blogs do try to be balanced and put forth both sides of the argument. However reading through a few community posts generated by these blogs, I did get a sense that there was a perception that this was a change pushed into the release by Microsoft at the last minute due to pressure from a few large customers.

I plan to articulate out here more clearly our thinking behind this change and hopefully debunk this perception.

The Thinking Behind It -
Non authenticode signed Internet ClickOnce applications were prevented from elevating in Beta2 with the primary goal to get user feedback on this decision so we could make a more informed decision for the final release.

The Beta2 feedback helped us realize that it was important to have a consisitent IE security model for Managed and UnManaged exes, diverging in the model was confusing and muddled our security messaging.

We also got a strong push to enable this scenario from hobbyist/non commercial/community/open source App developers who wanted to deploy their applications using ClickOnce but could not afford (both in terms of time and money) to get an Authenticode certificate.

Let's consider the scenario below ...
Jen is a .Net entusiast and a golf fanatic. She writes a .Net Golf Handicap calculator that unfortuantely needs Intranet (Not Internet) zone permissions to run. Jen wants to share this App on her homepage with her golfing friends and would also like them to get updates as she adds new functionality to her program; ClickOnce is the ideal choice of deployment technology for her.

If ClickOnce forced Jen to have an Authenticode certificate before she could share her App she would soon be looking at other deployment options. She could decide to just write the App in native code and share the exe. The native exe (even a Managed exe for that matter) would now be downloaded and run with Fulltrust on local machine, not a big security win.

Today instead Jen can use ClickOnce to downloaded her App and run in the Intranet sandbox. She also gets to keep her app current with ClickOnce and potentially push down required updates for issues she wants patched immediately.

If we flipped the scenario around to where Jen was the author of a malicious Addware App and wanted to prompt the user from the internet zone she can very easily do it today. ClickOnce has not opened up a new security hole here. We just extent the current IE security model. There are no default scenarios where you can cause a user prompt to come up using ClickOnce where you couldn't for unmanaged Exes.

Also there have been comparisions of ClickOnce with ActiveX in the past and the fact that unsigned ActiveX controls from the internet zone are now blocked by IE has been used as an argument for pushing for similar behavior in Clickonce. ClickOnce and ActiveX are naturally two totally independent technologies, but if parallels have to be drawn we see ourselves closer to exes than ActiveX, and hence as discussed above have tried to maintain the same security expereince that currently exists for exes.

Configuring Prompting -
The current ClickOnce prompting model is highly configurable.
Enterprises can also specifically disable prompting for particular zones or they can use the trusted publisher list to whitelist their ClickOnce applications to run without prompting and disable all prompting.
[MSDN - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickoncetrustpub.asp]

File Patching

Saurabh — Thu, 26 Jan 2006 00:26:00 GMT

While upgrading from v1.0 to v2.0 of an ClickOnce application, files/assemblies that have remained unchanged (have the same hash) across the update are not redownloaded from the server. Instead they are just copied over locally in the Clickonce store from the v1.0 to v2.0 app folder. This is totally transparent to the user except for the Dowload Progress Bar moving much quicker due to the local copy.

Keep in mind file patching is only across two versions of the same application i.e. the Deployment Manifest of the two applications has to have the same identity, modulo version.
Also the patching is at file level not the binary level, hence if only a few bits in a dll have changed Clickonce will still download the entire dll.

File Patching also works for assemblies downloaded using the DownloadFileGroup() APIs.

File Patching does NOT work currently for Data files (writeableType="applicationData").

Know Issue -
Our FilePatching model for assemblies (even strong assemblies) is based entirely on file hash.
Projects when rebuilt in VS often cause the same assemblies (exacly same source) to have different hashes. Hence if you are rebuilding your entire v2.0 solution its possible that assemblies that have not changed in terms of functionality will still have a different hash and hence be redownloaded by ClickOnce instaed of being copied locally.

ClickOnce Team Blog

Saurabh — Thu, 12 Jan 2006 01:14:00 GMT

The ClickOnce team now has a team blog at http://blogs.msdn.com/clickonce
Keep checking it out for tips and tricks, announcamants and other information on the ClickOnce technology and team.

Top X ways to learn about ClickOnce

Saurabh — Fri, 28 Oct 2005 11:27:00 GMT

Sameer Bhangar the Test Lead on ClickOnce project recently internally sent out a list of the top ways to learn about ClickOnce.
Is by no way the authoratative or complete list but definately good starting point. This should serve as a good resource for anyone ramping up on ClickOnce.
Feel free to recommend other resources and I'll add them in here.

Top X ways to learn about ClickOnce -

ClickOnce Discussion Forums:
External forum - http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=6
- As I as have mentioned earlier in my blogs, the forum is the ideal site to go to with ClickOnce issues, bugs, feature request and even general discussion on App Model/Deployment. It is looked at regularly by the ClickOnce product team who do a great of following up on the posts.

Microsoft sites:
    Smart Client Dev Center Home: http://msdn.microsoft.com/smartclient/understanding/windowsforms/2.0/features/clickonce.aspx
    MSDN content on ClickOnce - http://msdn2.microsoft.com/en-us/library/wh45kb66(en-us,vs.80).aspx.

    Video of Jamie Cool the PM on the Winforms/ClickOnce team demoing ClickOnce - http://channel9.msdn.com/ShowPost.aspx?PostID=15303

    Article by Brian Noyes on configuring trust with ClickOnce - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickoncetrustpub.asp
    Article on ClickOnce and Regfree COM - http://msdn.microsoft.com/msdnmag/issues/05/04/RegFreeCOM/default.aspx

    Overview article by Brian Noyes - http://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/
     - Bit old so some specifics may have changed but overall is accurate

Non-Microsoft sites:
   ClickOnce Publisher Certificates - http://geekswithblogs.net/kobush/archive/2005/05/30/41068.aspx
   Links to various ClickOnce related material - http://www.installsite.org/pages/en/clickonce.htm.
   VS Support for ClickOnce - http://www.ondotnet.com/pub/a/dotnet/2004/10/11/clickonce.html
   Another VS walkthrough - http://www.15seconds.com/issue/041229.htm

Few Blog references to ClickOnce:
    Saurabh's blog - http://blogs.msdn.com/saurabh/
    - The one stop Authoratative ClickOnce Resource (well Sammer's mail didn't say so but it should have :-) )
    http://mtaulty.com/blog/(5re21u3e1v3wjmm1qhgybqfo)/archive/2004/07/05/524.aspx
    http://mtaulty.com/blog/(32qtav45kx5a5zeb2taste3j)/archive/2004/07/06/525.aspx

MSI installed ClickOnce Apps?

Saurabh — Tue, 02 Aug 2005 20:37:00 GMT

Am at TechReady1 conference in Seattle today, helping proctor the ClickOnce labs. The labs have not been too busy so With some free time at hand am back to ramblings on Clickonce ....

MSI installed ClickOnce Apps?

This is a scenario request that keeps comming up.
Currently there is no support around installing an application using MSI and updating it via Clickonce.
A user could however have an MSI package that installs that configures the machine and then fires off a ClickOnce .application to install the App which can then be updated via ClickOnce.
Alternatively ClickOnce could carry an MSI package as a custom bootstraper, so that it will be run before the Application is installed.

Both the solutions above though break the isolated, non-impactful ClickOnce Application Model and do not have a clean unistall story.

The manifest has no XML signature

Saurabh — Wed, 06 Jul 2005 22:21:00 GMT

Seeing the following ClickOnce error log? Well your ClickOnce manifests are not signed ...

System.Deployment.Application.InvalidDeploymentException (ManifestParse)
- Exception reading manifest from http://foo.application: the manifest could be invalid or the file could not be opened.
...
--- Inner Exception ---
System.Deployment.Application.ValidationFailedException (Unknown subtype)
- The manifest has no XML signature.

But I did sign the manifest while publishing in VS?

Check if your project includes assemblies with spaces in their name.
There is a known Beta2 bug which causes VS to barf on signing manifest if the project includes Assemblies with spaces in the name.
Renaming the Assemblies in the easy workaround.

ClickOnce MSDN WebCast

Saurabh — Tue, 28 Jun 2005 20:03:00 GMT

Just got out of a ClickOnce MSDN WebCast titled "Building a ClickOnce Toolkit".
It was hosted by William Steele and you can get more info on it, on his blog at
http://blogs.msdn.com/wsteele/archive/2005/06/28/433313.aspx

I was primarily there to represent the ClickOnce development team and take questions.
An interestign experience overall, great to see the buzz around ClickOnce.

Some interesting questions from users, will try to address them in my future blogs.

Am even more convinced that we need a official ClickOnce Team blog ... Need to get more people blogging.

ClickOnce online discussion forum

Saurabh — Fri, 17 Jun 2005 23:05:00 GMT

The ClickOnce Online discussion forum is at - http://forums.microsoft.com/msdn/ShowForum.aspx?ForumID=6

It is looked at regularly by the ClickOnce product team and is ideal to get ansewers to your ClickOnce design/implementation questions.

Demistify the ClickOnce update story

Saurabh — Tue, 14 Jun 2005 06:04:00 GMT

Updates for ClickOnce apps are controlled by the following XML tags in the Deployment manifest.

<beforeApplicationStartup> and <update> are mutually exclusive functionality wise though not in Schema. When both tags are present <beforeApplicationStartup> wins.

BeforeApplicationStartup -
When this tag is present in an application's deployment manifest, at every activation of the application via the desktop shortcut, Clickonce does an update check. If no update is available the application is launched else the Update confirmation Dialog (more on this later) is displayed.

Expiration -
MaximumAge defines how often ClickOnce should check for updates for an Application. ClickOnce keeps track of the last time the update check took place for the application. On application launch if CurrentTime - LastCheckForUpdateTime > MaximumAge, a thread is fired up to perform the update check in the background. Note the check is non blocking and the Application launch is not blocked. If an update is detected (Updated deployment manifest version) a property is set in the clickonce store indicating that an update for the app is available. Next time when the app is launched from the Desktop shortcut the Update Confirmation dialog is displayed.

The UpdateConfirmationDialog -
There are three user actions possible::

1. Clicking Ok
Clicking OK on the Dialog downloads the Updated Application and launches it.
The detected update is considered a Required Update if the <minimumRequiredVersion> set on the updated deployment is greater than the version the user has installed locally on the machine. For required updates no UpdateConfirmationDialog is displayed i.e. The user is not provided with an option to skip the update, rather is assumed to have clicked "Ok" on the dialog.

2. Clicking Skip
Clicking on Skip launches the locally installed version of the application AND makes sure you are not prompted for that particular update for a week.

To reitterate, clicking on Skip is equivalent to "Do not prompt me for this particular update for a week". The week time limit is non configurable.
Note that you will no be "Prompted" for a week - however clickonce will still check for updates based on you maxAge or beforeApplicationStartup setting. If it detects a newer Update (You skipped V2, however now V3 is available) you will be prompted for the new update.

3. Closing the Dialog (Clicking on X)
Closing the dialog launches the locally installed copy of the application - However it does NOT set the "No prompt for a week" setting. So the next time you try to launch the application you are reprompted for the same update.

NOTE - By design if your application would like tighter control of its update lifecycle it can opt out of Clickonce updates by having an empty <subscription> tag. It can then use the ApplicationDeployment Update APIs for update management.
(Unfortunately a bug in Beta2 causes an empty/missing <subscription> section to cause the APIs to throw an exception saying the App is non updatable - The best workaround is to have a <subscription> section with a real high value for <maxAge>)

NOTE - Clicking on a URI to the .application directly always gives you the latest copy on the server independent of the update logic above.

Concurrency restrictions in the ClickOnce (System.Deployment.Application) APIs

Saurabh — Tue, 14 Jun 2005 02:09:00 GMT

UpdateAsync/CheckForUpdateAsync/DownloadFileGroupAsync are the Async APIs

Update APIs -

UpdateAsync()/CheckForUpdateAsync() CANNOT be invoked if either one of them is already in progress. Exception thrown -InvalidOperationException
i.e An updateAsync() call cannot be made when either a UpdateAsync()/CheckForUpdateAsync() call is in progress within the same process and vice versa.

There is no API/Property to query ClickOnce and find out if an Update/CheckForUpdate operation is in progress. Users can catch the exception or programatically keep track of Update/CheckForUpdate calls withing their process.

OnDemand APIs -

DownloadFileGroupAsync CAN be called concurrently with UpdateAsync/CheckForUpdateAsync methods.
DownloadFileGroupAsync(“Foo”) and DownloadFileGroupAsync(“Bar”) calls CAN be made concurrently within the same process.
DownloadFileGroupAsync(“Foo”) and DownloadFileGroupAsync(“Foo”) CANNOT be made concurrently – again you get an InvalidOperationException.

All restrictions discussed above are for API calls within the same process – there are no interprocess global concurrency restrictions.
Similarly there are no concurrency restrictions between the API calls and ClickOnce scenario updates, so while ClickOnce is downloading an update, the application could also be simultaneously downloading the update using the APIs.