CLR Integration into SQL Server 2005 - A 'good thing' for .NET developers, even if you never use SQL Server 2005? Or 'they're stealing engineering effort that could be going to us'.

SQL Server 2000 is one of my favourite Microsoft products - reiable, performs well. A solid bedrock that many other Microsoft server products rely on. Recently I’ve been thinking about the pros and cons of SQL Server hosting the CLR for the general .NET developer. On one hand I think its great for .NET developers that CLR 2.0 is now hosted inside SQL Server 2005. The reliability requiremed for the CLR to run inside the SQL Server process (SQL Server doesn’t have the luxury that IIS does of running .NET in a seperate process) are high, and its doubtful that the SQL Server team would accept something sub-standard on such an important product. On the other hand though I’m unsure as to how my ASP.NET or Windows Forms app is going to benefit from features like the fiber-mode threading/scheduling or how many constrained execution regions I am going to write. Will more “dogfooding” of .NET by Microsoft product teams lead to a better CLR for every .NET developer, or a CLR that is highly optimized to run SQL Server and Office? I believe (and certainly hope) it is the former. I wonder if the day will ever come where an important application like SQL Server will just ship with its own “special” CLR.