Build .NET projects from Windows Explorer using MSBuild Launch Pad (mPad)

An article by Laurent Kempé No Comments

In September 2009 I posted about a tool I am using to build my MSBuild projects from the shell “Build your .NET project with a right click in Windows Explorer”

Last week I changed to MSBuild Launch Pad (mPad) which also add a context menu when you right click your project or solution files.

The added value for me is that it maintained project, 1.0 was released on May 21, 2010 with following release notes:

• Support sln, csproj, vbproj, vcxproj, shfbproj, ccproj, oxygene and proj files execution.
• Basic settings such as Show Prompt, and Auto Hide are provided.
• MSBuild Shell Extension integration is achieved.

I also very much like that when I right click and say build I get the control on the .NET framework version I want to use and if it is a Release, Debug or what so ever.

Nice little productivity booster tool.

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.

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 !

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!