views:

75

answers:

2

I'm about to start working on a ClickOnce app targeted at internal customers for use on the organization's intranet. I want to ease the setup process, so I thought that developing the app to be partially trusted would be a good idea, but now I'm not so sure.

One thing that the users have specifically asked for is (boiled down to) a TextBox with Cue Text. The easiest way to provide this at the moment is with a simple subclass of TextBox that includes the CueText functionality as a property. The cuetext functionality is done via a PInvoke'd call to SendMessage().

protected override void OnHandleCreated(EventArgs e)
{
    this.UpdateCueText();  // Bang, you're dead here
    base.OnHandleCreated(e);
}

private void UpdateCueText()
{
    if (this.IsHandleCreated)
    {
        NativeMethods.SendMessage(new HandleRef(this, this.Handle), setCueBannerMessage, this.showCueTextWithFocus ? new IntPtr(1) : IntPtr.Zero, this.cueText);
    }
}

"Ah-ha! I need SecurityPermission.UnmanagedCode." The default intranet zone security includes the SecurityPermission permission as far as I can tell, so I try running it and it explodes on the call to UpdateCueText(). I can even inspect the properties on the SecurityException b/c every attempt to evaluate a SecurityException property throws another uninspectable SecurityException.

I try the standard modification:

protected override void OnHandleCreated(EventArgs e)
{
    var permission = new SecurityPermission(SecurityPermissionFlag.UnmanagedCode);
    permission.Assert();
    try
    {
        this.UpdateCue();
    }
    finally
    {
        CodeAccessPermission.RevertAssert();
    }
    base.OnHandleCreated(e);
}

Still no luck. But when I go to the security settings page in the project properties and set the SecurityPermission to be "Included" instead of "Zone Default", I don't even need the manual assertion, everything just happens. But of course, then I assume the customer is still going to get an elevation prompt.

Is it possible to do what I'm trying to do from a partial trust environment? I'm beginning to suspect that it's not b/c it wouldn't even make sense. Arbitrary partially-trusted code shouldn't be able to just call SendMessage, right? I'm beginning to realize that I've been trying to circumvent the security measures instead of work within them.

If that's the case, is it even worth the effort to develop this app with partial trust as a priority? Or should I just resign myself to an elevation prompt on setup to create a fully trusted app for the sake of schedule and meeting ui requirements?

+5  A: 

If you are deploying an intranet application I definitely don't think it's worth it to mess with partial trust scenarios. Partial trust tends to be hard to understand and can impose non-obvious limitations to your code. I only use it when I have to deploy a component into an existing partial trust environment.

Setting up a new partial trust environment in a scenario that does not require it is just adding extra overhead for yourself. Unless there is a specific customer requirement, less likely for intranet app, I would avoid it.

JaredPar
+1  A: 

The statement

permission.Assert();

can only grant your thread permissions that are already available to the assembly. That's why that doesn't work.

So: Yes, you'll need to include those permissions at the assembly level. And like JaredPar says, you might as well use full-trust.

Henk Holterman