ClickOnce apps unable to update?

[Danny Tuppeny]

I've been playing around with ClickOnce today, and it's all good stuff.
Except, that if I change my application to NOT be full trust (which seems to
make very little difference to the user prompt, which scares me!) but to be
installed on the start menu, it seems I don't have permission to call
CheckForUpdate()!

I understand that if I'm not a full trust app, I can't read the filesystem
etc., but not being able to update myself seems a bit flawed, given that's
what ClickOnce is all about - deployment??

Below is a stack trace, but to reproduce...

- Create a new WinForms app
- Add a button that calls
ApplicationDeployment.CurrentDeployment.CheckForUpdate()
- Set it to be installed in the start menu
- Disable any auto-updating options
- Change it to be a partial trust app, installed from "Internet" with the
defaults.
- Set your publish location etc., and publish it.

Click the button, and viola, you'll get the below.

My project's looking like it needs to be full trust anyway (I need to
connect to foreign servers), but it'd be nice to know if it wasn't, I could
still programatically update it :-(


See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Security.SecurityException: Request failed.
at System.Security.CodeAccessSecurityEngine.Check(Object demand,
StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.PermissionSet.Demand()
at
System.Deployment.Application.ApplicationDeployment.CheckForUpdateAsync()
at ClickOnceTest.Form1.UpdateApplication()
at ClickOnceTest.Form1.button1_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)
The action that failed was:
Demand
The type of the first permission that failed was:
System.Security.PermissionSet
The Zone of the assembly that failed was:
MyComputer


************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
ClickOnceTest
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase:
file:///C:/Documents%20and%20Settings/Danny%20Tuppeny/Local%20Settings/Apps/2.0/RGET4OHN.Q1M/ZERZOTTB.PZ4/clic..tion_ecff6c31000b4e14_0001.0000_87b11c99a9e05835/ClickOnceTest.EXE
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Deployment
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.42 (RTM.050727-4200)
CodeBase:
file:///C:/WINDOWS/assembly/GAC_MSIL/System.Deployment/2.0.0.0__b03f5f7f11d50a3a/System.Deployment.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

 

[hashimisayed]

Hi,

Using the ClickOnce APIs requires full-trust.


Thanks,


Sayed Y. Hashimi


http://www.sayedhashimi.com
Shameless Book Plug: Service-Oriented Smart Clients with .NET 2.0
http://www.amazon.com/exec/obidos/tg/detail/-/1590595513/qid=11263614...

 

[Danny Tuppeny]

Using the ClickOnce APIs requires full-trust.

That's what I figured - I don't understand why though! By default, apps can
connect to the site they were downloaded from, and that's pretty much all
the ClickOnce CheckForUpdate does, right?

So.....

This is complete madness. It's going to be ActiveX all over again.
Application developers will say "It has to be full trust, so we can deliver
updates in a sane fashion, when you want" (people don't want their app
downloading updates while they're on expensive mobile connections), so users
will get used to saying Yes to full-trust apps, and the whole CAS thing is
useless, and our users computers all fill up with garbage. Excellent :-(

 

[Danny Tuppeny]

That's what I figured - I don't understand why though! By default, apps
can connect to the site they were downloaded from, and that's pretty much
all the ClickOnce CheckForUpdate does, right?

<snip>

From MSDN:

Update, UpdateAsync, CheckForUpdate and CheckForUpdateAsync require Full
Trust
Calling the Update, UpdateAsync, CheckForUpdate, and CheckForUpdateAsync
methods now requires Full Trust. This is a change since Beta 1.

But no reasons! :-(

 

[hashimisayed]

Hi Danny,

I don't think it is going to be that bad. Realize that you need
full-trust if your application is going to use the ClickOnce APIs to do
updates. That doesn't mean that an application has to have full trust
to be auto-updatable. The ClickOnce runtime is the piece that manages
auto-updates for your application and the ClickOnce runtime has
full-trust. This means that partially trusted applications are also
auto-updatable. They cannot however use the ClickOnce APIs to do
on-demand updates--because the code that executes the ClickOnce APIs
has to have full-trust privilages.

Thanks,

Sayed Y. Hashimi
http://www.sayedhashimi.com
Shameless Book Plug: Service-Oriented Smart Clients with .NET 2.0
http://www.amazon.com/exec/obidos/tg/detail/-/1590595513/qid=11263614...

 

[Danny Tuppeny]

I don't think it is going to be that bad. Realize that you need
full-trust if your application is going to use the ClickOnce APIs to do
updates. That doesn't mean that an application has to have full trust
to be auto-updatable. The ClickOnce runtime is the piece that manages
auto-updates for your application and the ClickOnce runtime has
full-trust. This means that partially trusted applications are also
auto-updatable. They cannot however use the ClickOnce APIs to do
on-demand updates--because the code that executes the ClickOnce APIs
has to have full-trust privilages.

I understand this. But for a large application, the auto-updates isn't
flexible enough. ClickOnce supports non-mandatory filegroups, which can be
downloaded on demand - with the APIs. Without the APIs, there's also no room
for custom logic - eg. I want to deliver an update to my priority customers
first, and others later. I can't implement that without using the APIs in my
own code (unless I faff about having multiple deployment locations, which is
silly).

I'm not saying ClickOnce is useless, but it's certainly nowhere near as
flexible as it should be, without full trust :-(