As much as I love writing code, I realized long ago that it’s really the act of bending my computer to my will that I really love. Programming’s just the only way to really do that. After a few decades, you’d have thought we’d have come up with something better. Our industry’s pioneers agree that programming is holding us back, but don’t really know what we’ll use to replace it. Ideas?

NetFlix brought “Hell House” to my house the other day and I just finished watching it (in fact, the credits are still rolling).

Hell House is the name of a specific kind of “haunted house” exhibit that some churches run every year at Halloween. This movie is a documentary of the church that originated the practice and is in it’s 10th year, having had 75,000 guests over that period. The hook is that the church puts on little mini-plays showing real-life horrors, e.g. domestic abuse, rape, murder, drunk driving, abortion and, sin-of-sins, homosexuality (which doesn’t hurt anyone, of course, but gets them on the news every year).

At the end of each tour through the Hell House scenes is a room with a member of the church applying age old used car salesman techniques to pressure people into converting or recommitting to the church. There success rate is 20%, which is why hundreds of churches around the country have adopted this practice.

It amazes me that such a thing actually happens. The techniques they use reminds me of a cross between the horror movies we was made to watch in driver’s ed and the pressure our society puts on our children to believe in Santa. Don’t cults get into trouble for this kind of thing? Truth is truly stranger than fiction.

I have absolutely fallen in love with X1. I don't search my email, attachments or file system anymore; I just type a few character into filter fields until the results have narrowed enough to show me what I was looking for. This is but a small part of what WinFS is going to enabled and it already saves me hours/month. Highly recommended.

Just flew in from California… and boy are my arms tired! <shot area=“rim” />

We did 4 California theme parks in 4 days and here’s what I thought:

1. Magic Mountain: great rides, but even before spring break, the best rides had waits of 2-3 hours, so we didn’t get to go on them (although Scream rocked). Also, the price gouging was gratuitous, including $3 for a soda, $.87 for a packet of ranch dressing and extra money for a bunch of the activities after paying to get into the park, e.g. virtual reality ride and rock climbing. Over all, thumbs down.
2. Disney’s California Adventure: Surprisingly good. The production values are high, even making the waiting as fun as possible, just like in every Disney park. The Bugs Life “it’s hard to be a bug” show was hilarious and the Soarin’ Over California ride took my breath away. Plus, all of the rides that had analogs in Magic Mountain were better at California Adventure. This was the winner of the trip. Thumbs up.
3. San Diego Sea World: The day was a little overcast and their major ride wasn’t running, but the shows were fun and it was a nice, mellow experience after two intense days. Also, the food was noticeably better than the other parks (although $50 on lunch for 4 was a bit much). More on the meal front: I called Don on the road between Sea World and the hotel in LA and he recommended In-n-Out Burger, which none of us had ever had before. My oldest son mentioned that meal more than Sea World, so both get a thumbs up.
4. Disneyland: This park needs an overhaul. Their one really good ride, Indiana Jones, was closed and all of the rest of the rides were only interesting for the nostalgia factor (plus they broke down a lot). When I brought my 4-5 year olds here 4 years ago, it was really great to see the place again through their eyes. Now that they’re older, the place holds no attraction for me. Thumbs down.

Over all the trip was a thumbs up if for no other reason than I was without my laptop for 4 days and didn’t really miss it. Then I come home to find that you dang kids have TP’d my blog! : )

Thursday, March 11th, 2004

The .NET Global Assembly Cache (GAC) is a misunderstood and misused beast. For all intents and purposes, it provides what COM and windows\system32 do, i.e. a machine-wide place to drop shared DLLs. Of course, the problems with sharing DLLs in a machine-wide spot is that it leads to a set of well-known problems collectively called “DLL Hell.” There are many problems, but the biggest is that when a shared DLL is updated, you’re really updating an unknown set of applications. If the set of applications is unknown, how can you possible test them before making this change? And if you can’t test them, you’re likely to break them. What this boils down to is that any of the shared spots for updates, whether it’s a COM CLSID, windows\system32 or the GAC, are dangerous and should be avoided. And this is why the preferred .NET deployment scenario is “xcopy deployment,” i.e. having your own private copy of each DLL that you test and deploy with the rest of your application.

“Aha!” you say. “The GAC supports multiple version of an assembly! When a foo.dll is updated to v1.1, v1.0 sits right along side of it so that your app *doesn’t* break!” Of course, that’s absolutely true. But if that’s the case, why do you care? I mean, if there’s a new assembly available but your app isn’t picking it up, what difference does it make?

“Aha again!, you say. “I can put a publisher policy into the GAC along with my assembly so that apps *are* updated automatically!” That’s true, too, but now, like any of the machine-wide code replacement strategies of old, you’re on the hook for an awesome responsibility: making sure that as close to 0% of apps, known to you or not, don’t break. This is an awesome responsibility and one that takes MS hundreds of man-years at each new release of the .NET Framework. And even with those hundreds of man-years of testing, we still don’t always get it right. If this is a testing responsibility that you’re willing to live with, I admire you. Personally, I don’t have the moral fortitude to shoulder this burden. For example, we do sign genghis.dll when we ship it so that folks can put it into the GAC if they want, but we make no promise of backwards compatibility between versions and therefore we do not ship publisher policy DLLs. Instead, we expect folks to use xcopy deployment and catch the problems at compile-time and test-time.

So, if the GAC represents such a massive burden, why do we even have it? It’s for two things that I’ve been able to identify:

1. Fixing critical bugs without touching the affected apps (and without breaking anything!)

2. Sharing types at run-time between assemblies deployed separately

#1 is what you get when you install Windows hot fixes and service packs via Windows Update. A ton of design, implementation and testing time is spent to make sure that existing code won’t break before shipping these fixes.

#2 is needed if you’re going to be sharing types between assemblies that you can’t deploy as a group but absolutely must keep to the same version of things. .NET Remoting peers are in this category, but only if they’re deployed in separate directories so that they won’t share the same set of types available via xcopy deployment. However, if .NET Remoting peers are deployed on difference machines, the GAC won’t help you anyway as you’ll be manually insuring the types are the same across machines. BTW, the responsibility of keeping multiple machines to the same set of types (and the same framework for hosting those types) spawned an entirely new way to talk between machines, i.e. web services, so .NET Remoting itself is something to avoid unless you can administer both ends of the pipe for simultaneous updates.

Another scenario that fits into #2 is the Primary Interop Assembly (PIA). A PIA is a COM interop assembly that’s been pre-generated and dropped into the GAC so that everyone that adds a reference in VS.NET to mso.dll (the COM library for Office) gets office.dll instead (the .NET Office PIA). That way, everyone can talk to the same set of types instead of everyone getting their own incompatible interop types generated on the fly. However, PIAs are primarily a way to make sure that VS.NET has a central place to pick up the shared types without regenerating new incompatible types.

Notice that “Saving hard drive space” wasn’t on my list of reasons to use the GAC. I just purchased a 60GB, 7200RPM hard drive for my laptop for a measly coupla hundred bucks. I don’t want to hear about you jeopardizing the reliability of the applications on my machine to save a tiny percentage of that space. Hell, when I buy a HD, I give 50% of it over to apps anyway, so help yourself and keep my apps running by avoiding any machine-wide space for updating shared DLLs, including the GAC! Thanks.

Discuss (did I miss any reasons to use the GAC?)

Here.

I find it unbelievable that after umpteen books, I finally seem to have blended quality with quantity as the C# version of my WinForms book enters it’s 3rd printing after only 8 months in publication. Wahoo!

Here. Ouch. I resemble that remark...

I know that I'm no longer untainted because I work in the big house, but I just don’t get this. Do developers really want to build the same thing over and over, project to project, app to app or do they want to spend their time building cool, new stuff? Is .NET or Whidbey or Longhorn any different from continuing the foundation that we've built before? Does anyone really miss building their own file system or declarative content flow or toolbar? Will anyone miss building their own animation, object serialization or secure communications framework? I mean, building these infrastructure pieces is fun, but even more fun is pulling these pieces together to build something that’s never been built before.