On windows systems, certain dos commands don't have executables that can be explicitly called via NAnt's exec task. (I'm talking specifically about commands that are part of Command.com)
A complete list can be found here. While some of the more useful commands can be achieved with NAnt or NAntContrib tasks (copy, move, rename etc), some (such as 'type') cannot.
How can you execute these commands as part of a build? For example, using a wildcard, how can I easliy display the contents of a log file from an external command executed by my build (so that the external command's log file contents will become echoed into the build's log file)
Internal commands can be called using the exec task in the following manner :
<exec workingdir="${dir}" program="cmd" commandline="/c <command/> <arguments/>" />
For the scenario in the question (where the log's filename is based on the current time, partway through the build), rather than parsing/scanning for the filename, loading it into a property and then echoing it, you could echo log contents with the following task :
<exec program="cmd" workingdir="${dir}" commandline="/c type *.log" />
Related
I have a startup task for my webrole that download some executable file from a blob and then proceed to the installation.
From a .cmd file, I start a power shell script that download the files, then I start the file from the .cmd.
The script works fine if I run it manually through RDP after the publishing is done.
But, when running as startup script, it sometimes (often) fail at different points.
The taskType is set to background.
Last time, the error was that the command PowerShell does not exists...
Also, I use powershell -command set-executionpolicy unrestricted before running my PS script, but I read here that other task may reset this setting and make mine fail.
Quite a mess.
So that makes me think that if I could wait for all other task to perform before starting mine, it would eliminate these kinds of problems
I suppose I could check if some process is running and wait for it to finish, but I have no clue wich process to check.
Or maybe there's another solution.
~edit~
I read here that the error about powershell not existing may be caused by the batch file being saved as UTF-8 in visual studio. I re-writed it from scratch in notepad++ and made sure it is save as ANSI. Then, same error. The full message is :
'PowerShell' is not recognized as an internal or external command,
operable program or batch file.
Again, the script run perfectly from command line in remote desktop.
It would be possible to set an environment variable at the end of the script that is required to finish, then in the script which is awaiting the dependencies, loop until the environment variable is set, then kick off its activities.
You could also run everything from a single powershell script and use the '-asjob' switch on your installer statement, use the 'wait-job' cmdlet to block until the task is complete then carry on. Powershell also offers a '?!' operator which ensures the last statement executed properly.
This might be caused by an encoding issue. As mentioned in this answer you should save your file in ASCII to ensure correct interpretation of your script.
From the linked answer:
Open your whatever.cmd file with your VS 2012 Ultimate. Click on File->Save whatever.cmd as -> on the dialog there is little arrow next to the [save] button. It will show up a menu that will have the option Save with Encoding.
Select it. Now choose "US-ASCII Codepage 20127" from the list of available encodings.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any good PowerShell MSBuild tasks?
Powershell doesn't seem to have an easy way to trigger it with an arbitrary command and then bubble up parse and execution errors in a way that correctly interoperates with callers that are not PowerShell - e.g., cmd.exe, TeamCity etc.
My question is simple. What's the best way for me with OOTB MSBuild v4 and PowerShell v3 (open to suggestions-wouldnt rule out a suitably production ready MSBuild Task, but it would need to be a bit stronger than suggesting "it's easy - taking the PowerShell Task Factory sample and tweak it and/or becoming it's maintainer/parent") to run a command (either a small script segment, or (most commonly) an invocation of a .ps1 script.
I'm thinking it should be something normal like:
<Exec
IgnoreStandardErrorWarningFormat="true"
Command="PowerShell "$(ThingToDo)"" />
That sadly doesn't work:-
if ThingToDo fails to parse, it fails silently
if ThingToDo is a script invocation that doesn't exist, it fails
if you want to propagate an ERRORLEVEL based .cmd result, it gets hairy
if you want to embed " quotes in the ThingToDo, it won't work
So, what is the bullet proof way of running PowerShell from MSBuild supposed to be? Is there something I can PsGet to make everything OK?
You can use the following example:
<InvokeScript Condition="..."
PowerShellProperties="..."
ScriptFile="[PATH TO PS1 FILE]"
Function="[FUNCTION TO CALL IN PS1]"
Parameters="..."
RequiredOutputParams="...">
<!-- You can catch the output in an Item -->
<Output TaskParameter="OutputResults"
ItemName="Output" />
</InvokeScript>
This can be used in MSBuild.
Weeeeelll, you could use something long winded like this until you find a better way:-
<PropertyGroup>
<__PsInvokeCommand>powershell "Invoke-Command</__PsInvokeCommand>
<__BlockBegin>-ScriptBlock { $errorActionPreference='Stop';</__BlockBegin>
<__BlockEnd>; exit $LASTEXITCODE }</__BlockEnd>
<_PsCmdStart>$(__PsInvokeCommand) $(__BlockBegin)</PsCmdStart>
<_PsCmdEnd>$(__BlockEnd)"</PsCmdEnd>
</PropertyGroup>
And then 'all' you need to do is:
<Exec
IgnoreStandardErrorWarningFormat="true"
Command="$(_PsCmdStart)$(ThingToDo)$(_PsCmdEnd)" />
The single redeeming feature of this (other than trapping all error types I could think of), is that it works OOTB with any PowerShell version and any MSBuild version.
I'll get my coat.
We have a lot of existing batch files that help with the running of different perl and ruby scripts.
A batch file (e.g. test.bat) would normally be invoked like:
$ test
and within the batch file, it will set some settings and finally try to run the corresponding script file (e.g. test.pl) like this:
perl -S "%0.pl" %*
All works with cmd.exe, but today, I decided to switch to PowerShell and found out that it expands the commands. So trying to run "test" will actually run "Full\path\test.bat" and my script would complain that there is no file test.bat.pl.
Is there a way to prevent this command expansion? Rewriting all batch files is not an option.
One way is to call cmd explicitly:
cmd /c test
I'm trying to set an environment variable in a build script with phing.
This is normally done command line like this:
export MY_VAR=value
In Phing I did the following but it isn't working.
<exec command="export MY_VAR=value" />
I see that this is quite an old question, but I don't think it has been answered in the best way. If you wish to export a shell variable, for example say you are running phpunit from phing and want to do an export before invoking phpunit, try:
<exec command="export MY_VAR=value ; /path/to/phpunit" />
Simply do the export and invoke your command inside the same exec tag. Separate the export statement and the shell executable with a semicolon as shown. Your script will be able to access the value using the standard php function:
$myVar = getenv('MY_VAR');
Bold claim: There is no way to set/export a (Unix) shell variable in PHP so that it is visible inside the scope that started the php script.
php myfile.php (does putenv or shell_exec('export foo=bar');)
echo $foo
Will return nothing.
As PHP can not do it so neither can phing.
Accessing shell environment variables accross multiple script runs (if its that what you want) seems also like an unideal design decision, pretty stateful.
Apart from that I'd urge you to stick to phing and learn its lean lesson. Phing helps stateless thinking to some degree.
I'd never heard of phing before, but this looks very promising as a build tool. Thanks for posting! I looked through the doc on phing.info, I found the following possibility:
#0 I would like to clarify one point. Are you saying that
prompt$ > export MY_VAR=value
prompt$ > phing build.xml
doesn't set MY_VAR to value so it is visible inside the running phing processes? I'd be surprised, but I would understand if this is not how you want to run your build script.
#1 I think in the context of a build tool, a feature like exec is meant to run a stand-alone program, so, while the exec may run and set MY_VAR, this is all happening in a subprocess that disappears immediately as the exec finishes and continues processing the next task in the build.xml.
If you're just trying to ensure that your phing script runs with specific values for env_vars, you could try
Command-line arguments:
....
-D<property>=<value>
// Set the property to the specified value to be used in the buildfile
So presumably, you can do
phing -DMY_VAR=value build.xml
#2 did you consider using a properites file?
See http://www.phing.info/docs/guide/stable/chapters/appendixes/AppendixF-FileFormats.html
and scroll down for info on build.properties
#3 also ...
Phing Built-In Properties
Property Contents
env.* Environment variables, extracted from $_SERVER.
you would access them with something like
${env.MY_VAR}
#4 This looks closer to what you really want
<replacetokens>
<token key="BC_PATH" value="${top.builddir}/"/>
<token key="BC_PATH_USER" value="${top.builddir}/testsite/user/${lang}/"/>
</replacetokens>
I hope this helps.
We're in the process of evaluating MSBuild and Nant for deploys. We may roll our own tool. One thing that a different business unit -- let's call it DeptA -- would really like to have (as in it better have it) is the ability for someone in DeptA to read the script and see what it will do. Currently we do this with .bat files. We hates the bat files. Nasty nasty bat files's. But if we ask DeptA to learn a new script language (nant, msbuild) they may be resistant.
Ideally the build tool of choice would be able kick out a list of actions without doing anything else. Along the lines of:
Stop service ABC on server Z
Stop service DEF on server Z
Copy all files from
\server\dirA\dirB to \server2\dirC
Start service ABC on server Z
Start service DEF on server Z
Run all scripts in dir
\server\dirA\dirC
Is it possible to do this with MSBuild? NAnt? Without me re-learning XSL?
If I was you I would actually blend MSBuild and MSDeploy. You should have your MSBuild script perform the actions like start/stop service etc. Then let MSDeploy to the file copy. With MSDeploy you can use the -whatif switch to indicate that you only want a report of the actions to be executed instead of actually executing it. MSBuild unfortunately doesn't offer such an option out of the box you will have to "build" that into your scripts. You can do this with properties and conditions. For example it might look something like this:
<Project ...>
<PropertyGroup>
<!--
Create the property to use, and declare a default value.
Here I've defaulted this to true because it is better to force the
caller to explicitly specify when to perform the action instead of it
being the default.
-->
<SimulateExecution Condition= '$(SimulateExecution)'==''>true</SimulateExecution>
</PropertyGroup>
<Target Name="Deploy">
<Message Text="Deploy started" />
<Message Text="Stop service ABC on server Z"/>
<WindowsService ... Condition=" '$(SimulateExecution)'=='false' "/>
<Message Text="Stop service DEF on server Z"/>
<WindowsService ... Condition=" '$(SimulateExecution)'=='false' "/>
<!-- Call MSDeploy with the Exec task. -->
<PropertyGroup>
<MSDeployCommand>...\msdeploy.exe YOUR_OPTIONS_HERE</MSDeployCommand>
<!-- Append the -whatif to the command if this is just a simulation -->
<MSDeployCommand Condition= '$(SimulateExecution)'=='false' ">$(MSDeployCommand) -whatif</MSDeployCommand>
</PropertyGroup>
<Exec Command="$(MSDeployCommand)" />
... More things here
</Target>
</Project>
For the service actions you can use the WindowsService task from the MSBuild Extension Pack. You will have to fill in the blanks there.
When you call MSDeploy you should just use the Exec task to invoke msdeploy.exe with your parameters. If you pass the -whatif it will not actually perform the actions, just report what it would have done. These will be logged to the msbuild log. So if you invoke msbuild.exe with /fl you will get those actions written out to a file. The only issue that I've seen when taking this approach is that for msdeploy.exe you many times have to use full paths (those without ..) which can sometimes be tricky so be wary of such paths.