This project has moved. For the latest updates, please go here.

SplitButton changing SecurityContext

Sep 27, 2012 at 3:42 PM

This has me stumped and I'm unable to produce a "simple test" that displays the behaviour.

Before:

Standard WPF Button invoking a Command containing

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)

This works fine.

Replace with SplitButton invoking the same command I get an 

System.Security.SecurityException

Request for the permission of type 'System.Security.Permissions.FileIOPermission ....

In addition to that if I drop down the contained items but then click somewhere else on the form again I get a security exception:

System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib,  ....

the bit of the stack trace that is relevant to Xceed is:

at Xceed.Wpf.Toolkit.DropDownButton.set_IsOpen(Boolean value)   at Xceed.Wpf.Toolkit.DropDownButton.CloseDropDown()   at Xceed.Wpf.Toolkit.DropDownButton.OnMouseDownOutsideCapturedElement(Object sender, MouseButtonEventArgs e)

I've inspected the SecurityContext in both cases when it's called through WPF button the context is as expected but when called through SplitButton I get:

(System.Security.SecurityContext.Capture().CompressedStack.PLS.m_originList)._items[0] = <the full debug path to WPTToolkit.Extended.DLL>

(System.Security.SecurityContext.Capture().CompressedStack.PLS.m_zoneList)._items[0] = "Internet"

So for some reason it suddenly thinks it's been loaded via the internet any ideas?

 

 

Sep 28, 2012 at 1:23 PM

Is your toolkit dll located on a network drive, or a network folder or it is located directly on your hard drive ?

Sep 28, 2012 at 7:59 PM

The dll is located on the hard drive, the same location as the main application

Oct 16, 2012 at 5:16 PM

It looks like the dll was "blocked" after having unblocked the file in the file system the error went away. It's strange that only this area of the code had the problems.