Lab49 Blog » MSBuild

How PowerShell can Automate Deployment to Multiple Windows Azure Environments

Doug Finke — Fri, 25 Feb 2011 14:04:56 +0000

The two blog posts below are providing insight into how to create an automated delivery pipeline to the Cloud, Microsoft Azure. I believe the same fundamentals can and ought be applied to the software development life cycle whether you have a hybrid or Enterprise model.

The first post is the updated SDK and PowerShell cmdlets for MSBuild and Azure.

The second is a walk through showing how to automatically build and deploy your Windows Azure applications to multiple accounts and use configuration transforms to modify your Service Definition and Service Configuration files.

Scott Densmore - Another Update for the Deployment scripts for Windows Azure
Tom Hollander – Using MSBuild to deploy to multiple Windows Azure environments

Note to self: How to programmatically get the MSBuild path in PowerShell

Doug Finke — Thu, 02 Dec 2010 02:01:14 +0000

Other ways I’ve seen have been to get the directory from the registry. I prefer this approach.

Function Get-MSBuild {
    $lib = [System.Runtime.InteropServices.RuntimeEnvironment]
    $rtd = $lib::GetRuntimeDirectory()
    Join-Path $rtd msbuild.exe
}

This gets the directory for the latest installed .NET runtime and joins it with msbuild.exe.

Usage

& (Get-MSBuild)            

Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

MSBUILD : error MSB1003: Specify a project or solution file.
The current working directory does not contain a project or solution file.

Build Visual Studio Projects on Remote Boxes Using PowerShell and MSBuild

Doug Finke — Thu, 21 Oct 2010 00:20:22 +0000

We are setting up a new Continuous Build server and as we tweak parameters, things happen. For example, false positives. The build worked on the server but fails locally.

As a sanity check and major time saver, this script runs MSBuild on a remote computer. You specify the name of the remote box and the Visual Studio solution path and filename.

Invoke-RemoteMSBuild ServerX G:\Build\Test.sln

No Fuss, No Muss

You run this script on your box, the MSBuild runs remotely. The MSBuild output is returned to your local box. No remoting in, no login, simple and easy.

Function Invoke-RemoteMSBuild {
    param (
        $computerName ,
        $vsSolution = $(throw "Please specify the solution file")
    )            

    Invoke-Command -ComputerName $computerName {
        param ($vsSolution)            

        $msbuildpath = "$($env:windir)\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
        & $msbuildpath $vsSolution            

    } -ArgumentList $vsSolution
}

You need to have PowerShell installed on both boxes, run Enable-PSRemoting on both boxes and you need to be in the admin group on the server.

Thanks to colleague Jason Dolinger who is quickly ramping up on PowerShell and asked if this could be done.

PowerShell and MSBuild Extensible Task Factories

Doug Finke — Sat, 20 Feb 2010 13:30:36 +0000

One of the cool new features of MSBuild 4.0 is the extensible task factory. Writing your own task factory will allow you to write inline tasks in Perl, Python, or in this case… Windows PowerShell.

Blog post MSBuild Task Factories: guest starring Windows Powershell.

Sample task factory on MSDN Code Gallery MSBuild Windows PowerShell Task Factory.

Top 5 Secrets of .Net Desktop Deployment Wizards

Administrator — Mon, 25 Aug 2008 03:45:00 +0000

Deployment is one of the software project taxes that are often neglected or shunted aside to have another team deal with.

There are two big downsides when a team does not directly own it’s deployment. The first is obvious, if the quality of the deployment infrastructure isn’t any good, users perception of your software will suffer. Rightfully so, any you find yourself spending time fixing bugs that are only tangential to your project.

The second risk has to do with how outsourcing (to another group, another department or other company) deployment infrastructure can affect your project. If the amount of time it takes to get a new deployment ready is more than an hour – you’ll find yourself adjusting the release schedule to accommodate this – typically in the direction of longer delays between releases. No need to rehash the downside of that.

Here are some tips to taking control of deployment.

Secret #1

To install to the desktop, use ClickOnce.

You no longer need to be dependent on the installation and packaging department.

The core ClickOnce technology continues to improve from its inception in .Net 2.0 – In .Net 3.5 SP1 ClickOnce has support for the reduced client profile, FireFox installs, and file type registration.

For enterprise environments there are a few things that you’ll need/want to do to make ClickOnce really work for you

The most important thing is having support for multiple environments – this isn’t built in, and if you attempt to deploy two different ClickOnce builds with the same deployment name to different sites, the latest build will take precedence and effectively overwrite the existing deployment on the desktop.

The fix for this is relatively straightforward – you need to provide different deployment name for each build. Like so -

The one limitation of this approach is that project references will no longer work. Use file based assembly refs, and it’ll be fine.

For a more polished look obtain a code signing certificate. Instead of getting an install dialog that says “Unknown publisher”, you can indicate the name of your group. It also make the auditors feel warm and fuzzy.

And finally, you can make your desktop software URL addressable. Even though most workflow software in the enterprise has moved to the web, the need for desktops software still exists, and often this desktop software can benefit by supporting URLs. And rather than telling your colleague how to navigate to what you’re looking at, or sending a screen shot of what you’re looking at, you could send them a URL – which would open up to the screen you’re using.

If you were installing the software via windows installer you could rely on modifying the registry and register a protocol handler. That approach won’t work for non-administrator ClickOnce installs, but you can work around that limitation by enabling “URL parameters to be passed to the application” (thanks to my co-worker Eugene for discovering this one)

Update – Cedric in the comments wonders if ClickOnce limits the application to a “.Net Sandbox?” In many ways, not really. In full trust mode, ClickOnce applications can run unmanaged code via pinvoke and Reg-Free COM. For applications that truly need unmanaged component installs you can use the setup bootstrapper, or if you are in an enterprise situation, install the core components separately from the application.

Secret #2

To get the server components and ClickOnce files to the deployment site, use WiX to prepare a Windows Installer packages.

Sure, you could use Visual Studio Setup Projects, or even shell out some real money for InstallShield or Wise software. But WiX has a number of nice features

cost
text (well xml) based files so you can do the decent diffs and source control on them
active community support
reasonable learning curve – start with everyone’s favorite WiX tutorial

Secret #3

Get your configuration files under control

Secret #4

Although WiX is great, sometimes installs just too difficult to be done in Windows Installer technology. In this case, use PowerShell.

If the install involves modifying xml files, executing database commands, or invoking web services and it’s well outside the normal range for windows installer. Read than trying to force everything into one technology, simply distribute a PowerShell setup scripts in the installer package. Run them from the msi or by hand afterwards.

Secret #5

Working on deployment can help your career.

It’s true. Responsibility and influence on a project naturally flow to those that get things done (not sure if it matter that you’re smart or not). Few things are a more visible indication getting things done then a release, and if you own deployment, other project items will naturally flow your way.

Dealing with the Configuration Nightmare

Administrator — Sun, 24 Aug 2008 22:00:00 +0000

Typically during an overview of some new technology they will say “and it’s totally configurable” at which point my inner sarcastic voice pipes up in response “great, now we have two problems”.

Configuration files are getting bigger and more complex. In some ways this is a good thing as there’s a move towards a declarative approach, but in other ways it’s unneeded as the cost of compilation has gone down. The real problems with the move towards configurable everything is the configuration files often lack designer support, and do not get verified at compile time.

I can’t help with the lack of designers or verification, but I do have some solutions for managing the proliferation of config files and multiple environments.

In a typical enterprise development project, you may have as many as five environments to execute against.

localDev – the PC you develop and unit test on
sharedDev – a shared environment with minimal expectations around quality
UAT/QA - a shared an environment with explicit quality expectations – typically this means that developers publish a list of known bugs to testers before the release and the new bugs discovered by testers will be addressed
Production – this system that users use
COB/DR – the backup system that users will use “in case of”

I’ve seen a number of approaches for dealing with configuration files and multiple environments

0. Edit the configuration file by hand right after you deploy.

If this approach works for you, then god bless. You can stop reading this post. On the other hand, if this turns your hair gray, or if you’re deploying technology has has tamper protection (such as ClickOnce), then keep reading

1. Put all environmental information into the single configuration file. Typically this approach it is combined with a UI addition allowing the user the option to select which environment to use.

This approach has some merits. Everything is in a single location, so it’s easy to find and maintain. On the other hand this approach makes it way too easy to run un-tested development code against a production environment, and doesn’t completely solve the configuration problem – and that it doesn’t tell a server component what environment it’s currently running in.

2. Keep 5 separate configuration files, one for each environment.

This approach looks the DRY principle in the eye, and says ” what are you going to do about it?” It’s fine if you’re feeling tough, and in the mood for a maintenance headache. For example if you add a new logging sink, you need to edit 5 files.

3. Treat your configuration files as code to be compiled

Benefits: no duplication of effort, automated, safe, unambiguous, auditable.

Cons: Takes about 1 developer day to setup.

Here’s how it works. The configuration files for each assembly are always kept in localDev configuration. A new file, call it Deployment.Properties is the added of root of the solution. For each assembly, a new file is applied called DeployTransforms.Properties is added.

The Deployment.Properties file is kept in MSBuild format and represents the golden definition of environment settings. It might look something like this


  accountsdev.company.com


      accountsUAT.company.com


      accounts.company.com


  Data Source='$(AccountsDBServer)';Integrated Security=True;

The DeployTransforms.Properties file, also kept in MSBuild format defines how the golden values from the Deployment.Properties are applied to the [App|Web].config file.

It might look like this:


  
    $(AccountsDBCS)

Of course you would add additional properties and config transforms as needed.

The final steps are to include into your project the DeployTransforms.Properties as well as a DeployTransforms target. That might look like this:

and ConfigTransform.targets




  
    DeployTransform;
    $(PublishDependsOn);
    RollbackConfigFile;
  

  
    NonClickOnceDeployTransform;
  

  App.config
  $(ConfigFile)

This approach is invoked via msbuild /t:Publish /p:deployEnv=(UAT|Prod…)

The outputs of the build are now configured for the intended environment.

SilverLight tests + PowerShell = Automated tests in MSBuild

Sergey Kogan — Mon, 26 May 2008 17:57:16 +0000

In this post I will only discuss the way to configure SilverLight unit tests to run completely automated from MSBuild, so that it can also be used as part of continuous integration setup.

SilverLight tests must run within an actual SilverLight plugin rather then .NET Framework. Fortunately, Microsoft provided a test framework and source code for the both SilverLight controls and unit tests.

It is great to get support for TDD for such a new technology as SilverLight 2.0 right from the start. However, it is not possible to run SL tests from MSBuild out of the box. But do not panic, there is an easy solution to thid using PowerShell. PowerShell allows you to use COM objects and fortunately IE comes with a COM API that we can take advantage of. Below is a PowerShell script that creates and redirects IE browser to the SL test page, re-formats the test result output and saves it as an html file. It also returns an exit code > 0 in case of test failures.

param($testURL, $outFile=”TestReport.html”, $visible=$true)

#Instanciate IE, set Visible mode (tests that interact with desktop will require $true to pass
#then navigate to the test page
$ie = new-object -com “InternetExplorer.Application”
$ie.Visible = $visible
$ie.Navigate($testURL)

#poll the content until test execution is complete.
#Note: using $ie.Busy won’t work, because it does not detect that SL application is still running.
#Furthermore, the SL application is running until you close the browser, even after all the tests complete
while (!($ie.Document.body.innerHTML -match “\[ Close \]“))
{
[System.Threading.Thread]::Sleep(100)
}

#Once the execution is complete, we can check the results
#and, thanks to artist rendition by D. Finke, display some shining colors!
$failure = $ie.Document.title -match “(\d*) failures”
if($failure) {Write-Host -NoNewline -ForegroundColor “red” “Failed $matches[1]“}
else {Write-Host -NoNewline -ForegroundColor “green” “Pass “}

#Heavy RegEx stuff to reformat the body HTML.
#The test results in the SL test framework are displayed as a narrow column on the right with some
#error messages wrapped into context pop-up or limited in width.
$regOpt = [System.Text.RegularExpressions.RegexOptions]
[regex]::Replace($ie.Document.body.innerHTML, ‘^.*

’, “”, $regOpt::Singleline) -ireplace “width: 324px”, “” -ireplace ‘’, ‘$1′ -ireplace ‘\w*$’, “” > “$outFile”

#return error code in case of failure so that MSBuild and other tools can detect it.
Write-Host $testUrl
$ie.Quit()
if ($failure) { exit 1 }

Now, after we have out PowerShell script we can call it from MSBuild and have a completely automated SL unit test setup.
Note: If you will be running it from a service, i.e. TeamCity build agent, you should enable the service to interact with desktop.

Below is a snippet from MSBuild configuration file that calls the SL unit tests via PowerShell. Also, you will need to set PowerShell execution policy to allow the script to run using Set-ExecutionPolicy cmdlet. Check google for available policies.

’0′” Text=”SL Unit Tests run failed with code $(ControlTestExitCode)”/>

Note: I am using IgnoreExitCode option to allow other tests/tasks to run in case ControlTestResults.html fails. If you do not need this, you can remove IgnoreExitCode and tag.
=>

MSBuild : Item Groups on the fly

Doug Finke — Sat, 28 Oct 2006 02:12:35 +0000

MSBuild is part of our continuous integration process. Syncing to Subversion’s latest changes is done using the SvnCheckout Task (MSBuild Community Tasks Project). The revision number is then captured.

Subsequent tasks create staging/deployment targets, based on the revision – C:\deployment\389. This approach allows us to quickly review a directory tree and locate releases by revision.

Automation Challenge

MSBuild Item Groups allow wild cards, for example **\*.* tells MSBuild to build a recursive list of all files in all subdirectories. The wrinkle is MSBuild resolves Item Groups when the script is loaded.

Our targets are created during the running of the script. So the directory contents cannot be resolved at load time.

The solution, create Item Groups on the fly with the CreateItem Task.

This creates a named Item Group RevisionedDistributionFolderFiles and resolves the target directory structure for use in later tasks.