I'm running into an issue where a 'Execute Windows batch command' build step is failing to find PsExec.
To help narrow down the issue I've created a test project with the following build step:
C:\Windows\System32\PsExec /?
PsExec /?
C:\users\admin\Desktop\PsExec /?
Here are the results:
Building in workspace C:\SoveraHIMDEV-10.2.1
[SoveraHIMDEV-10.2.1] $ cmd /c call C:\Users\admin\AppData\Local\Temp\hudson9054484821341580808.bat
C:\SoveraHIMDEV-10.2.1>C:\Windows\System32\PsExec /?
'C:\Windows\System32\PsExec' is not recognized as an internal or external command,
operable program or batch file.
C:\SoveraHIMDEV-10.2.1>PsExec /?
'PsExec' is not recognized as an internal or external command,
operable program or batch file.
C:\SoveraHIMDEV-10.2.1>C:\users\admin\Desktop\PsExec /?
PsExec v2.0 - Execute processes remotely
Copyright (C) 2001-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
PsExec executes a program on a remote system, where remotely executed console
applications execute interactively.
As you can see, it runs from an absolute path to the desktop, but does not run when just using 'PsExec' or 'C:\Windows\System32\PsExec'. However, all three of these examples execute from the command line correctly.
I've added the PsExec executable to the Jenkins machine's C:\Windows\System32 folder. PsExec works when executing 'PsExec /?' from the command line, and Jenkins shows 'C:\Windows\System32' in its path configurations.
java.library.path:
C:\Program Files (x86)\Jenkins\jre\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\app\admin\product\11.1.0\client_1\bin;C:\Program Files (x86)\Windows Resource Kits\Tools\;C:\apache-maven-3.1.1\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Git\cmd;.
Environment Path:
C:\app\admin\product\11.1.0\client_1\bin;C:\Program Files (x86)\Windows Resource Kits\Tools\;C:\apache-maven-3.1.1\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Git\cmd
I'm able to run other executables from 'C:\Windows\System32'
What am I missing that stops Jenkins from finding PsExec?
It might be an issue of file system virtualization.
When you copy a file to C:\Windows\System32 it might only be visible for you, not for Jenkins. Copy it to the SysWOW64 folder instead.
Related
If you are getting this error than follow the following steps
When you install jenkin in C:\Program Files\Jenkins after that select the path for JRE
C:\Program Files\Java\jre1.8.0_221
and also remember the bit 64 and 32 beacuse if you select the path C:\Program Files (x86) than you fails to install the jenkins successfully
I try to run an MSBuild command to package an UWP application from an azure TFS build step.
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe" "C:\TFSagent\_work\1\s\MyProject.sln" /t:Build /p:Configuration=master /p:Platform=x86"
This command execute well when i log onto the remote VM agent and i just execute the command: package is created just fine as expected.
But when the command is executed via TFS Agent that runs as a service i got the following error :
2019-06-16T22:15:16.0141845Z C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2638,5): error APPX0002: Task 'ValidateAppxManifest' failed. Namespace prefix 'm' is not defined. [C:\TFSagent\_work\1\s\MyProject.vcxproj]
2019-06-16T22:15:16.0142853Z C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2638,5): error APPX0002: [C:\TFSagent\_work\1\s\MyProject.vcxproj]
2019-06-16T22:15:16.9689847Z C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2638,5): error MSB4018: The "ValidateAppxManifest" task failed unexpectedly. [C:\TFSagent\_work\1\s\MyProject.vcxproj]
2019-06-16T22:15:16.9690436Z C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2638,5): error MSB4018: System.Xml.XPath.XPathException: Namespace prefix 'm' is not defined. [C:\TFSagent\_work\1\s\MyProject.vcxproj]
...
Running: Microsoft Visual Studio Team Foundation Server Version 16.131.28507.4
Agent is setup as a service, on a windows 10 vm, using a local user, that is granted administrator rights.
Build Step is as simple as a command-line executing te above command.
I've tried adding /nodeReuse:false /m:1.
There is no use of any 'm' namespace in the corresponding manifest (and as it works when runnning 'by hand' i suppose the manifest itself is fine)
I just expect the command to work the same when running from a user or a service.
EDIT 1:
i may have found where the 'm' namespace comes from (when using /v:diag:
Task Parameter:
AppxManifestSchemas=
C:\Program Files (x86)\Windows Kits\10\\Include\10.0.18362.0\WinRT\FoundationManifestSchema.xsd
NamespaceAlias=m
NamespaceUri=http://schemas.microsoft.com/appx/manifest/foundation/windows10
C:\Program Files (x86)\Windows Kits\10\\Include\10.0.18362.0\WinRT\UapManifestSchema.xsd
NamespaceAlias=uap
NamespaceUri=http://schemas.microsoft.com/appx/manifest/uap/windows10 (TaskId:271)
EDIT 2
in the non working msbuild diag log, the parameter AppxManifestSchemas does not appear at all, probably explaining the intial error.
next step : finding why the parameter is not send to the task.
Solution found!
I had a Variable in my Build Definition named "SdkVersion" which was used to control the target sdk i wanted to build on.
This variable was used in my command line only.
Thing is, TFS is creating an environment variable for each variable in the build configuration.
During the MsBuild PRocess, and specifically task 'GetSdkPropertyValue' (task which is a dependecy for ValidateAppxManifest', which apparently add some AppxManifestSchema, including one with NamespaceAlias=m )
, there is a parameter named 'SDKVERSION' .. by default (when running manually) it takes the value '10.0' but as i had a variable with same name, it was overidde with '10.0.18362.0' which leads to adding no appxmanifestschema...
Took me a month :p
I created a batch file to run with Jenkins process,
When I run it in the CMD in the PC it runs fine,
but when I run it with the Jenkins as a flow, it's stuck, as you can see:
"Building in workspace C:\Program Files (x86)\Jenkins\jobs\TARD Testing\workspace
No emails were triggered.
[workspace] $ cmd /c call C:\WINDOWS\TEMP\hudson5135873889105585615.bat
C:\Program Files (x86)\Jenkins\jobs\TARD Testing\workspace>cd C:\Program Files (x86)\Jenkins\jobs\Buildscripts
C:\Program Files (x86)\Jenkins\jobs\Buildscripts>call DAR.bat
C:\Program Files (x86)\Jenkins\jobs\Buildscripts>ן»¿echo off
'ן»¿echo' is not recognized as an internal or external command,
operable program or batch file.
C:\Program Files (x86)\Jenkins\jobs\Buildscripts>C:\\EZcheck_ENV\\EZcheck_1_00\\test_engine.pyc
"C:\\EZcheck_ENV\\project\\login_script_dart.csv"
"C:\\Users\\alpha\\AppData\\Roaming\\DaRT\\results\\test_uzi_1.rst"
"C:\\Users\\alpha\\AppData\\Roaming\\DaRT\\variables"
"C:\\Users\\alpha\\AppData\\Roaming\\DaRT\\reports"
"C:\\Users\\alpha\\AppData\\Roaming\\DaRT\\temp" master
Someone told me that it's because I need to run the Jenkins process with user permissions,
Do you know how I do that or if that's even the problem..?
i am trying to execute devenv.exe through windows batch command plugin in Jenkins
but it keeps on executing and fails to launch the application.
Console Output :
**In progressConsole Output
Started by user anonymous
Building on master in workspace C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace
[workspace] $ cmd /c call C:\Windows\TEMP\hudson3900292017086958332.bat
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>set DEVPATH=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>set PATH=D:\app\nazopay\product\11.2.0\dbhome_1\bin;D:\app\nazopay\product\11.2.0\client_1;C:\Program Files (x86)\Integrity\IntegrityClient10\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\cde\tools;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Java\jdk1.6.0_23\bin\;C:\Program Files (x86)\Google\Chrome\Application;C:\MingW;C:\PROGRA~2\INTEGR~1\Toolkit\mksnt;%JAVA_HOME%;,;C:\Program Files\Java\jdk1.6.0_23;,;C:\Program Files\Java\jdk1.6.0_23\bin;%CLASS_PATH%;,;C:\Program Files\Java\jdk1.6.0_23\lib;,;C:\Program Files\Java\jdk1.6.0_23\lib;;C:\Program Files (x86)\M**icrosoft Visual Studio 10.0\Common7\IDE
C:\Program Files (x86)\Jenkins\jobs\TEMP\workspace>devenv.exe
You must execute devenv.com.
The devenv.exe always attempts to open GUI, even when commands are given, and it can't. The devenv.com has output directed to standard output and works fine from Jenkins.
You also must pass arguments.
Without arguments both devenv.com and devenv.exe just start the IDE GUI, which is not what you want. The correct command-line is
devenv.com projectname.sln /Build Release /Project projectname
First is path to the solution you want to build. Then the /Build flag is followed by configuration. If you have multiple platforms, you have to pass configuration and platform combination, e.g. Release|Win32. The /Project flag names project to build (including all dependencies). If omitted, it builds all projects selected for build in given configuration.
Why don't you use msbuild?
This would be a good starting point for your windows build script:
call "%VS100COMNTOOLS%\vsvars32.bat"
msbuild projectname.sln /target:Rebuild /l:FileLogger,Microsoft.Build.Engine;logfile=msbuild.log || goto error
goto end
:error
#echo ERROR: Build failed
exit/b 1
:end
exit/b 0
This way you can also capture the output log that you can parse with one of the jenkins plugins.
Ofcourse, adjust the VS100COMNTOOLS to your version of MSVS
I've configured the Jenkins MSTestRunner plugin to use the following path to the MSTest executable: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\mstest.exe'. However, although this path is correct, the build fails as follows:
cmd.exe /C "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\mstest.exe" "/resultsfile:/resultsfile testresults" /testcontainer:Project.Tests/bin/Debug/Project.Tests.dll && exit %%ERRORLEVEL%%
'C:\Program' is not recognized as an internal or external command, operable program or batch file.
What's the issue here, I thought this would be the normal way of configuring the MSTestRunner plugin as mstest.exe is installed beneath Visual Studio, which is again typically installed under 'C:\Program Files (X86)'? How do I work around this?
Have received confirmation from the plugin author that MSTestRunner 0.2.0 doesn't handle spaces in MSTest paths. I worked around the issue by instead creating an "Execute Windows batch command" build step in Jenkins that invokes mstest.exe directly, where I've surrounded the mstest.exe path with double quotes:
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe" /testcontainer:Project.Tests\bin\Debug\Project.Tests.dll /resultsfile:testresults.trx
Found that my issue was 2 fold.
File entries are from local workspace dir
You must configure mstest in global tools and then select that instance within the build step.