I am calling an external nant script from another nant script like below.
<target name="doCreateBuild" depends="">
<nant buildfile="${project::get-base-directory()}\..\BuildScript\buildCreator.build" target="externaldoCreateBuild" />
</target>
The problem is the call to "doCreateBuild" seems to return immediately without waiting for its completion.
How to make the external scrip to run in the same process so as the call will return only after successful build creation.
Related
I have a problem about call external process from CGI C++.
I want to run a macro (*.xls file) from CGI code directly but it's not working. I just see the EXCEL.exe process existing in the task manager (CGI run on APACHE). When I have run it on the command line then it worked.
system("start excel \"C:\Temp\91a3e34f-e2e4-442f-af32-4a38bef95a8e\FrfmMod91a3e34f-e2e4-442f-af32-4a38bef95a8e.xls\"");
Does anybody help me?
i use the following way to execute it
system("net use * /del /yes");
but it gives the following
`'net' is not recognized as an internal or external command, operable program or batch file.`
but when i run the same command on the CMD it is executed successfully. as
You have these remote connections:
Z: \\x.x.x.x\x
Continuing will cancel the connections.
The command completed successfully.
The issue was of Environment Path add the Path "C:\Windows\System32" then it will execute properly and give the output correctly.
I am manually running tests from msbuild/tfsbuild by manually invoking mstest.exe but it is failing unexpectedly with error MSB3073 and ExitCode 1 when I am expecting 0.
I have this target that searches for all DLLs with a postfix of *UnitTests.DLL in the $(OutDir) folder. It builds up a commandline statement that is then executed:
<Target Name="RunUnitTests">
<CreateItem Include="$(OutDir)\*.UnitTests.dll"
AdditionalMetadata="TestContainerPrefix=/testcontainer:">
<Output TaskParameter="Include"
ItemName="UnitTestAssemblies" />
</CreateItem>
<Exec Timeout="120000"
Command=""$(VS110COMNTOOLS)..\IDE\mstest.exe" #(UnitTestAssemblies->'%(TestContainerPrefix)"%(FullPath)"',' ') /testsettings:"$(OutDir)..\..\Sources\mysettings.testsettings"" >
<Output TaskParameter="ExitCode" PropertyName="ExitCode"/>
</Exec>
<Error Condition=" '$(ExitCode)' != '0' And '$(ExitCode)' != '2'" Text="An error [$(ExitCode)] occurred running unit tests." />
<OnError ExecuteTargets="MarkBuildStepAsFailed" />
</Target>
I've added a Timeout property above because some googling suggested this but it didnt make a difference.
This gets equated in the buildlog file as below (quotes included) (the folders names I have changed but left spaces where relevant but they don't look too long):
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\..\IDE\mstest.exe" /testcontainer:"C:\b\someprojectfolder\anotherfolder\Binaries\..\..\debug\some.unittests.dll" /testsettings:"C:\b\someprojectfolder\anotherfolder\Sources\..\..\mysettings.testsettings"
The tests DO run on the build server as part of the build process (i.e. calling the target above) as I can see the test results folder get created on disk. All unit tests pass as expected. I can see the MSTest.exe console output in my build log as well (e.g. Starting execution, list of tests and results, the results file is listed etc)
Additionally I can RDC onto the build server as the build service account and manually run the commandline above using a CMD and it works. (the test results (*.trx) and folder are there).
They also work when I manually invoke the commandline above using CMD them on my local developer machine as myself. It creates the test results file and folders.
FYI We are using Visual Studio 2012 Ultimate on my local machine and installed on the build server as well.
FYI We are using TFS 2012 with an upgrade process definition
I've got a feeling its to do with the "parsing"/escaping of quotes and/or apostrophes or could it be the use of using ..\ in the paths?
I have checked the event log on the build server and it displays no errors/information. Is there any other logs I can check? or properties I can define to "see" the actual error code?
NOTE: I know I could use the <RunTest> style msbuild/tfs build syntaxbut I manual trigger these tests at a more convenient time in the build process
this wasnt to with do quotes or apostrophes in paths. My .testsettings file connects to a remote test controller (on another server running Windows Server 2008 R2). I was collecting all data and diagnostics (video recorder etc, network emulation, event log, system diagnostics etc)
When I checked the event log on the test controller/agent server it was full of errors saying MSTest had to be run as administrative permissions. Thats what i am now investigating.
I'm working on implementing a self-updater for a daemon on OS X. The update is published as a .pkg file, so what I'm trying to do is as follows:
When the daemon is notified that an update is available, it calls installer via the system() call to install the package. The package contains a newer version of the daemon, a preupgrade script that stops the daemon (launchctl unload /Library/LaunchDaemons/foo.plist), and a postflight script that starts it back up after the new version is installed. The problem I'm having is that the installer process is quitting prematurely. I suspect that it may be because the installer kills its parent process in order to update it, and then gets killed itself instead of continuing as its own orphan process. I've tried the following with no luck:
Postpending the installer command with '&' to run it in the
background
Wrapping the installer command with nohup
The install command completes consistently without error when I run it from the command line, and fails consistently when run from the installer. When called from the installer, I'm piping the output to a file, and sometimes it has nothing, and sometimes it shows the install getting to about 41% completion before output stops. Any ideas on how I can figure out what's happening to the process or make sure it stays alive without its parent?
When you call launchctl unload, it kills the entire process group (unlike a simple kill). You want to move your subprocess into a separate process group. The easiest way is with the C call setsid().
If you're in the middle of a shell script, you should look at the following approaches. I haven't tried these since I was dealing with a C program and could setsid():
Prior to calling the installer, use set -m. This is supposed to turn on monitor mode, which says "Background processes run in a separate process group and a line containing their exit status is printed upon their completion."
Try this sub-interative shell trick: New process group in shell script
I am trying to execute a NAnt build script, which is perfectly working in one environment, but recently I have migrated my Build files to a new machine where I am facing the below issue.
NAnt Code Used :
exec program="cmd" commandline="/c ${build.dir}\XXX.vbs ${build.version}" failonerror="false"
NAne Error received
External Program Failed: cmd (return code was 1)
My Possible tries to overcome this
I have checked the environment variables and found that all are fine and also compared with the old machine to match the same.
Any solutions / comments ??
It seems "cmd" is running and you don't need to provide the full path. The error "External Program Failed: cmd (return code was 1)" means the 'cmd' ran but it produced an error. In other words your VB script (i.e. 'XXX.vbs') is failing. Try the following to find the actual error:
Validate that the expanded value of "${build.dir}\XXX.vbs" is a valid file/location. Double check your working directory if you're working with relative paths.
<echo message="${build.dir}\XXX.vbs" />
or
<echo message="${file::exists(build.dir + '\XXX.vbs')}" />
Run your NAnt script from the command line. This will give you a better error message, like a popup error from Windows Script Host.
C:\YourTools\NAnt.exe -buildfile:MyBuildScript.build
Avoid the command window, redirect the program's output. Append " >> exec.log" to your commandline string in the 'exec' task, then check the contents of the output/log file (i.e. 'exec.log').
<exec program="cmd" commandline="/c ${build.dir}\XXX.vbs ${build.version} >> xxx_exec.log" failonerror="false" />
Alternatively, a better way to use the 'exec' task is to use nested 'arg' elements. This would help in the case that your arguments have spaces in them; and your script will read clearer:
<exec program="cmd" failonerror="false">
<arg value="/c" />
<arg value="${build.dir}\XXX.vbs" />
<arg value="${build.version}" />
</exec>
Lastly, in the case your VB script is failing because of invalid arguments (maybe because of spaces in '${build.version}'), use something like the following to debug the VB script:
WScript.echo "Argument count", wscript.arguments.count
For i = 0 to wscript.arguments.count - 1
Wscript.Echo wscript.arguments.item(i)
Next
Hope this helps.