March 2005 - Posts
This week I was asked if I knew more on the API changes which occurred during development of the .NET Framework 1.1 and 2.0. Though I know there are changes in the APIs between the .NET Framework 1.1, Beta 1 of the .NET Framework 2.0 and Beta 2 of .NET Framework 2.0, I hadn't really a list of obsolete API's. Today I came accross this download link from the Microsoft Download Center. It comes with a number of html pages listing the .NET Framework Beta 2 Obsolete APIs.
Below a summary of the number of obsoleted members and types for Beta 2.
| Assembly Name (click for details) |
Obsoleted Members |
Obsoleted Types |
| Microsoft.VisualC.dll |
Members:0 |
Types:2 |
| mscorlib.dll |
Members:85 |
Types:5 |
| System.Configuration.dll |
Members:3 |
Types:0 |
| System.Data.dll |
Members:8 |
Types:1 |
| System.Deployment.dll |
Members:2 |
Types:0 |
| System.Design.dll |
Members:2 |
Types:1 |
| System.dll |
Members:19 |
Types:4 |
| System.ServiceProcess.dll |
Members:1 |
Types:0 |
| System.Web.dll |
Members:1 |
Types:0 |
| System.Windows.Forms.dll |
Members:54 |
Types:13 |
| System.Xml.dll |
Members:6 |
Types:0 |
| VJSSupUILib.dll |
Members:11 |
Types:0 |
So for those of us looking forward to Beta 2 and developing applications to go live within the Beta 2 (or later) timeframe, do not rely on these obsoleted APIs because they won't be available when shipping Visual Studio 2005. It's good practice to get your code compiled without obsolete warnings.
Last week at customer site we deployed a new release of our web-based line-of-business application. This major release includes besides some business services, role-based security. As the design of the application was done without security, it took quite some effort to build the security smoothly into the architecture and design of the application.
We used Authorization Manager (AzMan) to take care of the administration of our role-based security. Access to the application is provided by the administrator through user roles that relate to job functions. Our application stores the defined authorization policy in the form of an authorization store that is stored in an XML file. This authorization policy is applied at run time and manageable through the AzMan interface. Applications call a run-time access check method that checks access against the policy information in the authorization store.
After validation of the role-based security implementation by our testing-team, we planned and deployed the application into the production environment. Some smoke tests showed us that we got it right. Big was my surprise when two days later I was called, saying a user had an "Access Denied" error-page. After having checked the user's authorization policy, we turned on logging on the AzMan wrapper class (which also provides some other features like caching etc.). Simulating the "Access Denied" application error was difficult because it appeared randomly. After successfully reproducing the error the logfile showed the message "The specified domain either does not exist or could not be contacted". Some googling directed us to the Microsoft Help and Support site. As described here, this error message is thrown when the AuthzInitializeContextFromSid function passes a non-null-terminated string to the DsGetDcName function. This problem can be resolved by installing a hotfix provided by Microsoft. Instructions to download and install the patch can be requested here.
Once the patch was installed the error was not encountered anymore. Problem solved!
After all, implementing role-based security through AzMan was pretty straightforward. However, critical for the success in my opinion is:
- making good choices for roles, tasks and operations.
- having a clear view on how to implement security in your application is key.
- as a lot of security checks will have an impact on the application performance, caching security information and retrieving it when required is worth considering.
Worth thinking about:
- if possible within your environment consider using the Enterprise Library Security Application Block for building common security-related functionality into applications.
- if you're building Visual Studio 2005 applications, also have a look at the Permission Manager for ASP.Net 2.0 on the GotDotNet workspace. It's a provider based solution and with this manager you can add permission to object for roles and users. The Permission Manager will also use the Roles manager if it's enabled. A new version also includes Authorization Manager.
Here are some good resources on implementing role-based security in multi-tier applications using Authorization Manager:
Michael Howard reports that the document "The Trustworthy Computing Security Development Lifecycle" has been published on MSDN. This document outlines the security-related process improvements that Microsoft has been working on. It provides insights and guidance on how to improve the Security Development Lifecycle Process.
As I've been involved in defining process guidance for techical reviews (eg. code reviews) lately, it's interesting to see that Microsoft uses static analysis tools, fuzz testing, and manual code reviews while conducting code security reviews. As we've used a similar process - with success - the article is a must-read for anyone willing to improve his development skills.
Check also out Dana Epp's post on this topic!
I came across this post where Hisham Baz analyzes the performance of the Enterprise Library Logging Block using Compuware's DevPartner Profiler Community Edition. It looks like Enterprise Library could use some performance optimizations for its next version.
Hisham also has a number of other - worth reading - posts on Enterprise Library:
Both the Base Class Libraries-team and Julia Lerman are summing up an impressive number of blog posts: 35 in total. If you're looking for tips on how effectively use the .NET Framework, sit down and read, listen and watch!
Here's the list:
Cliff Atkinson answers why speakers should start a blog and why bloggers should go speak in public.
What speakers can learn from good bloggers:
- Express your personality
- Speak truthfully
- Tell us something we didn't know
- Open up a conversation
What bloggers can learn from good speakers:
- Find your focus
- Look for the story
- Make the personal universal
- Develop your craft
As both speaking and blogging are two ways to express ourselves it comes to get the message out clearly in a way that opens up mutual understanding. He also has a tip: if you're a speaker, start a blog. If you're a blogger, go speak in public!
Last week Jason Matusow, Director of Shared Source for Microsoft, has started a blog. In his second post - "More Open Than Open" - Jason gives a great overview of some of the different types of source licensing.
Microsoft has three Shared Source projects (WiX, WTL, and FlexWiki) under the Common Public License. A complete list of Microsoft's Shared Source Licensing Programs can be found here. These programs have only be designed with one goal in mind: meet the unique needs of the development community.
And if you're a C# developer looking for open-source projects, don't forget to take a look at the CSharp-Source.Net site. This site lists a large number of open source C# projects: from aspect-oriented frameworks to open source XML parsers. All developed in C# by the community and for the development community!
Yesterday we ran into some strange issues at customer site after deploying the server-side services of our application. These services are exposed through .NET Remoting to our own client-side application and to other applications. As these kind of deployments are rather routine than something exceptional, we wondered why the response to a remote call threw the following exception:
"Server encountered an internal error. For more information, turn on customErrors in the server’s .config file"
The first thing we checked was if our .NET Remoting services sent the same responses on requests of the applications installed on the same (physical) server as on requests coming in from other (physi