.NET Framework Administration Woes

By Michael K. Campbell

I love the .NET Framework. Along with SQL Server, it helps me pay my bills. It's also wicked-fun to use and develop with. But while there are some great new tools, technologies, and solutions looming on the horizon for .NET developers, Microsoft just keeps dropping the ball when it comes to administration of .NET Framework applications and solutions. I could cite a number of problems with ClickOnce, or the lack of any easy way to administrate spontaneous re-compiles by ASP.NET applications, or a couple of other problems to make my case. Instead, I'll focus on an example of something I recently bumped into as it highlights both how development and administration can sometimes be tightly intertwined, and showcases a big weakness in support for administering .NET solutions.

Recently I helped a client move an ASP.NET 1.1 application from IIS 6 up to IIS 7 and ASP.NET 3.5. I came in on the end of this transition and another developer spent a lot of time migrating code and testing it to make sure it would work with ASP.NET 3.5. Accordingly, I was left with the task of deploying this code out to IIS 7. Overall the transition went insanely well, but when the application was under load we kept getting page timeouts that were occurring at irregular locations within the request lifecycle.

To troubleshoot this problem, I decided to check into a couple of problems by making sure we weren't running into any collisions with assemblies in the Global Assembly Cache (GAC). Only, when I went to fire up gacutil.exe, I couldn't find. I hunted and pecked a bit, then determined that since I hadn't used gacutil.exe in a while on a Windows 2008 server that I would go check and see if it had been moved. Within just a few seconds of poking around on Google, I found a blog post by Brian Knight who explained that to get to Gacutil.exe, you need to download and install the .NET and Windows 2008 SDK.

Installing an SDK on a production sever seemed a bit crazy. I mean, the only difference between installing an SDK on a production server and installing Visual Studio (in my mind) is just a question of size, or bloat. But, I was in hurry, and decided to curse how difficult finding things on Microsoft's site are and went along my way to getting gacutil.exe installed. After a few more minutes, I had downloaded and installed what I THOUGHT was the right SDK. I also was able to verify that issues with collisions in the GAC weren't the culprit.

Life went on, a few days passed, and then I started getting really ugly application errors on what, up until then, had been a server with virtually no application errors. The application errors in question were sourced to SideBySide errors and were due to the fact that the activation context for C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\guidgen.exe apparently kept failing.

That's when I started getting cranky—because the path for this error was housed right in the SDK I had recently downloaded and installed.

For kicks and giggles I decided to try using sxstrace.exe to shed some light on the system—since that's what the event log entry suggested. However, two aspects of using sxstrace.exe got me thinking about how crappy Microsoft's admin tools and support for .NET applications are. The first was that while sxstrace.exe is actually a GREAT tool; its usability stinks. It takes an approach where you enable it for tracing, kick off your problematic code to let it watch what's going on, and then turn off your trace. That part of the user experience is great. But what's dumb is that the diagnostic log file that you generate as part of troubleshooting then needs to be parsed by sxstrace.exe before it can be read. So, you fire it up and tell it to log to a file, do your testing, and then you have to run it again against your log file so that you're able to read it. Not sure why it can't just give you the option to log plain text in the first place.

But what really caught my attention with this tool is that it is installed on all Windows Vista and Windows Server 2008 deployments –whether the .NET Framework is installed or not. Ostensibly, that makes sense - since this tool is designed to troubleshoot problems between different versions of the framework, so you'd want it on there in CASE you had different versions of the Framework.

But if Microsoft can make a smart decision like that, why can't they offer some sort of option for making it easier to install .NET Framework tools when you install the .NET Framework? Sadly, it looks like there's some sort of internal issue with distributing admin tools, either in the sense that Microsoft has licensed some of the tools for easy redistribution while others are not, or due to the fact that, apparently different teams are assigned to manage different groups of these tools.

In my mind the problem I bumped into is two-fold. First, from a business standpoint, I don't really care which teams at Microsoft own which parts of the .NET Framework. Nor do I care if Microsoft has some parts of the .NET Framework that their lawyers want distributable or not. Because if I'm administering .NET applications on a Windows Server 2008 instance with the Applications Services role (i.e., the .NET Framework) installed, then issues about who owns what piece of code or whether or not a developer should be able to distribute intellectual property or not should be moot. If I'm using the .NET Framework, then I should be able to use the administrative tools designed for it. Ultimately, Microsoft will let you download the tools you need, but you have to hunt and peck for them and jump through additional hoops. Obviously, this doesn't signal the end of the world, but it's also not what I'd call creating a great experience for licensed Windows Server 2008 users or admins.

Second, on a more practical or functional level, if I can manage roles and role services components on a Windows Server 2008 server, why ISN'T the option to install CLR/NetFX admin tools an option? It seems like that would be a really great way for Microsoft to make sure people can OPTIONALLY get the binaries and tools they need. Instead, I was left to hunt and peck around on their site, had to wait for an additional download, and ultimately ended up what (I think) was the wrong SDK. Ironically, the SDK I installed was for .NET 3.5. Maybe I should have downloaded this one instead? Probably not. But then again, why would the .NET 3.5 SDK start throwing SideBySide activation errors for GuidGen.exe once it was installed on a server with version 3.5 of the .NET Framework installed? And wouldn't it have just been easier for me to click another check box when selecting the Role Services to install for the Application Server Role? Seems to me like this is one area where Microsoft could make administrative tasks much easier.