I’m a fan of the Open Source project SubSonic, spearheaded by Rob Conery of Microsoft, which describes itself thusly:

A Super High-fidelity Batman Utility Belt. SubSonic works up your DAL for you, throws in some much-needed utility functions, and generally speeds along your dev cycle.

I’ve seen a few questions on the Internet about setting the SubSonic connectionstring at runtime and thought I’d post what I’ve done. SubSonic includes a tool to generate a DAL for you which picks up settings from your .config file which provides the connectionstring among other things. I’m using SubSonic in a plugin to CruiseControl.NET for EDI processing and here the portion of my ccservice.exe.config file related to SubSonic:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <configSections>
        <section name="SubSonicService" type="SubSonic.SubSonicSection, SubSonic" 
        requirePermission="false"/>
    </configSections>
  <connectionStrings>
    <add name="Velocity2" 
    connectionString="Data Source=db;Initial Catalog=db;Persist Security Info=True;"
    providerName="System.Data.SqlClient" />
  </connectionStrings>
  <SubSonicService defaultProvider="Velocity">
    <providers>
      <clear/>
      <add name="Velocity" 
           type="Subsonic.SqlDataProvider, SubSonic" 
           connectionStringName="Velocity2" 
           generatedNamespace="VelocitySubSonic"
           includeTableList="AR_*,CORE_*,EDI_*,II_*,IN_*,SA_*"
           excludeProcedureList="WMS_InsertImportQueue"
            />
    </providers>
  </SubSonicService>
...

One of the things I wanted to do is override the connectionstring using a property on my CCNET plugin. To do that I implemented a property like this:

[ReflectorProperty("connectionString")]
public string ConnectionString
{
    get { return m_connectionstring; }
    set
    {
        m_connectionstring = value;
        SubSonic.DataService.GetInstance("Velocity").SetDefaultConnectionString(value);
    }
}

On Thursday, Yahoo rolled out changes to my.yahoo.com updating the layout of the page with a beta version. One of the items that seemingly got lost was the link to switch back to the classic layout. I’ve played with the new layout and still prefer the old classic style that I’ve used for years now. Fortunately, at least for the time being, you can still switch back to the classic layout using this URL.

The other day I discovered one of the MSSQL tables I’m using heavily at the moment had 214 indices! There were about 20 with sensible names and the rest were all named similar to _dta_index_SA_OrderHeader_5_499519046__K1_2_6_9_13. I mentioned this issue to John Waters in the office today which elicited a nice laugh until I sent him this screenshot:

While I’m not exactly new to MSSQL I’m no expert though fortunately Falafel has a few experts on staff and John’s one of them. He dug into the problem answering the what, where and how to deal them, feel free to click through if that’s what you need.

Had I not blogged back in February asking about MSSQL tools this problem would likely have gone undetected for a lot longer. Microsoft’s Management Studio doesn’t show these so called Hypothetical Indices so you have no way of knowing your table/DB is being impacted by them. Ironically, they’re created by the Index Tuning Wizard. Anyway, one commenter to my post mentioned EMS Database Management Solutions (a mouthful notwithstanding whatever EMS stands for) SQL Manager 2008 for which there is a freeware download. SQL Manager’s treeview provides a wealth of information including counts for things like indices which allowed me to easily stumble upon the problem.

All in all, there were 500+ of these indices hanging around but thanks to SQL Manager no longer!

Building from the command line != building from the IDE

I just spent the last several hours fixing a large number of assembly references in a big C# solution. That means lots of errors like the following that leave you grep’ing your way through .sln/.csproj files to figure out what’s gone wrong:

Solution file warning MSB4051: Project {A9E00AF7-A1E0-4E65-90EF-CB66E8580
9AE} is referencing a project with GUID {958E0376-0272-4149-A1CF-E03521D12A72}, but a project with this GUID was not found in the .SLN file.

And builds stats that look like this:

Not good. It doesn’t help when VS.NET itself can cause these problems yet continue on blissfully. What I ran into today was a different reason for the same error message, this time around it wasn’t a missing "EndProject". The issue was that the second GUI was referring to a project that not only wasn’t in the .sln file but no longer existed. Regardless, the outcome was the same, building from VS.NET worked but executing MSBuild from the command line failed. WHY?! IMO, VS.NET should have failed just like MSBuild because it’s not doing you any favors when it doesn’t fail consistently along with MSBuild rather that’s just masking a problem. In addition, the error could be improved to show better information about the GUIDs that do reference a project rather than the GUID itself. I couldn’t agree more with Jeff Atwood’s post title The F5 Key Is Not a Bulid Process where he says:

If your "build process" is the F5 key, you have a problem. ...

Get your build process out of the IDE and into a build script. That’s the first step on the road to build enlightenment.

Communicating Continuous Integration Requirements

If you’re chasing the holy grail of CI and working to get automated builds, test execution, static code analysis, build stats etc. make sure the developers working on the project understand the build requirements of your CI setup. In this case, building the main project is about as straight forward as it gets:

Like I said, simple. Now, on the build server itself things aren’t quite this simple but for the bulk of the build if you get by this step you’ve gone a long way as it builds 22 C# projects. The first line above, that cleans the build is crucial. If you skip it and build from the command line after building in VS.NET you’ll continue masking the problem. A successful clean process is just as important as a successful build process. On this particular project there was a major project renaming that introduced a slew of errors but the VS.NET IDE sat idly by and in fact allowed this problem to occur. Eventually a checkin that trigger this set of failures occurred all the while "it builds fine on my machine".

The second problem was solution file name changes, copy/renames to be more specific, which further broke the CI build. The third problem was that the old .sln and csproj files were not deleted from the repository which led to even more confusion but I digress, that’s life in the real world, we fix it and move on.

Recently, based on comments to this post I decided to turn Vistas UAC back on in "silent mode" using TweakUAC. Doing so allows me to run Windows Live Mesh to support folder synchronization which I’m now using to backup my blog content. The downside is that after making this change I started getting System.Runtime.InteropServices.COMException errors when loading a large application into VS.NET 2008.

After a bit of head scratching I thought to change my VS.NET shortcut to launch with "Run as Administrator" enabled which resolved the error. Now, back to work!