One of the more difficult things to debug with .NET 1.0 and 1.1 is the security exception. With these frameworks generally the only information that you got was the state of the failed permission. Due to the complexity of debugging security problems, most people just gave up and required that their code run in a fully trusted environment. With Whidbey we've done a lot of work to beef up the security exception, and make debugging security issues even easier, in the process making it easier for developers to figure out the minimum set of permissions that their application needs to run under.
Currently, the SecurityException contains four security specific properties.
Generally, PermissionState is the only property that can be depended upon to always have a value. This does not provide for a good user experience.
The Whidbey SecurityException adds several more properties, which together allow developers to figure out what code was causing a security problem. The new properties are:
As you can see, there's a ton more data available about the cause of the security exception in Whidbey. However, as I noted above, even the current SecurityException properties don't get filled out properly all the time. As part of the SecurityException enhancement work, we've gone through all the places in the BCL that throw exceptions and ensured that they've filled out as much of the SecurityException data as possible.
All of these extra properties provide a lot of information for developers to work with if they catch the SecurityException in their code. But what happens if the exception goes unhandled? The default behavior of spewing exception information to the screen will still provide a lot more information than was provided before. For instance, if I tried to run my ProtectedData sample off a network share, with default policy in place, I'd end up with a SecurityException. The debug spew for that exception would look similar to the following.
First comes the standard stack trace and exception type that failed.
In addition to all the work done in the CLR to make debugging security exceptions easier, Visual Studio 2005 has done quite a bit of work as well. When an unhandled SecurityException is thrown under the VS debugger, Visual Studio will look at all of the extra properties that are populated on that exception, and provide you with context sensitive help to solve the problem.
As you can see in the screen shot, VS will highlight the line that caused the SecurityException, and shows a pop up dialog that tells you the permission that failed and provides several possible solutions for the problem. In this case, there's not a lot of ways to get around the DataProtectionPermission demand, so the options that VS presents include turning this into a ClickOnce application or installing locally. This help is based around the failing permission, so if a FileIOPermission failed, VS might suggest using IsolatedStorage instead.
The View Details link will, oddly enough, open up the View Detail dialog where you can inspect each property of the Security Exception yourself, in order to help you further track down security issues.
All that's fine and good, but when you develop on your local machine, you end up with FullTrust by default. Forcing developers to modify their security policy to debug is not a good user experience, so again Visual Studio steps up to the plate, this time with a feature called Debug In Zone.
By going to your project properties, and accessing the security tab, you can specify the set of permissions that you'd like to debug your application with. For instance, if your goal is to have your application run with Internet permissions, then just select Internet from the drop down list. You can also create a custom permission set that reduces down to the exact set of permissions that your app needs; the Calculate Permissions button, which will interface with PermCalc will help you with this goal.
With the changes to the SecurityException class and enhancements to the Visual Studio debugger, figuring out the cause of those hard to diagnose SecurityExceptions.