Skip navigation

New Security Tools in Visual Studio 2005

The Permissions Calculator

Secure ASP.NET




New Security Tools in Visual Studio 2005

The Permissions Calculator


By Don Kiely


It s here! It s here at last! On Monday, November 7th, after years of demonstrating vaporware, talking about features that might or might not make it into the final product, whipping up frenzied excitement for its vision of the new generation of development tools, and a painfully long beta period, Microsoft finally released the 2005 versions of Visual Studio and SQL Server. I m sure that you joined the legions of developers around the world who celebrated the release by taking the first few days of this week off work to celebrate and geek out with the new tools, staying up until all hours to relish our newfound power.


Or perhaps, more likely, like me you paused on Monday when reminded of the date and raised your early morning mug of Mountain Dew in silent salute to yet another milestone in Windows development, then got back to work on that ASP classic or ASP.NET 1.1 app that your company won t migrate for many months. But that s okay. Maybe it won t rock your world today, but I bet it radically changes how you develop Web sites at the very least by making them far more secure.


No matter how you marked the occasion, the fact that you re reading this column probably means that you re concerned with writing secure Web applications. The really good news is that this has become way easier in Visual Studio 2005. Version 2.0 of the .NET Framework has many security enhancements. There are more and better tools that make writing secure code far more possible (and even enjoyable). I have to give credit to the folks at Microsoft for putting in so much work in this area. Sure, there is still plenty to do and it doesn t help that there is so much work left to be done to make Windows itself more secure but if you care about your users and the security of their systems and data, you can do a much more credible job with the new tools.


In fact, for all of the nifty new ASP.NET features, I still think that the security enhancements are by far and away the best reason to migrate to the 2005 and 2.0 versions. So what are these tools I m so excited about? In the rest of this column I ll tell you about one of my favorite new security features; next month I ll cover a few more, as well as why I think they ll change the way we all write code. Most of the new security tools aren t specific to ASP.NET applications, but instead help you write any kind of .NET code more securely. A rising tide floats all boats, as they say, and all applications can benefit but only if we all take a little time to learn how to put them to good use.


One of the most important things you can do is learn how to write partially trusted applications. I ve written and talked about them a lot over the years in this column, at conferences and user groups, and in articles but few developers take the time to carefully design applications that don t require full trust to run. Partially trusted applications don t automatically receive every available permission, and therefore do a better job of restricting access to protected resources. In other words, and grossly oversimplifying, partially trusted applications are capable of less evil than their fully trusted brethren.


But developing partially trusted applications, particularly Web applications, has just been too darned hard. One of the most difficult things about it is figuring out what permissions your code requires to run successfully, and making sure that you degrade gracefully when the application doesn t have it. This is particularly true of server applications, because the typical user is usually powerless to do anything about the problem. Telling them to talk to an administrator to get the required permission just doesn t work.


So Microsoft included the Permissions Calculator in Visual Studio 2005. The calculator scans your code and tells you what permissions it requires in order to successfully execute the code. It does this by performing a static analysis of every .NET Framework class and method used and extrapolates the required permissions using internal data that describe the security of each class and method. The result is a list of all the permissions that your code has, and any that it needs, but doesn t have, given the defined environment.


Alas, the calculator is of no use for ASP.NET Web sites and the code behind any pages. But wait, before you call me nuts for writing about it here, consider that not all code in an ASP.NET application lives behind pages. Creating a partially trusted ASP.NET application is still a largely manual process of configuration, and requires some special care in how you design class libraries and other components. It is for these class libraries and other components you create to run from ASP.NET page code that the Permissions Calculator becomes useful. The issue here is that you have to jump through a few hoops to make your class libraries callable from partially trusted applications of any type. Here the calculator is a big help in making sure that the code will run when called from Web pages, eliminating much of the guesswork involved in doing the same thing in earlier versions of the .NET and Visual Studio tools. This makes it far easier to create these libraries and components.


To reach the Permissions Calculator, go to Project Properties and select the Security tab.


Join me next month as I look at a few more of my favorite new security tools in Visual Studio 2005.


Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at





Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.