Juan Pablo Garcia’s Blog

Motivation

Since Microsoft launched StyleCop, we are running this tool in all Southworks’ projects. From our Engineering Excellence department we’re promoting the use of this tool because it give us source code consistency and homogeneity we want for developers and customers who read the code.

If you’re using this tool, you surely be realized that some Visual Studio templates are not compliant with some of the StyleCop rules, like using directives inside the namespaces, regions, one class for each file, among others. This is quite annoying when you’re coding because each class, interface or test you add to your project has to be stylized to meet that rules.

Project templates like ASP.Net Web MVC Application (Preview 5) have an amount of ~120 warning even avoiding the documentation rules.

The purpose of this post is to give you a workaround to avoid this unnecessary work.

Context

The way that Visual Studio provides these templates is by using a series of compressed zip files, with the base source code inside.

There are two folders inside the “%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\” with these templates, one for the items (classes, interfaces, tests, etc.) and one for projects (Class Library, Console Application, MVC Web Application, etc.).

Workaround

The workaround is pretty much straightforward, all you have to do is:

1. Extract the default Visual Studio template files
2. Modify them to be compliant
3. Compress it again
4. and overwrite the original files

What I did this weekend, is make the work for you for the most used files and projects for me including the Microsoft ASP.Net MVC preview 5 project template :). So below you’ll find a table with the zip files to download and the folder location where you will overwrite them.

Once you have copied the files, ensure you’ve all you Visual Studio instances closed and run as administrator from the console the following command to refresh Visual Studio’s template cache:

“%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com" /setup"

Template Files

(*) rootPath = "%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\"

You can also download all templates in a single .zip file: AllTemplates.zip

In my previous post, I started with a posts series that describe the tasks we’ve included in the Southworks SDC Tasks we recently published at Google Code.

Today, I’m going to focus in a useful and interesting task which is RemoveDuplicatedFileNames and the reason of why we had the need to create it.

So let’s start.

The Problem

Imagine you have a solution where your assemblies are referenced as depicted in the picture below:

When you compile this solution you’ll realize that the Contracts.dll assembly will be generated into the Services and in WebUx folders, that’s right?

So far, there is no problem regarding compilation, but what happens if we define an ItemGroup in our MSBuild project that includes all our solution assemblies to be examined by FxCop by using WildCards like this?

<ItemGroup>

  <Assemblies Include="$(SampleDirectory)\**\*.dll" />

</ItemGroup>

The answer is that FxCop will analyze the same assembly twice, which will generate duplicated warnings and Code Analysis errors.

Our solution approach

As I told you previously we created a simple task called RemoveDuplicatedFileNames that basically remove items from an ItemGroup on the MSBuild process, to avoid the problem described above.

So let me show you how you should configure your project file to use this task

1. Reference the Southworks SDC Tasks assembly RemoveDuplicatedFileNames in your project file

   <UsingTask AssemblyFile="$(ToolsPath)\Southworks.Sdc.Tasks.dll"

              TaskName="RemoveDuplicatedFileNames"/>

2. Create your ItemGroup including your assembly files

   <ItemGroup>

     <Assemblies Include="$(SampleDirectory)\**\*.dll" />

   </ItemGroup>

3. Inside the target that runs FxCop include the following lines

   <RemoveDuplicatedFileNames Input="@(Assemblies)">

     <Output TaskParameter="FilteredItems" 

             ItemName="CodeAnalysisItems" />

   </RemoveDuplicatedFileNames>

4. Finally, instead of using the Assemblies defined in the first point, you should use the new filtered ItemGroup generated in the previous point

   <FxCop Assemblies="@(CodeAnalysisItems)"

          OutfileName="$(CCNetArtifactDirectory)\fxcop.xml"

          ProjectFilePath="$(CCNetArtifactDirectory)\project.fxcop"

          ToolPath="$(FxCopPath)"

          ProjectTemplateFilePath="$(ToolsPath)\template.fxcop" />

Note: The FxCop task is not part of Southworks SDC Tasks, you can get it from the Microsoft SDC Tasks at Codeplex. There are many useful tasks for your build process!

Verification

in order to verify if your assemblies are no duplicated you should add a Message task on the same target to display the contained values on both ItemGroup, Assemblies and CodeAnalysisItems.

<Message Text="Unfiltered Assemblies" />

<Message Text="=====================" />

<Message Text="@(Assemblies)" />

<Message Text="Filtered Assemblies" />

<Message Text="===================" />

<Message Text="@(CodeAnalysisItems)" />

Technorati Profile

Johnny and Ezequiel had published in they blogs about the Southworks SDC Tasks we published two weeks ago in Google Code. This project is a set of comprehensive MSBuild tasks that we built along with the maturity of our build process.

I’ll give you a walkthrough for these tasks we developed by giving you a sample of each one of them.

In this post you will find how you can easily update your assembly info files with company information by using the UpdateAssemblyinfo task.

This task is pretty much straight-forward, so I will create a simple .proj file to demonstrate how it works.

Reference the SDC assembly in your project file

The first step is to add the assembly reference for this specific task by giving the AssemblyFile and the TaskName values:

<Project DefaultTargets="UpdateAssemblyInfos" 

         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <UsingTask AssemblyFile="d:\test\Southworks.Sdc.Tasks.dll"

             TaskName="UpdateAssemblyInfo"/> 

</Project>

Notice that the DefaultTargets property indicates which target will be first executed, I’m going to include this target later.

Defining the files to be updated

Then, you need to specify which files will be updated and where they’re located. To do that create a new ItemGroup. If you want to know more about including and/or including Items, see http://msdn.microsoft.com/en-us/library/646dk05y.aspx.

<Project DefaultTargets="UpdateAssemblyInfos"

         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <UsingTask AssemblyFile="d:\test\Southworks.Sdc.Tasks.dll"

             TaskName="UpdateAssemblyInfo"/>  

  <ItemGroup>

    <AssemblyInfos Include="d:\test\**\AssemblyInfo.cs"/>

  </ItemGroup>

</Project>

Configure the UpdateAssemblyinfo target

Finally create and configure a new target by specifying the information to be replaced on the files we defined in the previous step.

<Project DefaultTargets="UpdateAssemblyInfos" 

         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <UsingTask AssemblyFile="d:\test\Southworks.Sdc.Tasks.dll"

             TaskName="UpdateAssemblyInfo"/>

  <ItemGroup>

    <AssemblyInfos Include="d:\test\**\AssemblyInfo.cs"/>

  </ItemGroup>

  <Target Name="UpdateAssemblyInfos">

    <UpdateAssemblyinfo Include="@(AssemblyInfos)"

                      AssemblyCopyright="Southworks (r) copyright"

                      AssemblyCompany="Southworks"

                      AssemblyProduct="Sample product " />

  </Target>

</Project>

To see if all it’s working as expected, you could run the project file with MSBuild as depicted bellow:

Open the sample AssemblyInfo.cs file and see how it was updated:

thanks, stay tuned!

Spanish Version

Last week we were working on our Build Server using CruiseControl.Net to allow multiple Test / Code Coverage tasks for two or more solutions.

Once we’ve configured the .proj file to run a set of two RunTests / RunCodeCoverage tasks we needed to merge the results file to the MSBuild log after running them.

So, our first approach was modifying the ccnet.config file to merge the files generated by these tasks using the same pattern of MSBuild, I mean, using "\**\", something like this:

<merge>

  <files>

    <file>D:\srv\ccnet\logs\project\**\*.trx</file>

    <file>D:\srv\ccnet\logs\project\**\*.cvg</file>

  </files>

</merge>

At this point, we have figured out that Cruise Control .Net does not have this functionality, only it allows to run something like D:\srv\ccnet\logs\project\theProject\*.trx, and since the CruiseControl.Net source code is available I started to writing some lines to modify the ThoughtWorks.CruiseControl.Core assembly to allow that.

In this post you will find the source code of the spike I wrote with a series of tests to implement that feature and the WildCardPath.cs source code from the core CruiseControl.Net project updated.

• Spike solution with tests [Download]
• WildCardPath class file of CruiseControl.Net Core assembly [Download]

Once you have updated the Core project with the new implementation of the WildCardPath class, you need to do the following tasks to keep it running.

1. Compile the Core project
2. Stop the CruiseControl.Net service
3. Replace the ThoughtWorks.CruiseControl.Core assembly with the new one.

And that’s it, use wildcards as in MSBuild

Microsoft has published a great tool called Microsoft Source Analysis for C#, formerly known as StyleCop.

This tool allow us to review and improve our source code quality. It’s is fully integrated with Visual Studio, so with a single right click in a solution, project or file, we can check our code against the best practices defined in a series of rules depicted below.

You will find a detailed explanation on the Announcing the release of Microsoft Source Analysis for C# post and download the latest bits from here.

Also you can customize which rules should be checked using the built-in configuration tool.

Finally, another good point is that we can integrate that tool on our build process with MSBuild. I recomend you the Jason Allor’s blog post on the Source Analysis Blog page where he explains how to do that.

Here is another good post from MSBuild Team Blog also, announcing this release.

Enjoy it and say goodbye to the documents with code-standards