NDepend v3 - now 100% integrated in Visual Studio

An article by Laurent Kempé No Comments

Patrick just announced on his blog the launch of the new NDepend v3. It is still in beta but very stable. I am testing it for a month now and enjoy very much it’s integration in Visual Studio 2008. I was using it and will continue to use it in our continuous integration server, TeamCity. But getting feedback right out of the developer environment is a very interesting feature.

Read more on Patrick’s blog post, “NDepend v3 is now 100% integrated in Visual Studio“

Even on large code base, made of hundreds of thousands of lines of code and dozens of VS projects, Visual Studio is not noticeably slow down by the NDepend v3 addin.

VisualStudio 2010, 2008 and 2005

Simply put, what NDepend v2 does in the Continuous Integration/Build process, NDepend v3 does it live at development-time inside Visual Studio

Multi VS solutions wide-analysis and collaboration

Rich Code Search in VS

Multi CQL Query Edition in VS

Code visualization in VS

Continuous comparison with a base line in VS

Reflector disassembly’s comparison

Deep VS Integration

NDepend Session state preserved

Well done Patrick!

ClickOnce ISignedCode::Sign returned error: 0x80880253

An article by Laurent Kempé No Comments

Tonight we got the following issue on our TeamCity build server which produce different ClickOnce setups :

c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(3652, 9): error MSB3482: An error occurred while signing: Failed to sign ..\..\Tests\Output\bin\DeployClickOnce\app.publish\setup.exe. 
SignTool Error: ISignedCode::Sign returned error: 0x80880253
    The signer's certificate is not valid for signing.
SignTool Error: An error occurred while attempting to sign: ..\..\Tests\Output\bin\DeployClickOnce\app.publish\setup.exe

Checking the certificate used by our project I found that the expiration date was yesterday:

So I had first to create a new test certificate.

Then I had to re-install the certificate on the server, as described in “ClickOnce certificate and TeamCity”. Before installing I had to remove the old one using:

> Psexec.exe -i -s cmd.exe

then running

> mmc

and removing by hand the old certifcate.

TeamCity 5.0 '​Failed to collect changes error' issue

An article by Laurent Kempé No Comments

Tonight I was facing an issue with TeamCity 5.0 plugin in Visual Studio 2008.

I was getting the error message '​Failed to collect changes error' in the new Local changes window.

Searching on the bug tracking tool of JetBrains for TeamCity I found this issue "TW-10474 I can not make VS addin recollect changes after recieveing '​Failed to collect changes error'”

Has this issue breaks my way to work with pre-tested build I decided to search for a solution because I cannot work without this now!

So following the instruction "Logging in TeamCity Visual Studio plugin" : Reporting Issues

Looking at the produced logs I found this:

9:28:24 PM.987: Thread:31: svn.exe info "xml" "non-interactive" "p:\@projects\_handsup\portal"
9:28:24 PM.987: Thread:31: Failed to execute svn. code 1, error svn: Try 'svn help' for more info svn: Syntax error parsing revision 'projects\_handsup\portal' , output <?xml version="1.0"?> <info>
9:28:24 PM.991: Thread:31: EXCEPTION: svn: Try 'svn help' for more info
svn: Syntax error parsing revision 'projects\_handsup\portal'.
Svn has exited with code '1'.
SvnInfoUuidCommand failed

I tried then the svn command from the command prompt and got the same error!

I finally renamed the path to my project from p:\@projects\_handsup\portal to p:\projects\_handsup\portal

And now it works again! So forget strange characters in your path!

ProjectReference with Condition in your MSBuild project files

An article by Laurent Kempé No Comments

Since some time I have the current scenario where I need to have conditional reference in a project. Basically the application must reference an assembly in one case in other it should reference another one. This was working correctly from an MSBuild point of view as the first implemented solution let me compile and run the application on my development machine and it was also working for our TeamCity build server. So everything was fine in this perfect word expect one thing!

The issue was the following; Visual Studio was showing two references of the ‘same assembly’ with different path. Not really an issue you would say because the correct one was used at compile time and at run time in all configurations. So the issue was that this had an impact of ReSharper. And this is I cannot accept because it affect my productivity.

So the other day I had a discussion with Ilya of JetBrains which gave me some idea but also told me that ReSharper reads project structure out of Visual Studio and that it doesn't provide lots of info, e.g. conditions on references. So this is why seeing two reference of the ‘same assembly’ was not a problem on Visual Studio itself and on the build server but was an issue to ReSharper because it was seeing two same reference, same namespace, same classes…

Today I had some time free and decided to see where I can come with this issue. And I found a solution.

My first solution, which had the explained issue was the same as the one on this post “Don't be afraid of your csproj-Files (III): We have a condition”, so having a Condition on the ItemGroup.

The solution I came to is to bring the Condition to one upper level than the ItemGroup, so I used Choose like this:

Reloading the project I had the surprise to see only one reference and that ReSharper was working again correctly!

For sure the build on TeamCity is also working perfectly.

Automating Publish of ClickOnce with TeamCity

An article by Laurent Kempé No Comments

The other day I published different posts about the way I automated our build process at Innoveo Solutions to generate different ClickOnce setup using TeamCity:

Build multiple ClickOnce deployment packages using MSBuild and Team City
Building ClickOnce with TeamCity
ClickOnce certificate and TeamCity
Build ClickOnce deployment packages using MSBuild and Team City

Yesterday I was asked to solve one minor issue. At ClickOnce publishing time the publish.htm file was not generated so the ClickOnce version number on the web page wasn’t shown. The publish.htm file is a static file on the targeted deploy directory and IIS uses that file. The file contains a hard coded version 2.0.0.x.

So from a user perspective it was difficult to know if there were a new version. So I was asked to show the correct version.

I knew from past research a way to handle this from the following post: How To: Generate publish.htm with MSBuild

But I went to a more pragmatic solution, as I already had the MSBuild Community Tasks.

I made a copy of Publish.htm to Publish.htm.ori on each targeted deploy directory.

Then I modified my MSBuild script to do the following:

1. Copy Publish.html.ori to Publish.htm
2. Use FileUpdate of MSBuild Community Tasks to search the 2.0.0.x string and replace it with the version

and the FullVersion is defined as this, using TeamCity BUILD_VCS_NUMBER, which is Latest VCS revision:

And now the Publish webpage display the version correctly!

Build multiple ClickOnce deployment packages using MSBuild and Team City

An article by Laurent Kempé No Comments

The other day I posted about Build ClickOnce deployment packages using MSBuild and Team City, and there were something that I didn’t liked in my way of doing it.

I have multiple ClickOnce deployment packages created using TeamCity and MSBuild but each ClickOnce packages have their own Application Revision due to the usage of TeamCity BUILD_NUMBER server build property.

So I changed to use TeamCity BUILD_VCS_NUMBER_<simplified VCS root name>

And now all my ClickOnce packages have the same Application Revision which is better !

Building ClickOnce with TeamCity

An article by Laurent Kempé No Comments

Migrating our TeamCity server today I got the following error on the new server:

error MSB3147: Could not find required file 'setup.bin' in …

I for sure fixed that on the older server, and the fix was to have the SDK on the build server. The issue is that I don’t want to install Visual Studio to do that, so here is how I achieved it

1. Copy my whole c:\Program Files\Microsoft SDKs\Windows\v6.0a folder to the server
2. Created a registry key
   Key: HKEY_LOCAL_MACHINE\Software\Microsoft\GenericBootstrapper\3.5\
   Value: Path
   Type: REG_SZ
   Data: C:\Program Files\Microsoft SDKs\Windows\v6.0a\Bootstrapper\

Then the error was gone and I had my build server ready again to build ClickOnce setup.

MSBuild and Silverlight 2.0 Beta 2 SDK running in Team City

An article by Laurent Kempé 1 Comment

First you need to un-install the Silverlight 2.0 Beta 1 SDK from the build server! Then you can download the Microsoft Silverlight Tools Beta 2 for Visual Studio 2008 and extract it on the server, there you will find the file silverlight_sdk.msi, that will allow you to install Silverlight 2.0 Beta 2 SDK.

Now if you followed my post MSBuild and Silverlight 2.0 Beta 1 running in Team City, then you know about the issue:

Using MSbuild to build a solution in a command line doesn’t copy the Silverlight project output to the linked web project

This issue is still there so my fix is still in my MSBuild file.

MSBuild and Silverlight 2.0 Beta 1 running in Team City

An article by Laurent Kempé 1 Comment

If you want to integrate Silverlight 2.0 Beta 1 in your Continuous Integration system, in my case Team City), it is better to read the readme of Silverlight 2.0 Beta 1 SDK here.

The important part in our case is the following one:

Using MSbuild to build a solution in a command line doesn’t copy the Silverlight project output to the linked web project

We don’t have complete support for command line msbuild usage to build solutions with Silverlight projects which also includes 64 bits MSBuild support.

So basically I made a copy manually from the source of the Silverlight project to the output path of my MSBuild project:

Now my web application is compiled, deployed and works!

Run NCover through MSBuild in Team City

An article by Laurent Kempé 4 Comments

After one comment of Chris Walquist on one of my last post about Team City integration of NCover here is the way I run NCover through MSBuild in Team City.

First I need to import the Task of NCover.

<ProjectToolsVersion="3.5"DefaultTargets="Build"xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask TaskName="NCoverExplorer.MSBuildTasks.NCover"AssemblyFile="$(NCoverPath)\Build Task Plugins\NCoverExplorer.MSBuildTasks.dll" />
  <UsingTask TaskName="NCoverExplorer.MSBuildTasks.NCoverExplorer"AssemblyFile="$(NCoverPath)\Build Task Plugins\NCoverExplorer.MSBuildTasks.dll" />

Then I define some properties:

    <!-- NCover -->
    <SolutionFolder>$(MSBuildProjectDirectory)\..\..</SolutionFolder>
    <TestsFolder>$(MSBuildProjectDirectory)\..\..\Tests</TestsFolder>
    <NCoverPath>C:\Program Files\NCover</NCoverPath>
    <NUnitPath>C:\Program Files\NUnit 2.4.6\bin</NUnitPath>
    <TestDll>TechHeadBrothers.Portal.DataAccess.Tests.dll TechHeadBrothers.Portal.DataAccess.dll</TestDll>
    <CoverageFile>..\..\Tests\Output\Coverage.xml</CoverageFile>
    <CoverageExclusions>Assembly=*.Tests</CoverageExclusions>
    <CoverageAssemblies>TechHeadBrothers.Portal.DataAccess;TechHeadBrothers.Portal.Domain;</CoverageAssemblies>

Then I have two targets:

  <Target Name="FullCoverage">
    <Message Text="#--------- Executing NCover ---------#" />
    <NCover ToolPath="$(NCoverPath)" 
            CommandLineExe="$(NUnitPath)\nunit-console.exe" 
            CommandLineArgs="$(TestDll)" 
            WorkingDirectory="$(TestsFolder)\Output\bin\Debug" 
            ProjectName="$(ProjectName)" 
            CoverageFile="$(CoverageFile)" 
            FileExclusionPatterns="$(CoverageExclusions)" 
            LogFile="Coverage.log" 
            AssemblyList="$(CoverageAssemblies)" />
    <!-- Summary Page -->
    <NCoverExplorer ToolPath="$(NCoverPath)" 
                    ProjectName="$(ProjectName)" 
                    OutputDir="$(TestsFolder)\Output" 
                    CoverageFiles="$(CoverageFile)" 
                    SatisfactoryCoverage="80" 
                    ReportType="ModuleClassSummary" 
                    HtmlReportName="CoverageSummary.html" />
    <!-- Full HTML Report -->
    <NCoverExplorer ToolPath="$(NCoverPath)" 
                    ProjectName="$(ProjectName)" 
                    OutputDir="$(TestsFolder)\Output\Coverage" 
                    CoverageFiles="$(CoverageFile)" 
                    SatisfactoryCoverage="80" 
                    ReportType="FullCoverageReport" 
                    HtmlReportName="Coverage.html" />
  </Target>

And finally in the target AfterBuild (more on that in this post) I call target SummaryCoverage or FullCoverage according to the configuration:

  <Target Name="AfterBuild">
    <CallTarget Condition=" '$(Configuration)' == 'Staging' " Targets="SummaryCoverage" ContinueOnError="false" />
    <CallTarget Condition=" '$(Configuration)' == 'Nightly' " Targets="FullCoverage" ContinueOnError="false" />

That's it!

Then Chris asked the following:

1) How did you get your "tests" tab to show up as well?  Did you have to run the tests with NUnitLauncher, and then run again for coverage?  I read that NUnitLauncher can't be used to profile, since it kicks off a separate process.

2) How did you get the "classes", "header", "index", etc. files?  I just get the summary.html.  I see options for this in ncover.console.exe but not in the <NCoverExplorer> target.

3) Did you use wildcard expressions to pass a list of test assemblies to NCover?  If so, would like to see how you did that, too.

1) I get the test tab configuring Team City to run my unit tests. That has nothing to do with NCover. And yes doing it so seems to run two time all unit tests. Here is a screen shot of my team city runner configuration:

2) Read this post "Using NDepend in Team City build management tool" that talks about for NDepend but shows configuration for NCover too.

3) The answer is on top of this post!

Hope it helps!