Ever since the SQLCLR talk at TechEd San Diego, I've been trying to find out some more information on the monitoring options available in SQL Server 2005 for managed assemblies catalogued in the database. Balaji Rathakrishnan (one of the Group Program Managers on the SQL engine team) kindly granted me permission to reproduce some information he posted to one of the internal mailing lists on the subject:

We have a whole new set of new dynamic management views some of which can be used for monitoring CLR, notably:

• sys.dm_os_loaded_modules shows whether CLR is currently loaded
  (e.g.)

   select name, description, * 
   from sys.dm_os_loaded_modules 
   where description like 
   '%Common Language Runtime%'

• sys.dm_os_memory_clerks shows amount of memory being used by each component in SQL Server including SQLCLR; for example, how much memory is currently committed to the sqlclr gc heap?

   select virtual_memory_committed_kb, * 
   from sys.dm_os_memory_clerks 
   where type like '%SQLCLR%' 
   go

• sys.dm_exec_query_stats shows execution statistics on the set of queries/batches that are currently in the plan cache. This will include queries/batches that invoke CLR code as well.

Thanks, Balaji!

For various reasons, I've been spending a fair bit of time over the last week or two ramping up my Longhorn development skills; expect to see a few blog entries over the next fortnight or two on the subject as I write up some of my experiences.

Some of my early experimentation has been with the Longhorn sidebar. It's not a bad place to start in some ways: it's a new Longhorn feature, it exercises Avalon as well as optionally Indigo and/or WinFS, it has a built-in template as part of the Longhorn SDK, you can build it in manageable lumps and iteratively improve it.

The first tile I've created has been a quick note-taking component that allows you to enter an item into OneNote. I've become a big fan of OneNote over the last few months: it works well as a general dumping ground for all kinds of things I want to capture. There are a few idiosyncracies (for instance, navigation is hard with 200+ note pages), but for a V1 product it's got plenty to keep me hooked. Anyway, the itch I was scratching with this OneNote tile was the ability to quickly jot down a phone number or some other tiny snippet of information and log it without having to even change window.

I'll write more about the tile itself in a future article, but for now I just wanted to share a few tips about developing sidebar tiles in general.

To start with, you should know that (in the PDC and WinHEC builds, at least) the sidebar is part of the main explorer.exe process. As you are undoubtedly well aware, Longhorn is very actively under development still and is at best alpha-quality software at this stage. (In practice, it's fine even now as a secondary machine - I run Outlook, VS and IE quite happily on it when I'm developing.) However, I had to rebuild my Longhorn partition early on this week when I built a buggy tile that caused the process to die with an unhandled exception. Since Explorer (and my tile) are loaded when the machine starts, I was caught in a nightmare scenario. I'd put good money on the sidebar being entirely robust against this kind of problem in later builds: it's just one of the many things you have to put up with when you ride the bleeding edge.

If you get into this situation, you might be able to recover by deleting the registry keys that register your tile with Explorer: they're found in a GUID-named subfolder of:

 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\SideBar\Modules

The problem is that creating the XAML user interface for a tile by hand is (for me at least) a laborious and error-prone process. So the other piece of advice that was very helpful to me was something buried deep in the excellent Longhorn Development FAQ, under the topic "How do I debug a Sidebar Tile?" Here Rob Relyea provides an alternative project file for loading a sidebar tile as a separate NavigationApplication window, which means that I can happily write buggy crash-prone code all day long without ever worrying about it affecting the integrity of my platform. This is a good starting point, but it doesn't fully model a hosting contanier for a sidebar tile: for example, there's no support for tile backgrounds. I found myself using this separate project file to model the UI with trial and error; when the UI was complete and exception-free, I moved across to the real sidebar for ongoing development.

A couple of the most useful resources I found in building this tile were:

• Dino Esposito's article (based on the PDC build - be prepared to swap some SimpleText elements for Text elements and make a few other minor amendments)
• The PDC lab "Using Controls, Layout and Data Binding" (available here as a 25MB MSI file) had some of the best examples of writing real-world UI code with XAML - no more rotated list boxes, please!
• The online Longhorn SDK is of course one of the best reference sources, if it covers the object you're looking for...

I'll write again soon on this topic as soon as I've got my tile into a good enough state that I'm prepared to show it in public!

This is probably blatantly obvious to most people, but I've seen some confusion on this topic over the last couple of days, so documenting it is probably no great disaster. Some people aren't clear about how you install SQL Server 2005 ("Yukon") Beta 2 and Visual Studio 2005 ("Whidbey") Beta 1 on the same machine.

Although Yukon Beta 2 and Whidbey Beta 1 are designed to work together, Yukon shipped about a month later to allow a little longer for bake-testing. The one thing you have to watch out for is that Yukon Beta 2 installs a slightly later version of the .NET Framework (2.0.40607.42, which we'll call Beta 1+ for simplicity) than Whidbey (2.0.40607.16). Visual Studio 2005 can run on either version of the Framework, but SQL Server 2005 depends on the later version as a result of some late bugfixes. So how do you install them together?

If you're starting with a clean machine, the simple answer is to install SQL Server before Visual Studio - that way, the Beta 1+ version of the Framework is already on the machine by the time VS setup runs.

But a lot of people installed VS 2005 as soon as it came out and are perhaps confused by the error message they get from SQL Server when they try to install it. If you find yourself in that situation, uninstall the Beta 1 release of the Framework and then install SQL Server 2005, which will install both Beta 1+ of the Framework and the database engine itself. There's no need to uninstall the whole of VS 2005, just the .NET Framework itself. Clear as mud?

Once again, apologies if this is blatantly obvious, but perhaps it will save someone ten minutes' frustration.

In the potentially tiny off-chance that there's an interested soul in the country who hasn't already heard me jabber on about SQL / CLR integration and Analysis Services in SQL Server 2005, I'm co-presenting a day on Yukon with a few colleagues in London on September 1st. This should be a fun day: a chance to see SQL Server 2005 in action, learn about some of the recent add-ons and enhancements available for SQL Server 2000 and walk away with a copy of SQL Server 2005 Beta 2 and the SQL Server 2005 Resource Kit. The day is absolutely free-of-charge, but places are running out very quickly, so register online if you'd like to attend and I hope to see you there!

I've written before in my blog about my desire to see us produce better training and education for systems administrators, IT Pros and infrastructure architects on the benefits of the .NET Framework as an application platform. In short, many of the pain points felt by the infrastructure and operation guys - deployment, updating, application conflicts and security - are eliminated or at least ameliorated as a result of technology introduced in the Framework.

I've just recorded a two-part webcast for TechNet that covers this material in some detail, including deployment and management of Windows Forms and ASP.NET applications, security considerations, the internal structure of .NET assemblies and ongoing configuration using application manifests. These will be available for download for the next twelve months: you might like to send the link to your sysadmins if they're the ones who are blocking adoption of .NET within your organisation...!

Part 1 is available here, and part 2 continues here. The sound quality of part 1 is unfortunately rather poor, due to my misjudged use of a cheap telephone headset. I recommend using the full LiveMeeting option, rather than the RealAudio or Windows Media files, as it's the only one that includes the video portion (vital for the demos).

Interested in your comments or feedback: what other things would be helpful to increase awareness of the .NET Framework to this audience?