I’ve found static constructors very appealing in .NET class design. I think this is partially due to coming into .NET with a C++ background. Although there are techniques available to achieve the same effect in C++, the language did not have the syntax to support the concept as elegantly.

The first time I received the “Do not declare explicit static constructors” message from FxCop I was a bit dismayed. Why is it telling me there is a performance penalty for a static constructor? One caveat I’ve always had with FxCop is that the tool enforces design guidelines for a framework, and these guidelines are not necessarily the same guidelines you’d want for an application. To get to the bottom of the critical warning message about static constructors required some research.

The key is a metadata flag the compiler adds to a class without an explicit static constructor – the beforefieldinit flag. In the code below, both Foo and Bar should appear identical in their behavior, and really they are almost identical if you look at both with a decompiler. The difference is, Foo will have the beforefieldinit flag, and Bar will not.

class Foo
{
    public static string Message
   {
      get { return _message; }
   }
 
   static string _message = "Hello World!";
 
}
 
class Bar
{
   static Bar()
   {
      _message = "Hello World!";
   }
 
   public static string Message
   {
      get { return _message; }
   }
 
   static string _message;
}’

Brad Abrams has some details about beforefieldinit in his blog post from earlier this year. However, after doing some experiments I’d give a slightly different description about the effects of beforefieldinit.

The beforefieldinit flag allows the runtime to be very ‘eager’ in calling a static constructor, a.k.a a type initializer. This is in contrast to being lazy and calling the static constructor at the last possible moment (in hopes you might not need to call it at all). The difference between eagerness and laziness can be demonstrated by timing the following code using Foo and then Bar.

for(int i = 0; i  <  Int32.MaxValue - 1; i++)
{
   string s = Foo.Message;
}

In my experiments, looping with Bar (explicit static constructor) will perform about 5x slower than looping with Foo (implicit static constructor and beforefieldinit set). With Bar in the loop, the runtime must invoke the static constructor at the last possible moment (the spec says it), so the check to see if the type constructor needs invoked is inside the loop. With Foo and the beforefieldinit flag, the runtime is free to eagerly execute the static constructor before the loop starts and thus avoid the overhead of further checks.

Obviously I’ve created a worst case scenario to see the possible performance impact, and performance should not always dictate design decisions. Still, I’m a little disappointed that my beloved static constructors feel a little bit tainted now.

If you are looking for online resources about the ASP.NET Community Starter Kit, here are a couple places to look:

Stephen Redd’s Site (full of CSK Articles, Mods, and Fixes)

Dave Rank’s Personal Web Site

Matthew Roche’s CSK Resources 

Football season (American) started today. To be precise, it started on Thursday night, but since we never had football games on Thusday nights when I was growing up as a kid, I tend to pretend this doesn’t happen.

A few years ago, my interest in pro football was on the decline. This was around the time when football began to morph from being a team sport into a form of modern dance, and players began to augment their costumes with cellular phones and permanent markers. Plus, the Steelers can never seem to get back to the super bowl, so, really, who cares?

One way to make anything interesting is to have a pool. A pool is where a bunch of people will put money into a pot and predict the outcome of some event, like football games. Whoever picks the highest number of game winners correctly wins a percentage of the pot.

Being in an office football pool is not about winning money, which might be enough to buy lunch for two. It’s about winning the pool and having bragging rights for a week. Winning means going to work and pretending you really knew what was going on when you made your winning selections, even though you might not have done it alone.

Me: “Alex, who do you think will win – the Eagles or the Browns?”

Alex (my now five year old son): “What is a Brown?”

Me: “Well .... it’s basically a dull color”.

Alex: “Eagles!”.

A few years ago I started a little pool at the office by sending an email to the staff@ alias (first mistake). This brought a response from the human resources department that football pools fall into a ‘legal grey area’ and I should refrain from mentioning ‘football pool’ at work. No problem, I thought, I had an email list of 30 people interested in a little fun, so I fired off an email to this list without actually checking who was on it (second mistake). Well, it turns out our CFO was on the list, and I’m not sure why, because he never actually played in the pool, but he did, it seems, mention to HR that I was running a football pool.

The next day I stood in the office of the Supreme Ministry Of Human Resources and explained why I disobeyed a direct order. I had to cross my heart, and swear that I would not be using company resources to run illicit gambling activities. It was the last pool I ever ran, and my time spent watching football is asymptotically approaching zero. If the Steelers make the playoffs, somebody please let me know.

On October 5, 2004 I’ll be talking about the Community Starter Kit for the CMAP .NET User Group meeting in Columbia, MD. I plan to focus in on a couple key pieces of the architecture that can be applicable to ASP.NET applications today and tomorrow. The presentation will stay practical, and I hope to use only two buzzwords during the talk: indirection and virtualization.

To finish the talk I’ll touch on customization and deployment of the CSK, which hopefully doesn’t put everyone to sleep. If it does, I plan to make off with all the free pizza, soda, and raffle prizes before the audience wakes up.

On October 16th and 17th I’ll be at Microsoft’s Waltham, MA facility for Code Camp II: The Return. I have a session to talk about techniques for integrating SQL Server Reporting Services into ASP.NET applications. Although I have not spent much time with the report designer I have spent a fair amount of time investigating ways to hook into SSRS programmatically. This talk will focus on improving the sample report viewer component for use in the real world, and tips / tricks / traps with the web service API.

I only hope my session doesn’t overlap with some of the sessions I really want to see while I’m there, because there is some great looking content and speakers. I also hope this software developer from Boston doesn't show up, because quite frankly, she scares me.

I have a slew of SSRS articles to build from, you’ll probably see more here soon as I work on the presentation.

Authentication, Role-based Security, and SQL Reporting Services Web Services

Introduction To Role-Based Security In SQL Server Reporting Services

The Blog Delivery Extension

 Embedded Code In Reporting Services 

Using GetReportParameters in Reporting Services 

Using CreateSubscription and the Reporting Service API

SQL Reporting Services Tree Navigation Sample using a Web Service API

This just in from the Microsoft Downloads RSS feed!!

Microsoft Calculator Plus is now available!

Update: The CalcPlus link seems to lead nowhere now. It really did exist for a time. Donna Buenaventura saw it too. The plot thickens....

Everyone has been talking for years about how Microsoft has killed calculator innovation by including calc.exe with the operating system. After all those messy anti-trust suits and allegations of anti-competitiveness, Microsoft has finally answered the critics. The calculator dev team has been back in feature development mode. A new age of calculation is upon us. Prepare your eyes as I now convert barleycorns¹ into feet!!

1: From Sizes.com. In England and Scotland, at least as early as the 12th century an inch was thought of as 3 barleycorns laid end to end. A document of 1474 states: “III barley corns take out of the middes [middle] of the Ere make an Inche and XII inches makith a foote and III fote makith a yarde.” 

When I first started working with SQL Server (v 7.0), I found two part / four part names a bit confusing:

            SELECT * FROM ownername.tablename
            SELECT * FROM servername.databasename.ownername.tablename

What would confuse me was why anybody would want an owner name - a login - appearing as part of a fully qualified database object name. This creates all sorts of limitations. If an admin needed to remove a user, all the objects belonging to the user had to be dropped or reassigned – breaking all queries, views, and stored procedures with two part names. Since nobody wanted to tie an object to a user, we created databases where dbo owned all objects – forcing permissions to be granted on an object-by-object basis.

Linking users to objects also created all sorts of unfortunate naming conventions. Take .Text for instance, which prefixes all database object names with “blog_”. Likwise, the Community Starter Kit prefixes all object names with “Community_”. This practice allows these applications to work in hosted environments and share a common database without object naming collisions, but it feels ugly.

Thankfully, SQL Server 2005 gives us schema. Objects now belong to a schema. A database may have multiple schemas.

            SELECT * FROM schemaname.tablename
            SELECT * FROM servername.databasename.schemaname.tablename

No longer does the designer have to worry about naming conventions to group tables. A database designer can instead think about what the functional area of a table will be. For instance, the new AdventureWorks sample database in 2005 groups user tables into schemas like “HumanResources” and “Shipping”.

Schema separates users from database objects and functions similar to a namespace. The schema is also a container, and permissions can be assigned at the schema level instead of on individual objects. Schemas are an additional layer of indirection. Admins can drop users without worrying about reassigning object ownership. Schemas are flexible. Queries with two part names don’t feel so brittle anymore.

I thought of a little saying. It goes like this:

Users come and go, but schemas are forever.

Is this poetic? Or Corny? Does it belong in a book of prose? Or printed on some t-shirt and sold at a discount stand by the beach?

John is addicted to chocolate. I think I am too. Just recently, I noticed a new product in the vending machine at work. It’s a chocolate bar with miniature M&M’s inside. Just think – you have pieces of chocolate inside of hard candy shells then embedded into a larger bar of chocolate. Human achievements just never cease to amaze me.

I somehow resisted the urge to plunk money into the machine and go on a chocolate feeding frenzy. I wish they wouldn’t keep these in the machine - it would be much easier to resist the spicy pork rinds Heather finds in the vending machines at Microsoft. I’m 40 pounds lighter than I was in 2002 and I’m not going back. I carefully monitor my chocolate intake.

In my searches for the latest in chocolate tech, I discovered the “Course In Chocolate Technology”. This course covers everything from cleaning, roasting, winnowing, and grinding the cocoa bean to chocolate viscosity exercises with polyglycerolpolyricinoleate. Doesn’t that sound yummy? Maybe understanding the underlying science and chemicals of modern chocolate manufacturing would cure my addiction.