Speakers are Speaking in Code . . .

cleaning up older .net beta framework installations

mollman — Tue, 03 Nov 2009 15:54:35 GMT

I’ve been working with Visual Studio 2010 betas for a while now (it’s really great) and have gone through multiple upgrades of VS and the .Net runtime over the past few months.

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.

Managing Internal Connection Strings in SQL CLR code during testing

mollman — Fri, 23 Mar 2007 22:05:01 GMT

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:

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.
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.
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.
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.
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>

Making Friends in the CLR

mollman — Fri, 13 Oct 2006 20:57:00 GMT

My boss and I were lamenting the lack of the "friend" declaration in the CLR languages like C# this week.

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.

Doc Watson: Nicest Man in Show Business?

mollman — Thu, 20 Jul 2006 20:32:00 GMT

Went with the family to see Doc Watson play at the Woodland Park Zoo last night. The zoo hosts concerts featuring some pretty great mid-level touring bands every summer on the North Meadow, and, since we live a block away, we go to most every show. It's a really kid-friendly scene; I think my son Søren was 4 days old when he saw his first show there (Suzanne Vega). Watson was great, as always, and the kids loved dancing to the familiar music.

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.

Microsoft to Supply ECUs for Formula One (Sort Of)

mollman — Thu, 06 Jul 2006 20:54:00 GMT

I'm on my annual F1-oriented vacation and travelled to Indianapolis for the USGP again. I'm a big fan of Kimi Raikkonen, so the USGP was a real dissapointment. We have great seats at turn one, which is where Juan Pablo Montoya took out Raikkonen (his McLaren teammate) on the first lap.

Interesting to see that Autosport is reporting that the FIA has chosen "Microsoft MES" as the official supplier of ECUs for Formula One starting in 2008. Exactly what/who is MES is subject to debate in the F1 press at this point, but Autosport sources report that it's McLaren Electronic Systems; a subsidiary of McLaren International reportedly unrelated to the McLaren Mercedes F1 team.

Where and how Microsoft fits into this I have no idea, but if anyone involved is reading this: can I come work for you? I'll move to Woking, no worries!

WSJ on Craigslist

mollman — Mon, 19 Jun 2006 23:27:00 GMT

File under "Goliath interviews David, Remains Incredulous."

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?

MTPS ContentServices and MSDNMan

mollman — Tue, 13 Jun 2006 23:00:00 GMT

Craig Andera has been working with my team on a set of web services exposing MSDN2 content hosted by MTPS (our content publishing and rendering system) to SOAP clients.

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."

MSDN Aggregation System Article

mollman — Mon, 12 Jun 2006 17:43:00 GMT

An article I wrote for MSDN Magazine covering the metadata aggregation system my team developed has been published. Online version at http://msdn.microsoft.com/msdnmag/issues/06/07/InsideMSDN/default.aspx.

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.

Jeff Tweedy at the Moore

mollman — Sat, 04 Feb 2006 02:00:00 GMT

It's been a Wilco-oriented week.

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.

VSLive Talk Resources

mollman — Thu, 02 Feb 2006 21:58:00 GMT

I promised to post links to some of the resources I mentioned in my talk at VSLive this week. Here they are:

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.

Back from VSLive

mollman — Thu, 02 Feb 2006 20:22:00 GMT

I've been pretty lax about posting of late (new baby, you see), but I just returned from giving a talk at VSLive in San Francisco and have several posts in the pipeline. Après ceci, le déluge.

I gave a talk on my team's use of SQL CLR integration and Service Broker in a system we built. For those of you who attended; thanks, and I'll post my deck as promised and try to get the demo code people requested up as well. It was a bit of a challenge distilling our fairly large and complex system into concepts I could demo in an hour, but I think I managed to pare it down reasonably well.

Mark gave a great (and very well attended) talk on his rendering framework, and Larry and Andy gave a terrific keynote address covering some of the new stuff our group is doing for MSDN and TechNet.

I had a lot of work to do on my presentation while we were down there (it was still pretty lame when we stepped off the plane), but managed to get out and have some fun too. We caught Nels Cline at Yoshi's in Oakland on Monday where he was doing Andrew Hill compositions with a very eclectic band (coronet, accordion, baritone sax/clarinet, standup bass, trap drums). It was fascinating the way the various instruments picked up parts of the melody and watching Cline leading the band. Cline is Wilco's guitar player these days, which is how I know of him. Larry scooped me with this review.

We also drove up to Muir Woods and had a nice dinner in Sausalito at a waterfront place with an incredible view from Muir Headlands to the city to Berkeley.

Much fun.

Honeynet Project Paper on Phishing Techniques

mollman — Tue, 24 May 2005 21:07:00 GMT

Another interesting paper from the Honeynet Project. This one relates their discoveries about the tools and techniques Phishers use to turn compromised servers into phishing support sites. Pretty scary how well organized these people are.

http://www.honeynet.org/papers/phishing/

Via /.

Gridswarms

mollman — Tue, 17 May 2005 19:13:00 GMT

"Imagine a large group of small unmanned autonomous aerial vehicles that can fly with the agility of a flock of starlings in a city square at dusk. Imagine linking their onboard computers together across a short-range, high-bandwidth wireless network and configuring them to form an enormous distributed parallel computer."

http://gridswarms.essex.ac.uk/index.html

via /.

One step closer to Stephenson's Diamond Age, I guess. Watch for them hovering over a burbclave in your franchulate soon . . .

vier vrijheid

mollman — Wed, 04 May 2005 23:28:00 GMT

5 May is the 60th anniversary of the liberation of the Netherlands from German occupation. The Dutch hold a Liberation Festival every May 4th & 5th to celebrate Freedom and to "reflect on the current meaning of freedom, democracy and justice."

These are three terms which are so blunted by jingoistic overuse that I find the idea of spending time in contemplation of their meanings, especially in the historical context of the horrors of the Second World War, terrifically laudable.

If you happen to be in Holland, there's a whole passel of great music to see as part of the Liberation Festival. Bettie Serveert plays 3 shows (in one day!) (14.20 - 15.10 Leeuwarden, 18.30 - 19.30 Groningen, 23.00 - 24.00 Zwolle) on the 5th, and the Drive By Truckers are in Haarlem.

Changes to VS Mapping of CLR Objects to Yukon Data Types under Whidbey Beta2

mollman — Tue, 19 Apr 2005 18:56:00 GMT

I'm working on a project that makes extensive use of Yukon's CLR integration. This makes things that have traditionally been difficult to do in T-SQL (like string manipulation) a whole lot easier. If you aren't familiar with the basics of SQLCLR integration, MSDN has several good overviews. Pablo Castro's new article is a great place to start and covers some of the changes in Beta 2.

Visual Studio does a great job of hiding the gory details of deploying .Net assemblies and mapping CLR data types to SQL data types behind a simple "deploy" button. Sometimes it does such a great job that you take what it's doing for granted and get bit.

I got so bit yesterday while working on migrating a prototype from Whidbey PD7 to Beta 2. I have a simple SqlFunction that takes a string (containing XML data), does a Regex.Replace, and returns the modifies string. Worked fine under PD7, but under Beta 2 I started seeing unexpected end of input Exceptions from the downstream XML parser. Stepping through the SqlFunction in the debugger I found that the input param string was being truncated to 4000 characters. Hmm.

Turns out that under Beta 2 Visual Studio's "auto-registration" of CLR objects (the mapping of CLR data types to SQL data types when you deploy a SQLCLR assembly) has changed. Under previous builds any string or char[] params were mapped to nvarchar(max) in the Yukon world. Under Beta 2 the mappings have changed, presumably for efficiency reasons.

The new mappings are as follows:

String           NVarchar(4000)
SQLString        NVarchar(4000)              
Char[]           NVarchar(4000)
SQLChars         NVarchar(MAX)

Byte[]           Varbinary(8000)
SQLBinary        Varbinary(8000)             
SQLBytes         Varbinary(MAX)

What this means is that when you want to pass string data that may be > 4000 characters long into (or out of) a SQLCLR function or SPROC you need to specify the params as SQLChars rather than string. Similar changes have been made for varbinary data.

As an aside: it's pretty amazing to be able to step pretty much effortlessly from CLR code into a T-SQL SPROC and then into SQLCLR code and out again from within the Visual Studio debugger.