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.

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. 

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.

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

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.

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:

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: