Archived Posts from this Category
Archived Posts from this Category
Comments Off on The Morning Brew #1176
Update: Fixed a typo suggesting that Scott Hanselman’s Videos were for .NET 3.5 – Thanks to Graham for letting me know via the comments
Unless you’ve been living under a rock for the past 24 hours you will already be aware of some of what follows….
It’s been quite a while since the last ‘Afternoon Tea’ post, and there have been quite a lot of significant announcements in the past few weeks, coupled with my being busy at work which has resulted in me building up quite a backlog of links which I really wanted to include in a Morning Brew. This post is my attempt to ‘clear the decks’ and get caught up again, and also provides the perfect excuse to do a link roundup of DDD South West which I had the pleasure of presenting at at the end of last month.
Comments Off on Afternoon Tea – Sunday 10th June 2012
Disaster struck this morning – I pressed post, waited until the page reloaded and shut my laptop as usual, but for reasons unexplained the post never made it onto the site – So here is today’s edition, a little later than planned – at least its still morning *somewhere* in the world!
Thanks to Libor or letting me know something was wrong
Update: In my haste to resurect today’s post a ‘smart quote’ snook into some HTML merging Sankarsan & Jon Skeets links together – fixed now – thanks to EF for letting me know
In the presentation about Good API Design I talked about in yesterdays post one of the key points made was that once an API is defined you should never make changes to it that will break your client’s code. An example cited throwing exceptions based on values previously considered fine.
As luck would have it I encountered an actual example of precisely this problem today while installing the .NET 2.0 Runtime on a development server. This server runs a number of .NET 1.1 applications and a number of classic ASP applications consuming COM components written in .NET 1.1.
Things didn’t start well, with the framework installer stopping the IIS instance for the better part of 10 minutes while installing, however it did restart it again once it was done (unlike MSDTC and SQL Server when installing anything from the Windows Components section of Add Remove Programs on Windows 2003).
Matters got worse when someone mentioned that one of the components on the server was now misbehaving – specifically one that uses the ASP.NET Cache to provide caching capabilities.
Whenever a web application tried to create this object (via Server.CreateObject) it was getting an invalid pointer error. Other COM components developed in a similar way were working fine, so I assumed there was something wrong with the registration of the component. Un-registering and re-registering the component gave no joy – neither did calling it from a simple VBScript file.
To make matters worse, a simple .NET test application was working just fine using the exact same library.
After a bit of head scratching and pondering the SysInternals (Now a part of Microsoft) Process Explorer revealed that instead of using the .NET 1.1 version of System.Web both CScript and the IIS DLLHost were loading the .NET 2.0 version. The code for the component hadn’t changed, so maybe the .NET framework had.
Loading the source code for the component into Visual Studio 2005 and attempting to compile and run a the simple test application revealed the problem, a Null Reference Exception from within the framework.
As the COM Component was using the ASP.NET System.Web.Cache it was creating a HTTP Context instance internally. This code looked like this:
private System.Web.HttpContext context = new System.Web.HttpContext(null);
Poking round the disassembled code of System.Web in Reflector didn’t reveal what it was that was causing the exceptions, although I did only go a few functions deep, however it did reveal an alternative way of getting to the cache.
Changing our code to use a call to
System.Web.HttpRuntime.Cache to obtain the cache instance fixed our problem, and a quick rebuild of the component against .NET 2 and redeploy to the server and we were back up and running.
Lessons learned from all this: