Updated to CS2.1 SP1 and fixed an issue

I just upgraded my site to Community Server 2.1 SP1. I wouldn't post this if I did not encounter an issue, though you may experience this error only if you use my coComment support for CS. In fact, it occurs only if you use BlogThreadQuery and set ReturnFullThread to false. In this case, the stored procedure cs_weblog_PostSet does not return ApplicationPostType for found posts, but the code tries to retrieve it from the IDataReader.

I attached a corrected version of that SP to this post. In fact, I only added P.ApplicationPostType, in line 128.

Auto-attaching to aspnet_wp.exe

Dennis van der Stelt asked me how to debug CSModules without using the Community Server SDK. Ok, so here's how I debug my modules.

First I set the output directory of my projects to CS' bin folder. To debug the module, I attach the debugger manually to ASP.NET worker process, aspnet_wp.exe. However, that's not very ergonomic, because you have to go to DebugAttach To Process, select aspnet_wp.exe (fortunately, processes are sorted by their name) and click OK.

However, after a while that gets really annoying.

Therefore I searched for a simpler solution, e.g. an add-in. I stumbled over this nice and short macro, published by Roy Osherove (who else? [;)]):

This was on the win-tech-off-topic mailing list:

A macro to automatically attach to aspnet_wp.exe, written by Kevin Dente can save lots of clicking around time:

Sub AttachAspNet()
    Dim process As EnvDTE.Process
    If Not (DTE.Debugger.DebuggedProcesses Is Nothing) Then
        For Each process In DTE.Debugger.DebuggedProcesses
            If (process.Name.IndexOf("aspnet\_wp.exe") \<\> -1) Then
                Exit Sub
            End If
    End If
    For Each process In DTE.Debugger.LocalProcesses
        If (process.Name.IndexOf("aspnet\_wp.exe") \<\> -1) Then
            Exit Sub
        End If
End Sub

Unfortunately, it's not perfect. Process.Attach doesn't let you specify the program type (CLR, Script, native, etc). I think that it uses whatever your last selection was in the UI. But don't quote me on that, it's been a while.

I added the macro to a toolbar, so debugging my modules is only one click far. [:)]

New Features in CS 3.0

Community Server Comments

Scott posted his three favorite new features in Community Server 3.0, one of which is

  1. Configuration Merge - one of the deployment things I hate is managing configuration files. We now support placing configuration overrides in an optional "_override" file. At runtime, CS will attempt to override default settings with changes found in the override file. The override file uses a pretty simple schema/structure along with XPath.  (Note: as in previous releases, each version places less in configuration files, but there are some cases where this is not feasible, hence the need for a way to manage it a little better). Also of interest, we have moved the connectionstring to a separate file. This is fully supported by ASP.Net out of the box. Our initial thought was this would be for development only and when we shipped we would move it back. Having used this system for a couple weeks, I am starting to think we should keep it for the long haul. The connectionstring is generally the only thing users had to change in the web.config, with this now external, it makes it much easier to deploy updates and new versions.

Great news for all developers who extend CS with jobs, modules etc, because users do not have to edit CS' configuration files anymore. E.g. in the past you had to add the module type to the CSModules section in communityserver.config. As far as I understand, with CS 3.0 you can simply drop your CSMVPs_communityserver_override.config (or whatever the naming schema is) into the root folder of your CS installation, and CS will pick up your modules/jobs automatically. I'm curious about the implementation.

Internet Explorer 7 Installation

Firefox, Internet Explorer Comments

I just upgraded Internet Explorer on my third machine. Jayson has something to say about the installation process:

Today like the rest of the free internet using world, I installed Internet Explorer 7.  Yes it looks good, is more standards compliant, is (supposedly) more secure, blah blah blah.  I have installed IE7 in various incarnations 4 times (on this machine) over the past few months...the installation routine is just simply ridiculous; total elapsed time from the point I started today's installation routine, just over ten minutes.  To install an f'ing web browser.  That's one (1) uninstallation routine that runs to get rid of previous versions, two (2) reboots needed to complete installation...that is 1 uninstallation and 2 reboots too many in my opinion, not to mention that after the first reboot completes your machine is unusable as the installation and configuration routines both run before Explorer is launched.  Hum a tune, twiddle your thumbs, fold laundry, whatever...sit and wait 10 minutes for ~14 megs of software to install on your machine.

Yes, the update process is annoying. And though the IE Team pledges that the setup won't change the default browser setting, on one of machines (which all are set to Firefox) the default was set back to IE. And on all machines the fonts were reset to Times New Roman and Courier New. So after each installation I had to set the fonts back to my favorites, Calibri and Consolas. What a bummer!