PowerShell gives you lots of options to log the output. For example you could collect the output in a variable and then do something about it like write it in a file or to the event log or whatever. You could also pipe the output to Tee-Object which will automatically write the output to a file and then send the output along the pipeline so that you could do something else with it, like showing it on the console.
But, in the case of MSBuild, I find all of the PowerShell options unnecessary as MSBuild has the ability to write to a log file (as well as the console) already built-in. The /fl and /flp arguments control how file logging works. My example lets MSBuild use the default log file name (MSBuild.log in the current working directory) but you could even configure the log file to generate by setting the LogFile property with /flp. The /fl and /flp arguments are actually very powerful as you can define up to 10 different log files to produce with different content in each (while still getting regular output on the console). See MSBuild /? for details on MSBuild's logging features as well as other possible command line arguments. PowerShell automatically puts the exit code in the $LASTEXITCODE variable. This is similar to how %ERRORLEVEL% contains the exit code in batch scripts. I would use $LASTEXITCODE rather than Start-Process. In my opinion, Start-Process, simply adds a layer of indirection that is unnecessary. In fact, I tried to say in my previous email that using a function or script to wrap MSBuild might already be a layer of indirection that is unnecessary depending on what your goal is. I find that a wrapper script is useful for command line usage where I want a specific type of invocation to occur every time. The script allows me to encapsulate MSBuild usage for developers that are less familiar with its capabilities. If I simply needed to call MSBuild as part of an existing build script that does other stuff as well as calling MSBuild, then I might just call MSBuild directly. I think KISS applies here quite a bit. For example, if I have a Solution.sln in the same directory as the automation script that I need to call without a lot of fluff and I know I need to call it with a single Configuration|Platform combo and I don't need anything special else special (because perhaps the CI server that calls my automation script already automatically captures my output) then I would simply use it like this: $ProjectPath = Join-Path -Path (Split-Path -Path $MyInvocation.MyCommand.Path) -ChildPath Solution.sln & $MSBuildCmd $ProjectPath /p:Configuration=Release /p:Platform=x86 /t:Rebuild If you can guarantee that MSBuild.exe will be in your PATH, then you can write it more simply like this: msbuild $ProjectPath /p:Configuration=Release /p:Platform=x86 /t:Rebuild I didn't enclose $ProjectPath in double quotes even though it might have spaces in it. PowerShell will automatically wrap it in double quotes when it passes the argument to MSBuild if necessary. This is another example of how people unnecessarily complicate their PowerShell scripts. In any case, questions about command invocation in PowerShell probably should be posted at http://www.powershellcommunity.com/Forums.aspx There are a lot of active members and they are very friendly. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail > -----Original Message----- > From: john.burak [mailto:john.bu...@telvent.com] > Sent: Friday, May 11, 2012 9:09 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] using wix with powershell > > As Edwin could have more tactfully pointed out, his script does have some > advantages over mine. Thanks, Edwin. Mine is intended to get you in the > right > direction, while his is more production ready except for one point: I still > suggesting using Start-Process to launch msbuild so that you can get the > return > code to see if it failed (and conveniently log the output). > > Things I would use from his script: > > - His msbuild args are in an array, which is nicer than the literal string in > mine. > - He reads a registry key to find msbuild which is less appropriate for a > quick > "how to" email, but better for production code. > - Parameter validation, if you want to be pedantic about it. > > -- > View this message in context: http://windows-installer-xml-wix- > toolset.687559.n2.nabble.com/using-wix-with-powershell- > tp7537541p7550930.html > Sent from the wix-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
