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!

Per my last post on Some Interesting Architecture Reading, I wanted to note that one of the authors of the book Microsoft .NET: Architecting Applications for the Enterprise, Dino Esposito, was recently over on dotnetrocks.com doing a show with Carl Franklin and Richard Campbell.  He mentions that book which I had recently reviewed in my blog, and of course has a nice interview with Carl and Richard on interesting things architectural.

By the way, if you’ve never checked out dotnetrocks.com, it’s a great way to catch up on trends occurring in the .Net stack when you’re driving or have other time when you can listen to an audio podcast.

This past winter I completed a well-done book by Dino Esposito and Andrea Saltarello entitled Microsoft .NET: Architecting Applications for the Enterprise.  I’d like to give my endorsement to this well-written, well-thought-out book.  It encapsulates all of the core concepts needed to correctly build an enterprise-class, durable, yet flexible application.  In many cases, it also gives these concepts detailed treatment, as well.

What I like most about this book is that, although it’s got “.NET” in the title – and it occasionally touts Microsoft-specific technologies, most of book content is dedicated on traditional application architecture and design concepts that are time-tested, proven, and have developed outside of the .NET community.  This includes concepts such as UML, layered architecture and the use of design patterns.  This is a good thing.

Although the book is not a replacement for the core application design and architecture books that I consider mandatory reading from authors such as Booch, GoF, and Fowler (more on this in a future post), it is a great book to dive into that you can consider a comprehensive and detailed treatment of application architecture.  Check it out.

Additionally, while listening to a podcast today, I heard about App Arch Guide 2.0 from the Microsoft Patterns & Practices team.  While I have not read this book, I can say that the interview with one of the authors was compelling enough for me to download it.  More to come on this one.

A non-obvious way to alter the behavior of .NET automatically populating Soap fault elements with stack trace information (specifically, in the faultString element) is to use the customErrors configuration element, which is part of the ASP.NET Settings Schema.

I state this is non-obvious because in the documentation, the following statement is made here under the Remarks section:

The <customErrors> element does not apply to errors that occur in XML Web services.

However, the use of this element’s mode attribute clearly does alter the behavior, when setting the mode attribute to “On”, in the system.web configuration section:

<configuration>
    <system.web>
        <customErrors mode="On" />
    </system.web>
</configuration>

Note that the default setting for the customErrors element’s mode attribute is “RemoteOnly” which will add stack trace information for local requests and remove it for remote requests.  This is usually desirable behavior but depending upon your own needs it is good to know the availability of the mode attribute’s “On” setting to always, universally remove the stack trace information, should you desire to do so.