MSBuild

End-to-end WCF code coverage with PowerShell

Elton Stoneman — Fri, 14 Oct 2011 09:53:44 GMT

I'm a big fan of automated testing which actually proves something. Unit tests may prove all the components in a solution work independently, but that doesn't mean you have a working solution. Integration tests give you confidence in the whole solution, but the cost of having a test suite with a lot of external dependencies is the risk of false build failures and long-running test suites.

To get something in between, we have acceptance tests written in SpecFlow which run tests at the highest layer - targeting WCF services which are the external entry point to our solution. Michael Stephenson has blogged and given sessions on the power of BDD for unifying a project team's understanding of a feature, and being able to get code coverage based on features proves the solution works as expected through all scenarios. Acceptance tests use stubs for any external dependencies, so they run quickly and allow us to confidently assert that our solution works, provided the dependencies work as expected.

Getting coverage for a whole stack of .NET code running beneath the WCF layer is trickier than you might expect. There's no VS or MSBuild functionality for it, and you need to dig down to vsinstr and vspercmd. I've made it all as simple as possible with a generic PowerShell script you can call locally during development, and which runs as part of the MSBuild scripts on the server.

The script is on poshcode here: PowerShell script for running WCF code coverage against IIS.

Technically the script can be used to get coverage on any process which is hosted in IIS. The bulk of the work is done in functions in the script, the main block requires you to specify values for your own solution:

#--------------
# Script begins
#--------------

#set variables:
$solutionFriendlyName = 'XYZ'
$wakeUpServiceUrl = 'http://localhost/x.y.z/Service.svc '
$appPoolName = 'ap_XYZ'
$appPoolIdentity = 'domain\svc_user'
$websiteBinDirectory = 'C:\websites\xyz\x.y.z.Services\bin'
$coverageOutputPath = "Test.coverage"

#instrument assemblies:
# - instrument assembly so ALL namespaces are included in coverage
instrument "x.y.z.Services.dll"
# - instrument assembly so anything from the Ignore1 and Ignore2 namespaces are excluded from coverage
instrument "x.y.z.Core.dll" 'x.y.z.Core.Ignore1.*' , 'x.y.z.Core.Ignore2.*'

#instrument W3WP, run tests & export results:
start-instrumentation
& 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe' Build.proj /t:$msBuildTarget /p:ConfigurationName=$configurationName
stop-instrumentation
export-coverage

#------------
# Script ends
#------------

The sections highlighted in blue above need to be replaced with your own values:

solutionFriendlyName - just a friendly name which is used in logging output
wakeUpServiceUrl - any URL which is part of your solution. The script hits the URL to start an app pool which is can instrument for code coverage. Can be anything which fires up the worker process - .svc, .aspx etc.;
appPoolName - the name of the app pool your solution runs under. Ideally have a dedicated app pool as the covergae run stops and starts it, so if it's dedicated to the solution you won't impact anything else;
appPoolIdentity - the service account the app pool runs under. Used in setting up instrumentation;
websiteBinDirectory - path to the binaries you want to be instrumented, where the IIS site is running;
coverageOutputPath - specify what the coverage file will be called. Should have the .coverage extension;
instrument - add a line for every assembly you want to instrument. If the assembly contains just your code, you only need to name the assembly. If it contains generated code you don't want included (e.g. service reference or EF model code), specify each namespace to exclude after the assembly name. Syntax is important here - each namespace should be fully-specified up to the wildcard, quoted in single quotes, and multiple namespaces are comma-separated.

The script has some expectations which mean hardcoded values in the functions, so if your environment is different you'll need to look at those:

running on Windows Server (expects to instrument W3WP.exe)
VS2010 installed at default path
.NET 4 installed

In our build scripts, we have one target to run the tests, and another to run the tests with coverage. The PowerShell script calls back into the original MSBuild script to run the unit tests, so to incorporate the script into your build you need a target like this:

< Target Name = "AcceptanceTestsWithCoverage">

< Exec ContinueOnError = "true"Command='powershell.exe "$(MSBuildProjectDirectory)\RunCoverage.ps1 -msBuildTarget AcceptanceTests -configurationName $(ConfigurationName)"'WorkingDirectory='$(MSBuildProjectDirectory)' />

</ Target >

- passing the script the name of the MSBuild target to run to execute the tests.

The output from the script is a .coverage file which you can load into VS (note that if you rebuild after running coverage, the assemblies will not be instrumented and the coverage won't load correctly), and an XML export of the coverage (which you can roll up in your build scripts, or load into VS).

Using MSBuild 4.0 web.config Transformation to Generate Any Config File

EltonStoneman — Fri, 20 Aug 2010 12:06:32 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Web.config transformation is a simple and powerful inclusion in .NET 4.0 for generating configuration files for different environments. It's a templated match-and replace, and you can put together a homegrown alternative with T4 and some scripting, but the integrated experience is better. It's limited to web.config in Visual Studio, but with a simple MSBuild target you can leverage it for any config file.

The transform is based on your VS.NET solution configurations, so you can start by replacing the standard "Debug" and "Release" builds with custom configurations to suit your environment. Then run "Add config transformations" by right-clicking the web.config file and VS will generate stub files for each type of build:

The original Web.config file is the source file, and the .DEV, .TEST and .PROD versions are the transform files which contain the overrides needed for each environment. So your Web.config may define a database connection:

<add name="db1"

connectionString=" "

providerName="System.Data.SqlClient" />

</connectionStrings>

- and in Web.DEV.config you provide the connection string for the development environment and specify a matching pattern. In this case specify to match on the name attribute of the element, and all the other attributes you provide will replace those in the source (there are more complex transformations available):

<add name="db1"

connectionString="Data Source=.\SQLEXPRESS;Initiali Catalog=xyz;Integrated Security=SSPI;"

xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>

</connectionStrings>

Switch to the DEV build type, right-click the web project and select "Build Deployment Package" to generate a config file for dev which contains the transformed node with the connectionString attribute from the transform file and the providerName attribute from the source file:

<add name="db1"

connectionString="Data Source=.\SQLEXPRESS;Initiali Catalog=xyz;Integrated Security=SSPI;"

providerName="System.Data.SqlClient" />

</connectionStrings>

All straightforward, and the deployment package VS builds is used with the WebDeploy tool, and makes it all very simple. The actual config file will be created in obj\<Configuration>\TransformWebConfig\transformed. You can get the same result from MSBuild by building the solution file with the property DeployOnBuild=True.

The actual transform logic is all in the TransformXml MSBuild task from Microsoft.Web.Publishing.Tasks.dll. So you can utilise the same functionality for generating any config file with a simple MSBuild script:

<TransformXml Source="BTSNTSvc.exe.config"

Transform="BTSNTSvc.exe.$(Configuration).config"

Destination="$(BuildOutput)\BTSNTSvc.exe.config"/>

</Target>

You'll have to manually create the source and transform files for each environment, but you can maintain the naming convention so the pattern is consistent across your Web projects and other config targets. One thing the transform doesn't do is render the runtime value of MSBuild properties – so if you want to include the build version number in an attribute of the config file, then you'll need a custom step before calling TransformXml to parse the property values.

For application config files you can have this step in your build prior to creating MSIs, so that the MSI has the correct config values when deployed. For external configs – if you need to populate say machine.config or BTSNTSvc.exe.config – you can create the configs in the build and have a manual deploy step to overwrite the files, or if you're brave you could create an MSI which just contains the config files and overwrites the targets on install.

Note that Microsoft.Web.Publishing.Tasks.dll is part of VS 2010 and not part of MSBuild (default install location: C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\Web), so you will need to be licenced to use the assembly on your build server.

This is an excellent way to centralise all your environment variables in source control along with the project code, and removes the risk of manual config updates as part of deployment.

BizTalk Deployments with PowerShell

EltonStoneman — Wed, 10 Dec 2008 23:09:56 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

As part of my first look at ESB Guidance 2.0 (which has some excellent enhancements which I'll post about shortly) I've been interested in the way the sample solutions are deployed. The P&P team have put together PowerShell scripts which take care of the usual things you'd find in a deployment scenario – stopping services, creating applications, adding resources and bindings.

In a Continuous Integration environment, you'd typically want to deploy to a BizTalk instance as part of the build process, to ensure the application configuration is valid, and as a prerequisite for running unit and integration tests. Currently I do this with MSBuild scripts using a variety of community, Sdc and custom tasks, and command-line tools. It makes for fragmented scripts that are difficult to read and maintain, and can be fragile to execute.

In the PowerShell version a central script isolates the complexity for common functions, and then the individual install scripts use a neat, readable and hugely intuitive syntax. This is a complete install script for one of the sample solutions (MultipleWebServices_install.ps1), which builds and then deploys the artifacts:

$relativePath = "..\.."

$samplesPath = $solutionPath+"\Samples\MultipleWebServices"

. ..\..\..\..\Core\Install\Scripts\ESBFunctions.ps1

function BuildItinerarySolution

{

param([System.String] $buildType)

&$FrameworkPath"\v3.5\MSBuild.exe" $relativePath"\GlobalBank.ESB.Samples.MultipleWebServices.sln" /t:Rebuild /p:Configuration=$buildType

}

BuildItinerarySolution Debug

StopBTSApplication "Microsoft.Practices.ESB"

StopBTSApplication "GlobalBank.ESB"

StopBTSServices

ImportBTSResource "GlobalBank.ESB" "BizTalkAssembly" $relativePath"\Source\ESB.MultipleWebServices.Maps\bin\Debug\ESB.MultipleWebServices.Maps.dll"

ImportBTSResource "GlobalBank.ESB" "BizTalkAssembly" $relativePath"\Source\ESB.MultipleWebServices.Orchestrations\bin\Debug\ESB.MultipleWebServices.Orchestrations.dll"

GacOperation "-if" $relativePath"\Source\ESB.MultipleWebServices.Maps\bin\Debug\ESB.MultipleWebServices.Maps.dll"

GacOperation "-if" $relativePath"\Source\ESB.MultipleWebServices.Orchestrations\bin\Debug\ESB.MultipleWebServices.Orchestrations.dll"

ImportBinding "GlobalBank.ESB" $relativePath\Install\Binding\GlobalBank.ESB.MultipleWebServices_Bindings.xml

StartBTSApplication "Microsoft.Practices.ESB"

StartBTSApplication "GlobalBank.ESB"

StartBTSServices

The common script (ESBFunctions.ps1) defines the main functions – ImportBTSResource etc. – so the logic in the individual scripts is very clean. Common functions make use of PowerShell commands, the BizTalk Explorer OM, BTSTask and custom tools as appropriate, so there's still a variety of tools under the covers, but the common script is a facade over them all. This makes the install scripts neater and abstracts them from the actual implementation of the functions. Below are snippets for the functions to stop and to remove a BizTalk application:

function StopBTSApplication

{

param([string]$appName)

$exp = New-Object Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer

$exp.ConnectionString = $btsConnectionString

$app = $exp.Applications[$appName]

if($app -eq $null)

{

Write-Host "Application " $appName " not found" -fore Red

}

else

{

if($app.Status -ne 2)

{

#full stop of application

$null = $app.Stop(63)

$null = $exp.SaveChanges()

Write-Host "Stopped application: " $appName

}

function RemoveBTSApplication

{

param([string]$appName)

Write-Output "Removing BTS Application "+ $appName

BTSTask.exe RemoveApp /A:$appName

}

There's some complexity in these common functions, but they're all tried and tested by the Patterns & Practices team. This is a new approach for the ESB Guidance installs (v1.0 used a combination of batch files to deploy the samples), but I don't think there are any inherent dependencies on BTS 2009 so this approach and the common script should work for BTS 2006 solutions. I'm going to look at migrating my current build scripts to this approach as it's so much simpler to work with, and the execution doesn't rely on chaining together unrelated tasks in MSBuild.

The ESBG samples specifically name resources to deploy, whereas my current scripts run dynamically over whichever artifacts they find, but Bart De Smet has a nice MSBuild task for running PowerShell scripts, which takes parameters so that's one option, and generating PS scripts using the ExecuteT4Template task is another.

If I do get this running for BizTalk 2006 R2 solutions, I'll post a working set of sample scripts.

Creating Shortcuts in MSBuild

EltonStoneman — Fri, 24 Oct 2008 18:13:52 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Windows shortcuts are .LNK files – a proprietary binary format which is not simple to generate. If you want to create shortcuts as part of an MSBuild deployment, the main issue is that the paths are not relative, they need to be explicit, so you can't create your own shortcuts and copy them. Alternatives are to create .URL or batch files containing relative paths, but they don't have the niceties of shortcuts.

You can generate .LNK shortcuts in MSBuild by shelling out to some VBScript at runtime, when you've deployed your files and know the exact paths. It's not a pretty solution, but it's fast and reliable. Create a .VBS file with the following content to generate a shortcut from given parameters:

'CreateShortcut.vbs

'Generates a .LNK shortcut to the specified program

'Usage: CreateShortcut.vbs <pathToExe> <exeName> <shortcutName>

Dim args, arg

Set args = WScript.Arguments

Dim workingDirectory, exeName, shortcutName

workingDirectory=args(0)

exeName=args(1)

shortcutName=args(2)

Dim WshShell

Set WshShell = WScript.CreateObject("WScript.Shell")

Dim objLink

Set objLink = WshShell.CreateShortcut("Shortcuts\" & shortcutName & ".lnk")

objLink.Description = shortcutName

objLink.TargetPath = workingDirectory & "\" & exeName

objLink.WindowStyle = 1

objLink.WorkingDirectory = workingDirectory

objLink.Save

Then call it from MSBuild after you've deployed the target file and know the path:

Points to note:

If you have any spaces in the arguments (C:\Program Files\etc) you need to wrap them in triple double-quotes ("""C:\Program Files\etc"""), otherwise each word is parsed as a separate argument in VBScript;
The friendly name of the shortcut can end in any extension – Windows hides the final .LNK , so if you specify a .EXE it will display as an EXE;
Shortcuts aren't limited to executables, if you pass a Word file as the exeName argument and end the shortcutName with .DOC, it'll launch the document in Word and show it with the Word icon in Explorer;
You have a lot of control over the link from the CreateShortcut call – including the startup window type, arguments and the icon. The example above is a straightforward one which just sets the minimum necessary.

ExecuteT4Template MSBuild task: Updated

EltonStoneman — Sat, 04 Oct 2008 08:14:31 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

As Cory pointed out, my original task to execute T4 templates under MSBuild (replacing property markers in the T4 script with evaluated values from the build, see: An MSBuild task to execute T4 templates), fails under MSBuild 3.5. This is down to a change in the object model in the framework. All the useful classes are internal and all the useful properties are private, so they have to be reflected over - which makes my code brittle.

I've updated the task as part of a set here: Sixeyed MSBuild tasks, and it now works with either MSBuild 2.0 or 3.5.

Another update will be coming soon, to allow you to use named item group values, as well as property values and whole item groups in the script. A script can be marked with %(Collection.Identity) and when the task is called iteratively over a collection, the script will be populated with the current collection value each time. I'm also planning to change it to use the T4 engine directly rather than invoking the TextTransform console app, to hopefully speed up the execution time.

I'm using this task increasingly in builds now. It's a lot neater than having multiple XML or Regex file updates, and the template can be used to isolate logic so the builds stay clean. Currently it's used to dynamically generate Wix scripts, generate BizTalk bindings file for a set of environments, generate documentation projects for Sandcastle Help File Builder and produce config files for running DevPartner code coverage. Some of those templates may be generically useful, so I'll add them to MSDN when I get to the next update.

Installing PDB files to the GAC with MSBuild

EltonStoneman — Wed, 17 Sep 2008 20:55:01 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

There are a couple of reasons why you might want PDB files available in the GAC, say if you're running coverage reports over unit tests as part of your CI build, and the assemblies being instrumented all live in the GAC, or if you want to deploy BizTalk PDB files as a troubleshooting aid. Patrick Cauldwell has a PowerShell script to install PDBs to the GAC, which is a good basis for an MSBuild task to do the same.

The principle is straightforward – find the "hidden" GAC directory where it the assembly is deployed and copy the PDB file there. Danger here is that the GAC structure may change, so the task uses AssemblyName.CodeBase which gives you the full path to the physical location, rather than determining it from the current format.

The main work is done here:

string pdbFilename = string.Format("{0}.pdb", Path.GetFileNameWithoutExtension(this.AssemblyPath));

string pdbPath = Path.Combine(Path.GetDirectoryName(this.AssemblyPath), pdbFilename);

//if source PDB is found:

if (File.Exists(pdbPath))

{

//get the strong name info from the assembly:

AssemblyName gacAssemblyName = Assembly.LoadFile(this.AssemblyPath).GetName();

string gacPath = this.GetGacPhysicalLocation(gacAssemblyName);

//if GAC location found:

if (!string.IsNullOrEmpty(gacPath))

{

//copy PDB file:

try

{

File.Copy(pdbPath, Path.Combine(gacPath, pdbFilename));

Log.LogMessage("Added PDB file to GAC: {0}, location: {1}", pdbFilename, gacPath);

}

//log other conditions...

Where AssemblyPath is the path to the un-GACd assembly where the PDB file is expected to be found (e.g. the build output directory):

</Target>

Full source code is here: MSBuild Task to Deploy PDB Files to GAC

Running BizTalkDocumenter under MSBuild

EltonStoneman — Tue, 09 Sep 2008 18:30:33 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

The BizTalkDocumenter tool on CodePlex is great for generating help files describing your BizTalk application. It runs under the command line as well as having a Windows UI, but it's missing a command-line option for specifying a single BizTalk application to document (it defaults to documenting the whole BizTalk estate on the server).

If you want to document a single BizTalk application as part of your MSBuild process, two small modifications are needed to the class Microsoft.Sdc.BizTalkDocumenter.Form1:

ProcessArgs() – add a new case to the switch statement (before the default is processed):

case "/app":

case "/application":

documenter.Applications.Clear();

documenter.Applications.Add(argValue.ToString());

documenter.IncludeReferences = true;

documenter.PublishType = PublishType.SpecificApplication;

break;
GenerateDocumentation() – modify to use the default (CHM) publisher if none is specified:

if (executionMode == ExecutionMode.Interactive)

{

documenter.Publisher = DeterminePublisher(this.comboBox1.SelectedItem.ToString());

}

else if (documenter.Publisher == null)

{

documenter.Publisher = DeterminePublisher("Compiled Help");

}

To call in MSBuild, use the following target (specify "show" as false, otherwise it defaults to true and the help file will be displayed on the build server):

<Exec Command="$(BizTalkDocumenterPath)\Microsoft.Sdc.BizTalkDocumenter.exe

/o:$(PublishDocumentDir) /t:TheApplication /app:TheApplication /show:false"/>

</Target>

T4 template to generate Wix scripts to generate WCF MSIs in MSBuild

EltonStoneman — Thu, 04 Sep 2008 13:55:11 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Snappy title. We have a project which contains lots of WCF Service projects, and we want to generate MSIs so we can deploy them to IIS. The gaps between the projects are minimal as they all use the same structure, so instead of having separate Setup or Wix files in each of the solutions, generating the WXS files on the fly was an option.

The installer steps we wanted were reasonably simple:

install WCF artifacts to the chosen directory (.svc and web.config files)
install WCF binaries to the chosen directory\bin
install dependencies to the GAC
create a virtual directory in IIS pointing to the install directory

The only UI we particularly needed was the choice of install directory, so the Wix for this fits into a fairly straightforward T4 template:

<#@ template language="C#" #>

<#@ output extension=".xml" #>

<#@ assembly name="System.dll" #>

<#@ import namespace="System.IO" #>

<#@ import namespace="System.Security.Cryptography" #>

<#@ import namespace="System.Text" #>

<?xml version="1.0" encoding="UTF-8"?>

<Product Id="<#= this.GetProductId() #>"

Name="<#= ServiceName #>"

Language="1033"

Version="<#= VersionNumber #>"

Manufacturer="Company"

UpgradeCode="<#= this.GetUpgradeCode() #>">

<Media Id="1" Cabinet="<#= ServiceName #>.Install.cab" EmbedCab="yes" />

<# foreach (string filePath in this.WcfArtifacts.Split(';'))

{

this.AddFile(filePath);

}#>

</Component>

<# int index = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<Component Id="GACComponent_<#= index++ #>" Guid="<#= this.GetNewGuid() #>" SharedDllRefCount="yes">

<# this.AddAssemblyToGAC(assemblyPath); #>

</Component>

<#}#>

<# this.AddAssembly(this.WcfAssembly); #>

</Component>

</Directory>

<iis:WebVirtualDir Id="WcfVirtualDir" Alias="<#= ServiceName.TrimEnd(".Wcf".ToCharArray()) #>" Directory="INSTALLLOCATION" WebSite="DefaultWebSite">

<iis:WebApplication Id="WcfApplication" Name="<#= ServiceName #>" />

</iis:WebVirtualDir>

</Component>

</Directory>

<iis:WebSite Id="DefaultWebSite" Description="Default Web Site">

<iis:WebAddress Id="AllUnassigned" Port="80" />

</iis:WebSite>

<Feature Id="ProductFeature" Title="<#= ServiceName #>" Level="1">

<# int i = 0;

foreach (string assemblyPath in this.WcfDependencies.Split(';'))

{#>

<# } #>

</Feature>

</Product>

</Wix>

<#+

private string ServiceName

{ get{ return "$(ProjectName).$(ProjectFilter)"; }}

private string VersionNumber

{ get{ return "$(Version)"; }}

private string WcfArtifacts

{ get{ return @"@(WcfArtifacts)"; }}

private string WcfAssembly

{ get{ return @"@(WcfAssembly)"; }}

private string WcfDependencies

{ get{ return @"@(WcfDependencies)"; }}

…

- the full template is here: WCF Service Wix template.

A couple of interesting things here – the Guids are generated from the name of the elements (see Generating Deterministic Guids), so multiple versions will have the same Guid and will operate as updates, provided the name of the service doesn't change; the tags for MSBuild properties in the template get resolved using the ExecuteT4Template MSBuild task; the GACd assemblies flag themselves as SharedDllRefCount so if you uninstall this package, the files will be left in the GAC if any other packages use them, but removed if this is the only package that uses them.

Another custom task is needed to resolve the dependencies of the WCF assembly (sample version here: MSBuild ResolveDependencies task), and the MSBuild snippet to run it together with the Wix commands looks like this:

<ResolveDependencies AssemblyList="@(WcfAssembly)"

Filter="$(CompanyName).$(ProductName)">

</ResolveDependencies>

</Target>

<ExecuteT4Template ToolPath="$(MSBuildProjectDirectory)\$(BuildBinDir)"

TemplatePath="$(TemplateRoot)\Services.Wcf.wxs.tt"

OutputPath="$(ArtefactWixDir)\$(ProductName).$(ProjectName).Wcf.wxs">

</ExecuteT4Template>

</Target>

- we store all the intermediate files (the T4 template with resolved property values, WXS and WIXOBJ files) to help with debugging.

An MSBuild Task to run C# code

EltonStoneman — Tue, 02 Sep 2008 21:31:21 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

MSBuild is lacking in handy functions. You can check if a path exists and list the contents of a directory, but everything else has to be achieved with a task. You often find yourself choosing between clumsily stringing together tasks or writing a custom task to perform a specific function – even a simple one.

Rather than putting together a function library, I've got one simple task which takes C# code as a parameter and executes it. The code can consist of one or more statements, can read the runtime values of properties or item groups in the build, and returns a string output (currently it expects last the code statement to be like return x.ToString()).

So if you want to prefix text to a property, get the ticks of the current time or get a valid temporary file name, you can do it like this:

</CodeExecutor>

</Target>

</CodeExecutor>

</Target>

</CodeExecutor>

</Target>

The task doesn't do anything complicated; it builds a class at runtime by injecting the code statements passed to it into a T4 template (as with the T4 task, in its current form it uses the TextTransform.exe tool), compiles it in memory with CodeDom and executes a static method which now contains the code statements.

You can pass it directives if your code uses anything more exotic than System, System.Collections.Generic etc, and give it the path to any existing assemblies the code needs to reference. I'll add it as part of a set of build tasks to CodePlex but until then the code for the task is here: MSBuild CodeExecutor task.

Wix error -532459699

EltonStoneman — Fri, 25 Jul 2008 14:43:14 GMT

[Source: http://geekswithblogs.net/EltonStoneman]

Running Wix 3.0.2420.0 I got an "object reference not set" and this error message when calling light.exe from an Exec MSBuild task:

The command ""..\bin\Wix\light" -out "c:\x\y\z\x.y.z.msi" "c:\x\y\z\x.y.z.wixobj" -ext WixIIsExtension -ext WixUiExtension -cultures:en-us" exited with code -532459699.

Annoyingly, I could run the exact same command in a command prompt immediately after the build failed, and it worked fine - and this error only happened on the build server and not on the dev boxes.

Before diving into it too much, I updated to the latest version of Wix (currently 3.0.4318.0) and the problem went away. So that solved that issue and just left me with "should we be using beta software even if it works for everything we need at the moment"…