While working on a WCF REST service this week I started seeing assembly load errors when IIS was attempting to initialize my service code. The errors in the Event Log looked something like this: “The worker process failed to pre-load .Net Runtime version v4.0.20521.” That seemed a little odd since I’m running version 4.0.21006. 

I double checked that IIS was configured to use v.0.21006 for the Application Pool I was using. It was. Binging around didn’t lead to any quick answers so I’m posting this in hopes that it will now.

Turns out that when you uninstall previous beta versions of VS or the .Net runtime some vestiges remain on your system. In my case %SystemRoot%\Microsoft.Net\Framework and %SystemRoot%\Microsoft.Net\Framework64 contained several v4.0.* subdirectories. IIS appears to have been picking the first subdirectory that matches the major.minor version and attempting to load the runtime from that location. 

Removing the older v4.0 subdirectories (NOT v4.0.21006) cleared up the problem.

Hope that helps someone else.

One thing that’s somewhat painful about testing/debugging SqlClr application code is managing the connection strings used for internal DB calls inside the system. SqlClr has the notion of a “context connection” connection string which uses the same connection and execution context as that under which the SqlClr code is executing. We use this a lot inside the Aggregation system my team developed.

It can make testing difficult, as when you’re unit testing functionality that uses the context connection and you’re hosted not within SqlServer but within a testing framework these internal calls fail with a “context connection is only available when hosted by SqlServer” error.

I’ve come up with an idiom for managing this in my unit tests. Maybe useful to others as well, so here it is.

I have a utility class with a static constructor which figures out if we’re hosted by SqlServer by inspecting the SqlContext.IsAvailable property and sets a connection string property appropriately. If we’re not hosted by SqlServer the utility class checks the ConfigurationManager for settings stored in AppSettings in our app.config file and uses those.

Here’s the relevant code:

#region Constructors
/// <summary>
/// Sets up the internal connection string used by the system.
/// </summary>
static Utility()
{
  if (SqlContext.IsAvailable)
  {
    internalConnectionString = "context connection=true";
  }
  else
  {
    try
    {
      SqlConnectionStringBuilder sqlSb = new SqlConnectionStringBuilder();

      #if DEBUG
      sqlSb.Pooling = false;
      #endif
      sqlSb.DataSource = ConfigurationManager.AppSettings["DBServer"];
      sqlSb.InitialCatalog = ConfigurationManager.AppSettings["Database"];
      sqlSb.IntegratedSecurity = true;
      internalConnectionString = sqlSb.ToString();
    }
    catch (Exception e)
    {
      // log 
      internalConnectionString = "context connection=true";
    }
  }
}

#endregion

#region Properties

/// <summary>
/// Connection String used for DB calls within the system.
/// If hosted by SqlServer this will be a context connection,
/// otherwise we assume this is a test run and use a trusted connection
/// string with database and server as configured in app.config.
/// </summary>

public static string InternalConnectionString
{
  get { return internalConnectionString; }
}

#endregion

Then in the SqlClr code we get the connection string like so:

using (SqlConnection conn = new SqlConnection(Utility.InternalConnectionString));

Now our unit tests can operate outside of the SqlServer context. This isn't always appropriate or neccessary, but for our project it's both.

Some caveats/weirdness:

1. When hosted in SqlServer you don’t usually have access to config files (or the file system as we know it) so I rename and copy the app.config for my unit test assembly to the output directory and rename it so it looks like the config file for the SqlClr assembly. This is only useful for testing, and the config file that appears to be for the SqlClr code isn’t actually deployed to SqlServer. 
   
2. I wouldn’t ordinarily read config settings in a static .cctor, but in SqlClr you can’t write to static members unless they’re readonly which complicates things somewhat. 
   
3. When debugging SqlClr you want to use a trusted connection when possible, so that’s what we do for test scenario here. This assumes whatever security context the tests are using has necessary permissions on the database. 
   
4. SqlContext.IsAvailable can return false for reasons other than that your code isn't hosted in SqlServer. I haven’t fully explored all the potential failure cases here yet. We protect our system against this in the SqlServer hosted case by defaulting to a context connection if any exception is caught when attempting to initialize the test connection string.
5. VS won't let you add a reference to the System.Configuration.dll assembly using the normal Add Reference context menu for SqlClr projects. Apparently this assembly was added to the "blessed assemblies" list for SqlServer hosted code late in the game and VS hasn't yet caught up. You'll need to manually edit your .csproj file and add  the reference manually like so:

     <ItemGroup>
       . . .
       <Reference Include="System.Configuration" />
     </ItemGroup>

We're working on tightening up the Publishing API for the MTPS system (the publishing system behind msdn2.microsoft.com) and wanted to be able to restrict access to some utility library methods so that only the core of the system could use them but not external clients. "What we need," I said "is C++'s 'friend' declaration. Too bad we don't have that for managed code."

Turns out we do have such functionality. Even better, maybe.

Using the [assembly:InternalsVisibleTo] attribute introduced in .NET 2.0 allows to to declare another assembly a "friend," meaning that all members declared with internal visibility can be accessed from the friend assembly. Pretty neat. It solved our problem quite well. I'm not sure how I missed this when .NET  2.0 came out, but I did.

Note that there are some important security caveats to keep in mind when using this attribute.

At one point Watson fielded a request from the audience with what must be the most polite refusal since Bartleby worked as a scrivener. I'm paraphrasing:

"Well ma'am, thank you for making a request, but I've played that song about 3500 times with Merle, and probably 4000 times since. If it's alright with you I'd prefer not to play it tonight." Jeff Tweedy he ain't.

Saturday's Wall Street Journal has an interview with Craigslist CEO Jim Buckmaster. Brian Carney, the interviewer, seems distinctly ill-at-ease with the notion that Craigslist isn't terribly interested in maximizing revenue.

From the interview: "If Craigslist does what its users ask of it, and Craigslist doesn't need or seem to want all the ad revenue it declines to collect, maybe we, as end-users, should ask them to post some banner ads and give us the money instead."

Is leaving money on the table really such an affront?

Yesterday at TechNet they pulled the wraps off and announced the public availability of these services. I think this is a pretty big deal; we're opening up the corpus of MSDN's developer documentation to clients outside of our control and I'm confident that usage scenarios we've never imagined will emerge as folks play around with these services.

Craig developed a reference implemenation of a client for these services of particular (peculiar?) interest to those of us who've dwelt in the *NIX world and still cling to the command line: msdnman. No, it's not a superhero -- it's a command line documentation engine that displays MSDN docs fetched from the Content Services. Craig has made the source code available and it provides an excellent example for those interested in writing clients which consume these services.

I've been helping out a little around the periphery of this project and have learned more about  XML esoterica than I ever thought possible. Now when I'm asked about REST I'll have a more reasonable answer than "no thanks, I gave it up when my second child was born."

This article builds on the talk I gave at VSLive in Febrary.

Release of upgraded Related Articles functionality based on this system on MSDN2  is planned for later this month.

Followed up Monday's Nels Cline show with a Jeff  Tweedy solo show last night. As an added bonus Wilco's drummer Glenn Kotche opened and sat in for a few songs with Tweedy.

Now you might be thinking A drummer opened? By himself? What was it, a 45 minute drum solo? Well, sort of. It was drums and temple bells and hoses rubbed on snares and hubcaps being whacked with egg beaters and all manner of wierdness and it was amazingly melodic.

Tweedy was great and played both acoustic-friendly fare like Acuff Rose and some usually heavily electrified stuff like Shot in the Arm and I'm the Man Who Loves You that were amazingly good in their solo acoustic arrangements.

One thing Larry and I both lamented a bit was that Tweedy's renown for "baiting" his audiences seems to bring out the people interested in participating by trying to be obnoxious enough for Tweedy to notice them and tell them to shut up. It's a strange notariety, but maybe there are people bragging to their friends that "Jeff Tweedy called me the snaggle toothed voice of the abyss last night"! Tweedy was good natured about it, and used it as therapy I guess, but it must get pretty old.

Oh, and Tweedy's growin' a beard (Bob Dylan's 50th?)

Here's the setlist.

• Presentation deck (.ppt)
• Presentation deck (.htm)
• Chris Brumme's blog post on SQL Server's hosting of the CLR
• MSDN2 docs on SQL CLR debugging
• Service Broker Dev Center on MSDN2

I'm awaiting legal clearance to post the code I used in the demo, and will post as soon as it's granted.

If you attended my talk and have questions or feedback, feel free to get in touch via the email link above.