I have an application deployed via ClickOnce that uses the System.Deployment.ApplicationDeploymentclass to check for updates. The app checks and applies updates perfectly fine on my PC, but when I deploy it to a Tablet PC it hangs on CheckForDetailedUpdate (I also tried CheckForUpdate, even though I think that in turn calls the other). I've reproduced this on two different Tablet PCs. Can anyone shed some light on what exactly is happening inside this method call so I can start to focus on what potential difference(s) it's choking on? I can post code if anyone thinks it'll help. Thanks.

MEC

Did you develop the application on your PC, i.e. the one that works? Have you tried installing it on another PC that is not a tablet?

RobinS.

GoldMail.com

Yes, I installed it on a Vista PC (all I had on hand over the weekend), and it updates fine. I'm working on getting a fresh XP PC to try as well. So far, the only PCs I've encountered that behave this way are 2 Tablet PCs.

MS, can anyone shed some light on what's going on inside this call that would make it not return? I'd like tofocus on what might be behind all this, but it's hard to figure out what to scrutinize. Thanks.

MEC

It may also be worth noting that if I kill the app when hung, then reun the deployment manifest to relaunch it, it does install the update then launch. So, it seems like ClickOnce is working in general. That is, it doesn't appear to be getting choked up on a bad manifest ora deployment failure. It's just hanging in the API call.

I'm getting a little desperate here. Any ideas? Thanks.

MEC

I tested the app on an XP workstation with no SDKs or VS--pretty basic Windows setup. It gets through the API call just fine--no hang. So, now 2 PCs besides my dev PC (including 1 XP Pro) are not exhibiting this issue.

Anyone? Help! :-) Thanks.

MEC

hi MEC,

Windows XP didn't include a version of the .NET Framework, and i'm not sure about Tablet PC. Windows Vista does include a version of the .NET Framework. which version of the .NET Framework did you target in your application? are you installing your application with the setup.exe, or just running the .application file?

m.

Mary,

No edition of Windows XP (including Tablet PC) included .NET Framework to my knowledge. The production application targets 3.0 Framework. We're just running the application file.All the XP Pro and Tablet PCs we're testing have 3.0 installed. I'm aware that Vista ships with 3.5, but the only reason why I mentioned Vista was as another example of the API working on various PCs,as opposed tothe couple Tablets we tested. I think the key discrepancy here is that theAPI works on XP Pro (w/ 3.0), but not on XP Tablet (w/ 3.0). Again, I have no evidence that it's any difference in the platform or Framework that's at the root. It could very well be some difference in configuration/settings between the XP Pro and XP Tablets we're testing. My frustration is that it's hard to pinpoint what kind of settings to focus on when I don't know what underlying operation(s) in the ClickOnce API are causing the call to fail.

MEC

Here's another spin...

I put together a trivial Windows Forms app with a multiline textbox to print trace text, and a button whose click handler simply calls the ClickOnce API exactly as we do in the production app. When I run the sample app on XP Pro and click the button, everything executes fine. When I run the sample app on our tablets and click the button, CheckForUpdate() throws an InvalidOperationException with a trace as follows:

System.InvalidOperationException: Application cannot be updated programmatically unless the deployment manifest includes the <deploymentProvider> element.
at System.Deployment.Application.ApplicationDeployment.CheckForDetailedUpdate()
at System.Deployment.Application.ApplicationDeployment.CheckForUpdate()
at Updater.Form1.btnUpdate_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

So, just to humor, I built a new deployment manifest that includes the deploymentProvider element, and it now works fine on the tablets and still works fine on the XP Pro machines. So, now I have what seems to be a workaround for the time being.

Here are the outstanding issues:

Whywould the deploymentProvider need to be explicitly defined, as opposed to defaulting to the same (deployment manifest) file that was launched? I can understand why it's useful if yo uwant to look for updates elsewhere for some reason, but if not, why not just default to itself?

If the deploymentProvider element truly must be included for programmatic update, as the exception message implies, why do I only get this exception on the tablet PCsubset of my test contexts?

Thanks.

MEC