.NET Gotchas

Of Sobriety Tests and Loop Iteration

Chris Falter — Thu, 08 Nov 2007 11:44:40 GMT

A few years ago I listened in fascination to a radio interview with a highway patrol officer who was describing how she conducted field sobriety tests. In addition to the typical tests of walking in a straight line and of standing on one foot, she would ask the erratic driver to recite the alphabet. One driver slurred, "A. Is that good enough?" "That's all the alphabet you can recite?" she responded. "Yep," he answered. She booked him. She would also ask drivers to count backwards from 100. If a driver skipped around or had to think hard, his mental facilities were not sharp enough to permit him to drive safely.

Counting backwards can also come in handy when you're performing a loop iteration. For years we had some data access code that looped through a DataRowCollection in order to commit changes to a DB2 database:

public void SaveRows(DataTable tbl)

{

    string spName = null;

    for (int i = 0; i < tbl.Rows.Count; i++)

    {

        DataRow row = tbl.Rows[i];

        DataRowState rowState = row.RowState;

        if ((rowState & DataRowState.Unchanged) > 0)

            continue;

        switch (row.RowState)

        {

            case DataRowState.Added:

                spName = "SPI" + tbl.TableName;

                break;

            case DataRowState.Modified:

                spName = "SPU" + tbl.TableName;

                break;

            case DataRowState.Deleted:

                spName = "SPD" + tbl.TableName;

                break;

        }

        try

        {

            IDbDataParameter[] parms = DataHelperParameterCache.GetSpParameterSet(DataHelper.ConnectionString, spName);

            CallStoredProc(spName, parms, row);

        }

        catch (Exception ex)

        {

            if (tx != null)

            {

                tx.Rollback();

                rolledBack = true;

            }

            throw new BaseApplicationException("Fatal Exception while running stored proc " + spName, ex);

        }

    }

}

Then after we had called this function on all the DataTables in the DataSet, we called DataSet.AcceptChanges(). This code generally worked well.

Then one day we realized that by not using a IDbTransaction (we left it null) and calling DataSet.AcceptChanges() at the end, we would leave our DataSet in a state inconsistent with the data store if a failure occurred part way through the process of saving tables and rows. For example, if a row had been inserted to the data store, but AcceptChanges() had not been called, then its RowState was still DataRowState.Added. And the next time a user tried to save his work, our system would try to insert an additional row, rather than updating the row that was already in the data store. So we decided to call DataRow.AcceptChanges() after each row operation (after the call to CallStoredProc in the above code).

A few days later, our testers reported that the last of 2 delete operations would no longer commit to the data store. What? How could adopting a new strategy for accepting changes cause that kind of bug?

Well, what happens when you call DataRow.AcceptChanges() when the RowState is DataRowState.Deleted? Poof! It vanishes into thin air. As a result, the next row would get skipped over in the loop iteration, since its ordinal had shifted back by one.

Allow me to illustrate: you've got 2 rows, and you're going through the loop. The first time you enter the loop body, i is 0 and you're working with Rows[0], the first row. Before you finish the loop, you call DataRow.AcceptChanges(), and the row disappears in a cloud of smoke, alakazam! Now the row that used to be at Rows[1] shifts back to Rows[0], and Rows.Count == 1. And we're at the end the loop, so we increment i to 1 and do the test:

i < tbl.Rows.Count

This statement is false, so we exit the for loop. Thus the row that shifted from index 1 to index 0 (when its sibling vanished) never got processed.

My first thought on fixing the problem was to use a foreach loop and let it figure out how to deal with the deletion for me. However, the DataRowCollection quite correctly threw an InvalidOperationException when we tried it, and I can't blame the class designers for the behavior. Remember, the iterator is supposed to keep track of the Current and the Next member of the collection as you traverse it. But if you delete the Current member, where should Current point to? Can it point to the member of the collection immediately following the deleted member? Not really; Current and Next would then be referring to the same member. And if the iterator shifted the Next by one to avoid the clash, the same way it shifted Current by one, we might skip over the collection member that immediately follows the deleted member when the iterator's MoveNext method is called. As the .NET Framework documentation states:

The foreach statement is used to iterate through the collection to get the desired information, but should not be used to change the contents of the collection to avoid unpredictable side effects. [emphasis mine]

My colleague Kyle then came up with a terrific idea: just count backwards! Start at the last member and iterate back to the first; and if a member is deleted, the loop still operates correctly. So now our code looks like this:

for (int i = tbl.Rows.Count - 1; i >= 0; i--)

{

    // everything else is the same as before

}

You might not think the great programmers grow up in Appalachian hill country, but Kentucky Kyle has been full of pleasant surprises for us ever since we were astute enough to hire him. Or maybe they just have to deal with field sobriety tests a lot more in the Kentucky hills. Whatever the background, my hat is off to Kyle for his excellent idea.

Website Projects and Windows Authentication: a Volatile Mixture

Chris Falter — Fri, 02 Nov 2007 15:01:43 GMT

Vinegar is an important ingredient in the kitchen; with it you can make baked tropical spareribs, Indian mutton curry, orange almond greens and a host of other delightful dishes. Baking soda, too, is an essential ingredient in nutmeg raisin coffee cake, buckwheat pancakes, and many other delectable baked goods. Both are useful, reliable, and safe in storage. However, as any fourth-grader who has ever attended a science fair can tell you, all you have to do is mix the two to create a volcano that will spill lots of red, flowing "lava" all over your kitchen tile.

Today one of my colleagues inadvertantly created a code volcano when he incorrectly mixed Windows authentication with an ASP.NET 2.0 website project. (Of course, I was responsible for reviewing the code [Ahem!] so I'm in no position to point fingers.)

The site has the responsibility of displaying GIS data to internal users. Certain of the data are restricted to users who belong to certain Windows groups; the restriction is managed through database views. My initial thought was to create a separate directory for each group, and to let each page in a directory derive from a custom page class which would define the database view to use. Then we could write a location element in web.config with a directory-specific authentication element (under system.web) to ensure that only the members of the appropriate group could view the directory's pages.

But my colleague had a much better idea; the main site could select the appropriate view based on the group membership(s) of the logged-in user. The code he checked in this morning for the site's base page class contained the following:

    Public ReadOnly Property UserGroups() As List(Of String)

        Get

            Dim groups As List(Of String) = New List(Of String)()

            For Each idref As IdentityReference In WindowsIdentity.GetCurrent().Groups

                groups.Add(idref.Translate(GetType(NTAccount)).Value)

            Next

            Return groups

        End Get

    End Property

The page class would then check for group memberships (in order from least restrictive to most restrictive) in the List<string>. It would select the database view that corresponded to the first match. If it did not find a match, it would transfer the user to an error page ("Unauthorized.aspx").

To test this design my colleague ran the site in debug mode on his machine, and saw that he was able to use the view corresponding to his group membership. To test users with other group memberships, he turned on Windows impersonation in web.config...

<identity impersonate="true" userName="MyDomain\TestGroupMember" password="TestGroupMember"/> 

...and everything worked as expected. He commented out the identity node in web.config, checked in his code, and we promoted it to a test environment.

Knowledgeable readers can anticipate what happened next: when I accessed the site's index.aspx on the host server, I got a chance to review the look-and-feel of Unauthorized.aspx, even though I was a member of the least restricted group.

So why was the behavior different running on IIS than on the developer machine? On a developer machine, the website is hosted in a process called WebDev.WebServer.EXE running under the identity of the Visual Studio 2005 user. On Windows 2003, though, the website is hosted by an app pool running under the identity of whatever's configured in IIS (by default, the server's "Network Service" user). The UserGroup property's call to WindowsIdentity.GetCurrent() returns the Windows identity of the host process, *not* the WindowsIdentity of the authenticated user. When the code ran on a developer machine, this was not a problem; the identity of the site's user and the host process were identical. But when the code ran on a server, it would try to find a database view associated with the "Network Service" user. And since none existed, it would refer the user to Unauthorized.aspx.

(Note to self: never repeat the mistake of testing user logins via identity impersonation.)

Once we understood the error, correcting it was not too difficult. My colleague simply called the (System.Web.Security) Roles.IsUserInRole() method, passing in the role names from least restrictive to most restrictive. Behind the scenes, ASP.NET is basing its role management on the logged-in user's roles. When a site is configured to use Windows authentication, the user's roles are the same as the user's Windows group memberships. Now everything works the way it's supposed to, and Daddy can go home and have dinner with his family.

Do NOT Set up a Reparse Point for the Windows\Assembly Folder!

Chris Falter — Mon, 16 Jul 2007 13:31:27 GMT

Our build server (running Windows 2003 Server) was set up with 2 partitions: a small system partition (C:) and a large data partition (D:). As we installed more and more software packages on it, the system drive filled to capacity. In order to free space on the system partition, we moved a variety of directories from drive C to drive D, and then used the Junction utility from SysInternals (now owned by Microsoft) to create reparse points on drive C that pointed to the new file locations on drive D. A reparse point is a symbolic link that redirects a file request from one point to another on the same computer. In this case, the reparse points allowed applications to access files supposedly on drive C, while in fact they were on drive D. Storage problem solved, all was well...or so we thought.

This storage reconfiguration strategy can be successfully applied for user profiles (via C:\Documents and Settings\) and a variety of applications that install to C:\Program Files by default. However, our decision to redirect file requests for the Global Assembly Cache (located at C:\Windows\Assembly) blew up in our faces when the most recent Windows security update (KB 928365, which corresponds to security bulletin MS07-040) was installed. After the build server was rebooted, we suddenly started seeing the following error show up in a variety of contexts:

Could not load file or assembly 'System.EnterpriseServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Web services and web applications running in ASP.NET 2.0 threw this error on first request, and Visual Studio 2005 builds/compiles would report this error as well. We tried a variety of troubleshooting steps, such as rolling back the security update, and reinstalling .NET Framework 2.0, but nothing worked...that is, nothing worked until we removed the reparse point for the GAC. Once we moved the GAC's physical file location back to C:\Windows\Assembly, everything suddenly began to function correctly.

Evidently there is some kind of security setting in the .NET Framework which does not allow updates to some (or all) of its assemblies anywhere outside of the original GAC location. For the time being, I do not have the time to satisfy my curiosity by researching why this is so. However, I do have a few minutes to warn my readers not to fall into the same trap: do not create a reparse point for the GAC folder!

How To: Write a Unit Test for Multi-Dimensioned Output

Chris Falter — Fri, 04 May 2007 13:42:42 GMT

One of the cool features of Visual Studio 2005 is that it can generate a unit test stub for a class or method. However, I recently discovered that the Unit Test plug-in does not know how to auto-generate an assertion for a method whose output includes a multi-dimensioned out parameter or return value. Here's the relevant stub code that VS 2005 generated for one of my methods whose output includes a multi-dimensioned array:

// generated code that creates a class instance called "target", plus other input + expected output parameters

string[][] homeAttributes;
string[][] homeAttributes_expected = null; // TODO: Initialize to an appropriate value

target.MethodBeingTested(in1, in2, out homeAttributes)

CollectionAssert.AreEqual(homeAttributes_expected[i], homeAttributes[i], "homeAttributes was not set correctly.");

So I edited the code to initialize homeAttributes_expected, then ran the unit test, and it failed. Okay, my code must have a bug...but when I reviewed the code for MethodBeingTested(), it sure looked right. Then I stepped through the unit test in debug mode. However, when I hit the breakpoint on CollectionAssert.AreEqual() and expanded the arrays, the data was exactly what I expected it to be. So maybe my initialization code for homeAttributes_expected was wrong...but no, it looked right. What was wrong with this picture?

(These are the kind of challenges that either bring out the best or the worst in a software developer. You either rise to the occasion, or become a broken, miserable, and somewhat sneaky creature that silently excises the CollectionAssert.AreEqual() statement so the unit test will pass. And I was not about to steal away quietly!)

I realized what must be happening: CollectionAssert.AreEqual() must be calling the object.Equals() method to compare each member of the collections. And in a multi-dimensioned array, the collection object being tested (the array of arrays) consists of members that are themselves collections (i.e., arrays). Since the built-in Array class in the .NET Framework does not override the object.Equals() method, CollectionAssert.AreEqual() will use the default object.Equals() method to compare the identity of the array members; in other words, it compares the address of the 2 arrays in memory. These will of course be different, so the assertion fails, and the unit test fails.

You have probably noticed that this post claims to apply to all multi-dimensioned output. That's because you will encounter the same problem if your output is a List<string>[], or a List<List<string>>, or any other multi-dimensioned object.

Fortunately, you can conquer this problem with some clever refactoring. Just iterate through the outer dimension, and call CollectionAssert.AreEqual on the inner collections. Write your code like this, and everything will work just the way you want it to:

for (int i = 0; i < homeAttributes_expected.GetLength(0); i++)
{
CollectionAssert.AreEqual(homeAttributes_expected[i], homeAttributes[i], "MethodBeingTested_homeAttributes_expected was not set correctly at index " + i.ToString());
}

Now CollectionAssert.AreEqual() compares two single-dimensioned collections each time it is called. As a result, when it calls object.Equals() on the members of the collections, it will use the member type's override of object.Equals()--in this case, String.Equals()--and the assertion works correctly.

Happy unit testing!

More on How To Re-throw an Exception

Chris Falter — Wed, 28 Mar 2007 21:37:00 GMT

Re-throwing an exception is a little more complex that I had realized. The gotcha, pointed out by helpful reader "Sander", is that when the initial exception is thrown from directly inside the try block, rather than from within a method call inside the try block, you will lose the line number of the faulty line of code, regardless of how you re-throw the exception. Here's some sample code that demonstrates what I mean:

using System;

namespace RethrowExTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Whoops! Re-throw from procedural code loses the line number of the exception");
            try
            {
                try
                {
                    int zero = 0;
                    int i = 1 / zero;
                }
                catch (Exception ex)
                {
                    Console.WriteLine("Inner catch:");
                    Console.WriteLine(ex.Message);
                    Console.WriteLine(ex.StackTrace);
                    throw;
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine("Outer catch:");
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.StackTrace);
            }
            Console.WriteLine();
            Console.WriteLine("However, re-throw from exception-throwing method retains the line number, as expected");
            try
            {
                try
                {
                    MethodThatThrowsException();
                }
                catch (Exception ex)
                {
                    Console.WriteLine("Inner catch:");
                    Console.WriteLine(ex.Message);
                    Console.WriteLine(ex.StackTrace);
                    throw;
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine("Outer catch:");
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.StackTrace);
            }
            Console.WriteLine();
            Console.WriteLine("New throw from procedural code loses the line number, as expected");
            try
            {
                try
                {
                    int zero = 0;
                    int i = 1 / zero;
                }
                catch (Exception ex)
                {
                    Console.WriteLine("Inner catch:");
                    Console.WriteLine(ex.Message);
                    Console.WriteLine(ex.StackTrace);
                    throw ex;
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine("Outer catch:");
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.StackTrace);
            }
            Console.WriteLine();
            Console.WriteLine("New throw from method loses the line number, as expected");
            try
            {
                try
                {
                    MethodThatThrowsException();
                }
                catch (Exception ex)
                {
                    Console.WriteLine("Inner catch:");
                    Console.WriteLine(ex.Message);
                    Console.WriteLine(ex.StackTrace);
                    throw ex;
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine("Outer catch:");
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.StackTrace);
            }
        }

        private static void MethodThatThrowsException()
        {
            int zero = 0;
            int i = 1 / zero;
        }
    }
} 

The output looks just like what we expected:

Whoops! Re-throw from procedural code loses the line number of the exception
Inner catch:
Attempted to divide by zero.
at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 15
Outer catch:
Attempted to divide by zero.
at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 22

However, re-throw from exception-throwing method retains the line number, as expected
Inner catch:
Attempted to divide by zero.
   at RethrowExTest.Program.MethodThatThrowsException() in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 103
   at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 37
Outer catch:
Attempted to divide by zero.
   at RethrowExTest.Program.MethodThatThrowsException() in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 103
   at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 44

New throw from procedural code loses the line number, as expected
Inner catch:
Attempted to divide by zero.
at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 60
Outer catch:
Attempted to divide by zero.
at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 67

New throw from method loses the line number, as expected
Inner catch:
Attempted to divide by zero.
   at RethrowExTest.Program.MethodThatThrowsException() in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 103
   at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 82
Outer catch:
Attempted to divide by zero.
   at RethrowExTest.Program.Main(String[] args) in C:\Projects\Tests\RethrowExceptions\RethrowExTest\Program.cs:line 89

How should we design our exception handling, then? Follow these 2 simple rules:

1. If you can reasonably expect any exceptions to be thrown only by methods called from within the try block, you can just call "throw" instead of "throw ex" and retain the debugging info you need. This is what I explained in the previous article.

2. If on the other hand there is a substantial probability of the exception being thrown directly from within the try block, you should log the exception's stack trace before you re-throw it.

P.S. I always welcome comments from knowledgeable readers like "Sanders." Thanks, man!

How To: Re-throw an Exception

Chris Falter — Fri, 08 Dec 2006 00:31:00 GMT

I've coached many youth baseball teams, and I've always put a lot of focus on developing pitchers. Your left fielder can be chasing butterflies, and the right fielder might have his glove off, and the third baseman can be making faces at his sister in the stands...but if the guy on the mound is mowing 'em down, your odds of winning are pretty good. To the uninitiated, pitching looks easy, but in fact it is one of the most difficult skills in all of sports. To throw a baseball with both force and accuracy requires the balance of a dancer on stage, the timing of NASCAR driver weaving through traffic, and the consistency of a pro golfer on the driving range. These do not come easy to a nine year old, so Coach Falter has spent a lot of hours helping aspiring pitchers learn to throw a ball.

But today Coach Falter is going to explain the secret of catching and throwing something else: an exception. Our first major web project had a lot of exception handling code that looked like this:

public static void Save(QuoteDS dsQuote)
{
   IDbConnection conn= DataHelper.NewConnection(DataHelper.ConnectionString);
   IDbTransaction trn=null;
   try
   {
      conn.Open();
      trn = conn.BeginTransaction(IsolationLevel.ReadCommitted);

      // ******************************************************************
      // Do a transacted set of updates, using data in the dataset dsQuote
      // ******************************************************************

// data update code here...

      // Commit the transaction
      if (trn != null)
         trn.Commit();
   }
   catch (Exception ex)
   {
      if (trn != null)
         trn.Rollback();
      throw ex;
   }
   finally
   {
      conn.Dispose();
   }
}

This code needs an exception handler in order to rollback any in-flight transaction. On the other hand, it needs to rethrow the exception so that a handler further down the stack can catch it, log it, and display an appropriate message to the user. This is the exception-handling pattern blessed by Microsoft for all non-masochistic programmers. (Masochistic programmers prefer to set up exception handlers in every function, and build an elaborate scheme of return codes and switch statements and Lord knows what else.)

However, the above code has a hidden flaw. I'll grab a cup of coffee while you examine the code carefully....

Okay, you've been patient enough, it's time for your reward. When the .NET Framework executes this statement:

throw ex;

it throws away all the stack information above the current function. So when you look at your error log, you won't know which line of code was executing when the exception was thrown. Sometimes this won't be a bother, but other times you will spend fruitless hours speculating on what might have happened. So we need a better approach.

Here's how you retain the full stack trace: just rethrow the exception like this...

throw;

That's right, all you need to do is remove one little word. Superficially, it is no more different from "throw ex" than the throwing motions on a change-up and a fastball. (Hint: they are supposed to be identical; the difference is in how the pitcher holds the ball.) But like the difference between a fastball and a change-up, the difference between "throw" and "throw ex" becomes obvious very quickly! So get out those code editors and start throwing like you're supposed to...and lift your knee almost up to your elbow during the wind-up....and step toward home plate....

EDIT 3/28/2007: Based on a reader's comment and further research, I have updated my advice. See "More on How To Re-throw an Exception" for the latest and greatest.

Visual Studio Team Server, the Gangly Adolescent

Chris Falter — Fri, 25 Aug 2006 04:44:00 GMT

As a high school sophomore I was 6'1“ tall and 140 pounds--a human bean pole. My arms shot out of my sleeves like beanstalks in Jack's garden. You could practically see my ankles emerging from the bottom of blue jeans as I stood before you. As a physical specimen, though, you could see on my frame what I would eventually become as an adult, after a little more maturation. I was a gangly adolescent.

I'm almost delirious that Microsoft finally released Visual Studio Team Server (VSTS), especially with its new source control solution. Lord have mercy on the soul of the librarian who ever attempted to manage source code for a large team using Visual SourceSafe! When I was Microsoft's manager of support for a large ISV, I routinely fielded complaints about VSS: corrupted source databases, weekend-long maintenance routines that would blow up at the end and leave a team stranded, etc. So even though it's a brand-new product, VSTS already exhibits the features that make it worth the migration effort.

As a brand-new product, though, VSTS is a gangly adolescent. And like the teenage version of Chris Falter, VSTS has some awkwardness and blemishes. I ran across one today. As I was adding a project to my solution from source control, I accidentally chose to place it in a folder that already had a project. As expected, VS displayed an error message:

The folder 'x' cannot be used for the solution or project you are trying to open because it is already in use to store part of another solution or project.

Okay, let's close the error dialog and try again. File menu, source control, add project from source control, choose the same project, and...oh, oh, a pimple. The “local path” text box is disabled. There is no apparent means of changing the path to a different folder. When I click OK, I get the same result, of course. Same folder, same error message. I'm stuck, stuck, stuck. If the interface to change the local path is disabled, how am I going to add the project?

After the usual googling, head-scratching, and oath-muttering, I discovered that the Team Server Source Control Explorer manages the mapping between projects and file paths. So:

1. Open Source Control Explore (View > Other Windows > Source Control Explorer).

2. Choose Workspaces... in the Workspace dropdown.

3. Select your workspace and click the Edit button.

4. Either remove the working folder for the project so that you can start over, or edit its “Local Folder” right there in the grid control. I chose to edit the Local Folder in the grid control.

5. Try again, and dance triumphantly, like John Travolta.

Hopefully the adult version of VSTS that eventually emerges will be smart enough not to create a mapping if the attempt to add a project fails. In the meanwhile, maybe this posting will help a few developers avoid some of the anguish of adolescence.

The Literary Ambitions of the ASP.NET 2.0 Site Compiler

Chris Falter — Sat, 29 Apr 2006 01:39:00 GMT

In previous versions, ASP.NET considered the web.config file to be untouchable. What you, the developer, wrote into the file may as well have been engraved like the Ten Commandments into stone tablets. But under the new compilation model, ASP.NET wants to collaborate with you in authoring the web.config file. Specifically, during site compilation, it will insert lines into the /configuration/system.web/compilation/assemblies element to make sure that the runtime JIT compiler knows how to link to the dependencies of project references. In other words, it will enumerate the entire dependency tree and write the necessary metadata to make sure that the JIT compiler knows what it needs, if you have not already provided the information via an explicit reference.

We stumbled onto this behavior quite by accident. For no obvious reason, when we ran our build script to compile/deploy a new website, the Visual Studio 2005 compiler decided to sneak these lines into the web.config:

<add assembly="stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="Office, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

And VS 2005 was quite insistent about adding these lines: it actually removed the read-only attribute from web.config, inserted the lines, and continued on its merry way. We, of course, knew nothing about the compiler's silent literary ambitions, so the site deployed as usual. But then it blew up; we did not have the stdole and Office assemblies version 7.0.3300.0 installed on the web farm, so things went south very quickly. The event log recorded something like this:

Configuration Error

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: Could not load file or assembly 'stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Googling turned up a thread where a developer declared that the problem could be solved by changing the default html editor on the build machine. This did not work for us. Then I noticed that one of my colleagues had recently added a new reference in one of the projects that was in the site project reference list. In other words, after my colleague's modification, we could now draw a line indirectly from the site to the stdole and Office assemblies: (1) site references a project, (2) the project references the Dart.PowerWEB.LiveControls component, and (3) Dart.PowerWEB.LiveControls references the stdole and Office assemblies.

We had not noticed this prior to deployment because the Dart development suite had installed the assemblies on the test sites' host server. Of course, the Dart run-time environment on the production server farm did NOT install the assemblies. Shame on you, Dart! After we removed the Dart.PowerWEB.LiveControls reference from the project, ASP.NET lost its literary ambitions. And not a moment too soon; next thing you know, the compiler will start a blog. And I don't want to have to compete with Microsoft technology!

So if you notice the new literary ambitions of the ASP.NET compiler, and they suddenly mess with your deployment, you know what to do: examine any references you recently added to the site's dependency tree, because one of them is the source of your problem. Keep removing references until ASP.NET ends its crazy literary ambitions. There are enough authors and bloggers in the world already; we don't need ASP.NET to join the crowd.

Exceeding the Wildest Dreams of the Microsoft Marketing Department

Chris Falter — Fri, 21 Apr 2006 19:07:00 GMT

The marketing gurus at Microsoft singlehandedly support a half dozen Starbucks franchises, no doubt, as they prime their adrenaline pumps to concoct Yet Another Plug (YAP) for the virtues of the .NET Framework. "Write more functionality with 80% less code!", they shout. As a heartfelt idealist, I take these claims seriously, so I have been looking for evidence to support the yapping. Recently, I achieved a wondrous breakthrough that will cheer the Redmond lads and lassies and leave the Java crowd groaning in dismay. Yes, folks, with exactly ZERO lines of code I have produced a programming construct that formerly required at least a few lines of procedural code. And I am proud to say that it is a record that will never be broken; no one will ever create the same programming construct with less than zero lines of code, right?

Sidestep coding a data tier by binding SQL statements directly to a DataGridView control: that's pretty swift. (Although for non-trivial applications I would not recommend it; I'll leave the details for another post.) Avoid writing a WSDL interface for a web service by decorating a plain old programming interface with attributes and running a WSDL generation tool: what a concept! But it takes genius, my friends-- yes, pure, unadulterated genius--to bequeath to the world a framework that allows the cunning programmer to create an infinite loop without any code whatsoever. An infinite loop, effortlessly created with no code: who knew?

In the days before the .NET Framework, the tool-deprived, hard-working programmer actually had to write code to create an infinite loop. Here's an interesting example from C++, which is of course the language in which all the Windows operating systems are written:

void RunLoop() {
int i;
i = 10;
while (i > 0) {
i = i--;
}
return;
}

So how is this an infinite loop? You just decrement i until it reaches 0, then you break out of the while loop, right? Ha! “i--” really means “i = i-1”, and it returns the pre-decrement value of i. So when you assign i-- to i the value of i never changes, and you just keep looping and looping and looping. Doesn't this make you long for the good old days of C++, when you could write obscure bugs like this, or do pointer math that would allow you to modify data who-knows-where in the heap? Of course, if you worked at Microsoft, you wouldn't have to long for the good old days, you could still be living them as you worked on Windows. And you wondered why they have all those security bugs.

Now, though, the .NET-equipped, lazy programmer can write an infinite loop with no code at all and head home early. Here's how:

1. Write an ASP.NET 2.0 application. Configure the customErrors node in your web.config to redirect to an error page.

<configuration>

  <system.web>

    <customErrors mode="On" defaultRedirect="Error.htm"/>

  </system.web>

</configuration>

2. Put frames in error.htm, and let each frame contain an aspx page.

3. Make a deployment error that causes all the aspx pages to break. You could forget, for example, to tell your admin that the site is configured to JIT-compile the DLLs dynamically, and let him xcopy code-behind DLLS to the production website.

4. Pop open a frosty beverage and watch the fun when ASP.NET doesn't know how to deal with the multiple copies of the same class in the AppDomain. It will detect an error on the home page, then redirect the browser to error.htm, just like the web.config tells it to. The browser will then try to load aspx pages, and then ASP.NET will detect more errors and redirect the browser to error.htm again, so the browser will request the framed aspx pages again, which will cause ASP.NET to detect more errors yet again and redirect the browser to error.htm yet again, and so forth. Just watch the status bar flash text like an old-timey stock ticker! You never had such fun in the Pleistocene pre-.NET days.

If you want to spoil the fun and make things actually work, I would recommend that your user-friendly error.htm page never contain any .NET dependencies. It should be pure browser-readable code; IIS should be able to pass it to the browser as is, without invoking anything related to the .NET Framework. Of course, you could always ignore this advice in an attempt to tie my record for fewest lines of code to create an infinite loop. But I'm not worried; I've created a record that can never be broken!

Here's hoping that the Microsoft marketing folks read this blog and get so excited that they storm the nearest Starbucks and run up a massive tab.

VS 2005 Gotcha: Project Loading When Opening Solution from Source Control

Chris Falter — Tue, 04 Apr 2006 00:36:00 GMT

We have invested a lot of effort into making the file paths for our projects mirror the SourceSafe project hierarchy, per the long-standing Microsoft “Team Development” whitepaper (especially chapter 3). The initial solution developer, typically the team lead, creates a blank Visual Studio solution, then adds the various projects at the solution root. To illustrate, here's the directory structure from a solution I created recently:

After the solution is checked in to source control, the project hierarchy in SourceSafe will mirror the file directory structure:

Any subsequent developer who opens the solution will find that its projects are all “auto-magically” loaded at the correct file path. Hence all developers who work on the solution will share the same file directory structure, and painless collaboration is assured. (Except for the weekly project management meetings...)Yes, you have entered programming heaven.

Unless St. Peter notices you're using Visual Studio 2005, in which case he bars you at the gate.

Try opening someone else's solution in VS 2005, and you'll find your projects being loaded in a location like C:\Documents and Settings\MyUserName\My Documents\Visual Studio 2005\Projects\Projects\Dev\Utils\etcetera. Argh! What happened?

After a bit of IDE spelunking, I opened this little dialog from the Tools => Options menu:

So you see, Visual Studio 2005 believes that you want to load all projects into the default VS projects location, regardless of what your source-controlled solution file might say to the contrary. And if you've redirected your “My Documents” folder to a network drive so your IT department will back it up daily, the way I have, VS 2005 will be polite enough to tell you that code access permissions will prevent you from running your code. Oh, how kind!

Fortunately, this problem is not too hard to fix. Just change the default location to a root directory...

...and St. Peter will let you pass through the pearly programming gates.