Tim Sneath posted a great piece of information today.  I ran into this issue exactly:

I installed Whidbey and then Yukon.  Yukon setup kept complaining that there was already a conflicting version of Yukon on the box (I had MSDE Express), but that wasn’t it.  Tim points out that Yukon has a slightly new version of the .Net framework, so what I need to do is uninstall v2.0 (not VS), and then Yukon will install fine.  Great job Tim.  I was stumped.

By the way, I saw a demo of stored procedures in .Net languages, and I’d like to clear up something:

In Yukon, there is no way to get or modify data without using TSQL.  Yes, stored procedures can be written in any .Net language, but stored procedures are just executable bits of logic.  Manipulating rowsets in the database still requires TSQL calls, but any calculations, validation, etc can be coded in the .Net language.  That being said, is there a reason to code stored procedures in .Net?  Not for me (yet).  I make it a habit NOT to write logic in my Sprocs.  I manipulate data rowsets, and that’s it, so if I have to use TSQL to manipulate rowsets, then I’m right where I am now.

Also, what about the issue of database migration, or switching databases.  If you write database sprocs in .Net, you can never switch databases.  What if you develop a product with Yukon.  You’ll never be able to implement it with SQL Server 2000, and 2000 will be around for a long, long time because it suits the needs of so many businesses.

I’m probably coming across as a pessimist, but that’s not my intent.  I just know it’s inevitable that somebody will devleop an entire application on Yukon’s CLR and then wonder why their database box is so damn slow.  At least, it’ll be good material for The Daily WTF.