If you’re like I am, then you can’t stand all the garbage references and using statements in some of the VS Project and Item templates, and instantly remove many of those references.  I talk myself into doing that by reasoning that if I need an assembly reference – that I want to overtly make the choice myself, so that I can think about what the dependency on that component assembly is providing to my current layer.

Well, tonight I got burned by removing references from project templates to System.Core, and finding out that in fact when you try to re-reference this assembly, it still shows in VS2010 as selected, as such:

Solution references showing no reference to System.Core:

Note the Add Reference Dialog showing an existing reference to System.Core:

What gives?  Well, I blogged this because the solution was not quite straightforward, but trivial when you think about it.  I simply opened up my .csproj file and added the reference in manually using Notepad2, and reloading the project when prompted to do so by VS2010.  Here’s how to add the reference in:

  <ItemGroup>
    <Reference Include="System.Core" />
  </ItemGroup>

Note that the <Reference /> node can be included in another <ItemGroup /> if one exists.

By the way, if you’re wondering about the reference to System.Linq: well – it is in System.Core.dll.  That’s the connection…

Hope this helps someone.

I was having some difficulty the other day getting code coverage analysis to run on just the selected assemblies that I wanted in my build output directory, and had the requirement (placed on myself) that I didn’t want to list the assemblies declaratively in my build configuration file.  Not finding a quick solution, I thought I’d share what I came up with – it may end up being helpful to someone out there.  Please do let me know if you have another solution, I’d be interested in hearing about it.

As a background, I’m using the Gallio suite (including MbUnit) for testing which includes the Gallio test runner and custom Gallio NAnt task.  I want to limit the list of covered assemblies to those meeting a set of criteria, not all assemblies in a given folder.  The solution I came up with involves writing a custom NAnt function, which turns out to be a trivial thing to do.

First, a portion of my Gallio NAnt task:

    <gallio runner-type="NCover" 
            working-directory="${build.output.dir}"
            report-types="html"
            report-directory="${test.output.dir}"
            show-reports="false"
            failonerror="true"
            verbosity="Normal"
            echo-results="true">
      <runner-property value="NCoverArguments='//q //a ${coverage.assemblies}'"/>

Note the <runner-property /> element with NCoverArguments specified in the value attribute.  In this attribute, I specify a list of NCover runtime arguments, including the //a argument used to specify the list of assemblies to be profiled delimited by semi-colons.  The trick for me was to set this list dynamically.  I also, quite frankly, didn’t want to get into writing a ton of NAnt code using things like string::concat functions and whatnot.  Before I call this <gallio /> task in the appropriate target, I set a property like so:

    <property name="coverage.assemblies" 
              value="${mlincek::getcoverageassemblies(assembly.output.dir)}"/>

Essentially, here, I have set the list of coverage assemblies (property/variable ‘coverage.assemblies’) by calling out to a custom-written NAnt function that I have written, and passing in my build output directory as a string.  Note this function returns a string:

  <!-- Custom NAnt functions -->
  <script language="C#" prefix="mlincek">
    <code>
      <![CDATA[
        [Function("getcoverageassemblies")]
        public static string GetCoverageAssemblies(string assemblyFolder)
        {
          StringBuilder sb = new StringBuilder();
          FileInfo[] files = (new DirectoryInfo(assemblyFolder)).GetFiles();
          foreach (FileInfo file in files)
          {
            string fileName = file.Name;
            if (!fileName.EndsWith(".Tests.dll") && !fileName.EndsWith(".pdb"))
            {
              int dllPosition = fileName.LastIndexOf(".dll");
              sb.Append(fileName.Substring(0, dllPosition) + ";");
            }
          }
          return sb.ToString();
        }
      ]]>
    </code>
  </script>

You can place this script task at the bottom of your NAnt .build file, or do as I do and place it into a common.build file which you can reference via a NAnt <include /> task.  Of course, this function could be made more flexible and used for other things besides setting the coverage assembly list simply by passing in the filter criteria either as a string parameter, an expression, or a collection of rules (rule objects), but hey, this is a build file for gosh sakes and it got the job done for me.

Now, I can add assemblies to my overall solution and as long as I follow my naming conventions for projects and build folder structure, they will be picked up automatically for coverage analysis, per my filter criteria.

Hope this helps someone!

Hello all!  Sorry I have been away for several months – it has been a busy spring, summer and now fall here in northeast Ohio.  I thought I’d drop a quick post today highlighting a great piece of research that I just finished reading.

Those of you who know me know what a great fan I am of Conway’s Law.  Having worked for and consulted for many organizations over my career thus far, I have found Conway’s Law to be a solid, immutable truth.  For those of you not familiar with Conway’s Law, it essentially states that:

…organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

Since software development is about expressing and constructing a solution to solve a problem, the pattern of communication about the problem domain and the vocabulary used to describe it becomes paramount.  In addition, the manner in which this pattern of communication takes place and evolves – ultimately – influences solution design, construction and implementation.  I guess I like to say that good, well-run organizations produce good software.  And, that… …well, you get the picture.  Note that in my experience the word “organization” here applies to both the technology department and the business people in the organization (can’t have one without the other).

Though there has been additional research on Conway’s Law since Melvin Conway first introduced it in 1968, empirical evidence has seemingly been hard to come by.  Thus, often (at least from my perspective), Conway’s Law can end up relegated to the subject of discreet giggling around the water coolers and hallways of dysfunctional organizations.

How fitting is it then that this study, in the midst of the unit test code coverage quality debate, actually ties organizational metrics to the quality of software produced!?  I say, quite fitting.  Take a moment and read it.  I believe it will validate all that you’ve likely come to know and expected about the effects of “the organization” on producing software.

Non-softies take note: You just might even find it humorous that the guinea pig used to exercise the metrics was none other than Vista!

Cheers!

TheInfluenceOfOrgStructureOnSoftwareQuality.pdf (172.27 kb)