I had the pleasure of seeing Rob Howard speak at VSLive! in San Francisco about a month back, and really enjoyed his presentation. His knowledge of the materials he presented was absolutely amazing. Since then, I’ve made it a point to read anything he puts out, as the information provided is invaluable.

Yesterday, part 2 of his article on the provider design pattern became available on MSDN. The provider model will be introduced as part of the .NET 2.0 framework. This new article discusses how someone would go about implementing this provider model using the .NET 1.1 framework.

While the article only covers implementation of the MembershipProvider, it is very easy to see how it can be applied to the other providers, including the Personalization provider, so that you can start using these right away.

Great work, Rob.

I’ve recently been participating in several .NET newsgroups, and I cringe everytime I see a posts asking for help where the answer involves elevating permissions.

When all else fails, throw excessive permissions at the problem. ARGH!!! Some of the better ones Ive seen are:

• Grant EVERYONE full control of c:\windows\microsoft.net\framework. I dont think I even need to explain why this is bad.
• Apply the APTC attribute. Keith Brown talks about this in one of his Security Briefs.
• Give the ASPNET account full control to a folder. Uh sure, let’s open that folder up to anyone with a web browser and an imagination…

When will people realize that elevating permissions unnecessarily to work around something, without finding the *real* reason to the problem, is why Windows has such a shoddy reputation when it comes to security?

If an application has problems writing a file, then grant write access, not full control. If an application can’t read a value from the registry, then grant read access, not full control.

Ideally, an application would be developed where the absolute bare minimum permissions are required. Should additional functionality require additional permissions, *then and only then*, just enough permission would be added to make the app work. I believe this is defined as the Principle of Least Privilege.

I’m ever so glad that VS.NET 2005 is making strides in this area by allowing debugging to occur with specific permission sets. Hopefully soon we will see an end to this madness.

*Update:* Looks like Keith Brown has a new article on MSDN discussing security in Longhorn and the focus on least privilege. Wahoo!

The Patterns and Practices group has come through with another gem.

Improving .NET Application Performance and Scalability

*Abstract*: This guide provides end-to-end guidance for managing performance and scalability throughout your application life cycle to reduce risk and lower total cost of ownership. It provides a framework that organizes performance into a handful of prioritized categories where your choices heavily impact performance and scalability success. The logical units of the framework help integrate performance throughout your application life cycle. Information is segmented by roles, including architects, developers, testers, and administrators, to make it more relevant and actionable. This guide provides processes and actionable steps for modeling performance, measuring, testing, and tuning your applications. Expert guidance is also provided for improving the performance of managed code, ASP.NET, Enterprise Services, Web services, remoting, ADO.NET, XML, and SQL Server.

This is a must read if you’re doing .NET development and are concerned about performance.

It has been almost three months now since I have taken the plunge and removed myself from the administrators group and started doing everything with a less privileged account. I’ve found that it greatly changes the way you think about writing certain pieces of code.

One thing that has been bugging me for a while is the apparent inability to access windows explorer from this non-privileged account via the runas command. However, Peter Torr has a great tip to get around this.

From your admin console, navigate to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced and set SeparateProcess DWORD to 0×01.

Google Inc., the world’s No. 1 Web search provider, filed with U.S. regulators Thursday to become a publicly listed company and sell as much as $2.7 billion in stock in a widely expected initial public offering.

[via FoxNews.Com]

I was really pleased to find that getting NUnit 2.1 to work with the VS.NET 2005 March CTP is really quite trivial.

In Program Files\NUnit v2.1\bin, open nunit-console.exe.config and nunit-gui.exe.config and add the following line to the startup section, directly below the requiredRuntime.

Restart NUnit, and it runs just fine with VS.NET 2005 and you can test code compiled under VS.NET 2005.

During the past few weeks, I’ve learned way more about InstallShield than I ever wanted to know.

Several months ago, I was tasked with creating an installer for one of our applications at work. Thanks to DevStudio, the installer originally seemed to be pretty painless.

Unbeknownst to me at the time, some of the defaults that InstallShield sets for you are just ridiculous (ie: components are shared by default). During the last two weeks, I’ve spent some time reworking this installer and ironing out some of the kinks.

I’ve found two great resources for dealing with these sorts of issues.

Michael Dunn’s Ten Tips for Well Behaved Application Installations and Bob Baker’s Practical Windows Installer Solutions for Building InstallShield Setup Applications.

Matt Hawley has a post that details the first measurements that I’ve seen regarding the effects of Test Driven Development (TDD).

Some of the interesting numbers:

• 95.8% of developers reported reduced debugging efforts.
• 79% of developers thought that TDD promotes a simpler design
• 92% of developers felt that TDD yielded high-quality code.

The challenges of TDD:

• 40% of developers found adoption of TDD was difficult.
• 16% increase in development time of projects.

I’ll be the first to admin that getting into the TDD mindset is quite difficult. There is nothing to force you into doing it other than your own willpower. For me, a great difficulty came from knowing what types of conditions to test for. I recently purchased and downloaded Pragmatic Unit Testing in C# by the Pragmatic Programmers. This books seems to bridge the gap for me, and things are really starting to click.

Interesting note about the 16% increase in development time (from Matt’s reference article) is that the variance in the performance of the teams was large, and the control group did not write any worthwhile automated test cases (even though they were instructed to do so). This factor would make the comparison uneven.

Even if the control groups were identical, is a 16% increase in development time justified if you know that you have a comprehensive set of unit tests that would allow you to more easily add features in the future with confidence?

Brian Pepin gives an excellent introduction to System.ComponentModel on UrbanPotato. This namespace can be used to easily create scalable, extensibile applications using the techniques he demonstrates.

Fantastic work…

[via Chris Anderson]

One statement that I have heard incessantly is that foreach over an array is slower than for (int i = 0; i < array.Length; i++).

Finally, some good people have debunked this myth:

• Kevin Ransom — To foreach or not to foreach, that is the question.
• Eric Gunnerson — Efficiency of iteration over arrays

I personally find it *SO* much nicer to look at code like:

foreach (int i in array)
{
    Console.WriteLine(i.ToString());
}

as opposed to:

for (int i = 0; i < foo.Length; i++)
{
    int item = foo[index];
    Console.WriteLine(item.ToString());
}

mostly because the first code chunk is a lot more compact, and I think more clearly states its purpose.