I need to call MSTEST.exe passing arguments as "elevated/admin" from an account which is not an admin, and cannot be. I have created a short cut for MSTest.exe called "MSTest_Elevated.lnk". I can call this and pass parameters via command line and everything works fine, see below:
REM Set up test executable variables
REM SET MSTEST_EXECUTABLE="C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe"
SET MSTEST_EXECUTABLE="C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\MSTest_Elevated.lnk"
SET NUNIT_EXECUTABLE="C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe"
CD %WORKSPACE%
SET WORKSPACE_TEST_RESULTS=%WORKSPACE%\TestResults_Integration
REM Create test result folder
IF NOT EXIST "%WORKSPACE_TEST_RESULTS%\" ECHO "Creating %WORKSPACE_TEST_RESULTS%"
IF EXIST "%WORKSPACE_TEST_RESULTS%\" ECHO "%WORKSPACE_TEST_RESULTS% EXISTS"
IF NOT EXIST "%WORKSPACE_TEST_RESULTS%\" md "%WORKSPACE_TEST_RESULTS%"
REM Run the tests
%MSTEST_EXECUTABLE% /resultsfile:"MyServiceTestsResults.trx" /testcontainer:"MyService\Test\Unit\MyServiceTests\bin\Release\MyServiceTests.dll" /nologo
REM Clear up test executable variables
SET MSTEST_EXECUTABLE=
SET NUNIT_EXECUTABLE=
However my solution cannot use command line and needs to use PowerShell. I can call MSTEST from PowerShell like so, but not as admin. It also fails if I try and call the elevated shortcut.
Execute-Command -commandTitle "MSTest" -commandPath "`"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\mstest.exe`"" -commandArguments "/xml:`"MyServiceTestsResults.trx`" `"MyService\Test\Unit\MyServiceTests\bin\Release\MyServiceTests.dll`" /nologo ";
The shortcut seems to run without failing but MSTEST does not get called. So...
Is there a way to call MSTest.exe via the elevated shortcut, with parameters in the same way in PowerShell as I can from call it from a BAT file?
Related
I created a freestyle job in Jenkins that I just set up (latest version).
I added parameters to it. One of those is a Options selection for ReleaseType with the options of Staging and Release.
One of the build steps is executing a remote command on the server when the site is uploaded to. It uses the Execute Windows Batch Command build step.
Here is the command line (with things made generic):
sexec myuser#mysite.com -pw=mypassword -cmd="PowerShell -Command ""C:\batch\bvCopyFast.ps1 C:\inetpub\mysite${ReleaseType}\siteLoad C:\inetpub\mysite${ReleaseType}\site""
Basically I am executing a powershell command that uses Robocopy to copy the files from the upload folder to the actual release folder for the site.
As you can see I need to have the ${ReleaseType} replaced with the actual value. The problem is that when this gets executed it isn't doing the substitution. I just uses that literal value in the command and that doesn't work.
If you use the -Command parameter it implies you are going to write raw PowerShell code in between the quotation marks that follow (allow you can call a script as you have).
PowerShell -Command "Get-Date; pause;"
To call a PowerShell script file you should use:
PowerShell -File "Your-Script.ps1 -Parameter1 Argument1 -Parameter2 Argument2"
https://learn.microsoft.com/en-us/powershell/scripting/components/console/powershell.exe-command-line-help?view=powershell-6
I would write a PowerShell script that accepted your root path and the releaseType as arguments and execute that.
Param($rootPath,$releaseType)
{
robocopy "$($rootPath)\$($releaseType)\siteLoad" "$($rootPath)\$($releaseType)\site"
}
I have never used Jenkins so I hope this works as I expect it to!
sexec myuser#mysite.com -pw=mypassword -cmd=""PowerShell -File 'C:\batch\newScript.ps1' -RootPath 'c:\inetpub\mysite' -ReleaseType {ReleaseType}""
So, I want to make a script that will execute 2 .bat files and start some .exe files.
However, the .bat files are supposed to keep running.
I have something like this :
pushd tools\wamp64
start wampmanager.exe
pushd ..\..\server\login
call startLoginServer.bat
pushd ..\test
call startTestServer.bat
start "C:\DEV\P2\Test\client" P2.bin
The problem is that call startLoginServer.bat will not exit and therefore, I'm stucked here.
How can I run my 2 .bat files and let them keep running.
(Ideally, I want them to run in 2 different command prompt windows)
Also, there is probably a better way to handle relative path than using pushd if you can correct me on this.
Thanks
You could use:
start "Wamp Manager" /B /D "%~dp0tools\wamp64" wampmanager.exe
start "Login Server" /B /D "%~dp0server\login" startLoginServer.bat
start "Test Server" /B /D "%~dp0server\test" startTestServer.bat
start "Text Client" /B /D "%~dp0" "C:\DEV\P2\Test\client.exe" P2.bin
Run in a command prompt window start /? for help on this command explaining the options.
"..." ... title for new console window which is optional, but must be often specified on program to start is or must be enclosed in double quotes. The START command in last command line in batch file code in question interprets C:\DEV\P2\Test\client as window title. It is also possible to use an empty window title, i.e. "" which is best if the started application is a Windows GUI application on which no console window is opened at all.
/B ... run without opening a new window, i.e. in "background". This option can be omitted to see what the started applications and batch files output to console if the executables are not Windows GUI applications.
/D "..." or also /D"..." defines the directory to set first as current directory before running the command specified next. %~dp0 references the directory of the batch file containing these commands. This path always ends with a backslash. Therefore no backslash must be added on concatenating the directory of the batch file with a file or folder name or path.
Run in a command prompt window call /? for help on %~dp0 explaining how arguments of a batch file can be referenced from within a batch file.
See also the answer on How to call a batch file that is one level up from the current directory? explaining in total four different methods to call or run a batch file from within a batch file.
Finally read also the Microsoft documentations about the Windows kernel library function CreateProcess and the structure STARTUPINFO used by cmd.exe on every execution of an executable without or with usage of its internal command start. The options of start become more clear on having full knowledge about the kernel function and the structure used on Windows to run a program.
I am working on a script or batch file (or combo of the two) which imports an outlook prf file, then launches a new cmd.exe window runs a application specific program which when passed a server cluster name pulls in an outlook data file in the previously created outlook profile. So i have the vbs script that checks for the outlook profile if it doesn't exist it imports the prf. That's working fine, now the program i need to is called addiman.exe the server cluster name is gsiapp...the manual method is i launch a cmd windows and type "addiman gsiapp" i wish to automates this by calling it in a routine called :Filesite the below command has been unsuccessful, it launches a new cmd.exe window but doesn't run the command.
:ImportPRf
call cscript \\gsf1\Apps\Scripts\public\deployprf.vbs
GOTO :FileSite
:FileSite
start cmd.exe /c "c:\program files\interwoven\worksite\addiman.exe" GSIAPP
GOTO :EXIT
:Exit
Exit
start cmd.exe /c "c:\program files\interwoven\worksite\addiman.exe GSIAPP"
try this, because cmd.exe interprets the part between "" as comand and ignores the GSIAPP statement
wild guess. Try adding another call before the "start" - like this
:FileSite
call start cmd.exe /c "c:\program files\interwoven\worksite\addiman.exe" GSIAPP
problem solved, the full path isn't needed. just had to putt "addiman GSIAPP". Thanks everyone who provided suggestions.
I have a job in Hudson that builds on a Windows XP slave. I know that symlinks are not possible (directly) in Windows XP, and so I am trying to use junctions instead. I wrote a batch script:
#echo off
if "%1" == "" goto ERROR1
if "%2" == "" goto ERROR2
goto create
:create
echo Creating junction for %1 at %2
if exist %2 junction -q -d %2
md %2
junction -q %2 %1
goto :eof
:ERROR1
echo Source directory not specified
goto :eof
:ERROR2
echo Destination directory not specified
goto :eof
In my job, when I call this script, it hangs at the line echo Creating junction for %1 at %2. This is my Hudson "Execute Windows Batch Command":
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
copy C:\Data\Scripts\slink.bat .
call slink.bat C:\Data\3rdParty64 3rdParty
call slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core
...and this is the output:
C:\Data\Hudson\dev\workspace\Common_Windows\label\DFWW9202>call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
Setting environment for using Microsoft Visual Studio 2010 x64 tools.
1 file(s) copied.
Creating junction for C:\Data\3rdParty64 at 3rdParty
Any ideas? (if this is not the right site, please redirect..sorry and thanks!)
The best way to solve this is to: pass /accepteula command-line argument to the junction command.
eg:
junction -q %2 %1 /accepteula
This procedure did not work for me, but I did narrow down the real problem.
Some background: The very first time the "junction.exe" program is ever run by a user on a Windows machine, it throws up an End User License Agreement (EULA) with an Agree button. Once that user clicks on the "Agree" button, they can use the utility normally.
junction.exe was stalling for Hudson because the service was being run as "Default User", and "Default User" never clicked on the Agree button. This caused junction.exe to invisibly and indefinitely stall, waiting for that click, which of course will never arrive.
The way we fixed it was to configure the system to run the Hudson service as a well known account, instead of as Default User. Then we logged into the Windows machine as that account, ran junction.exe, clicked on the Agree button, then logged off.
junction.exe has worked nicely in Hudson ever since.
The other option is to move to Windows Server 2008. I'm told that version has the junction functionality in a new "mklink" utility that comes built into the OS itself, and does not have a EULA.
Never mind, found it if anyone else is looking - I changed the "call" to slink.bat to "start /B", and added full paths, so:
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
start /B C:\Data\Scripts\slink.bat C:\Data\3rdParty64 3rdParty
start /B C:\Data\Scripts\slink.bat slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core
I have an MSBuild script that I want to call from a PowerShell script as part of a deployment process. If I call the build script via a bat file all works well. If I do the exact same thing in PowerShell I get CS1668 error looking for wierd and wonderful paths that dont exist on my machine.
I know I am getting into the MSBuild script as these errors are occuring from within the MSBuild script targets (logging output is showing this).
The bat file and the PowerShell script reside in the same place, right next to the build script.
Errors:
error CS1668 : Warning as error :
Invalid search path 'C:\Program
Files\Microsoft Visual Studio
8\VC\AtlMfc\Lib' specified in 'LIB
environment variable' -- 'The system
cannot find the path specified. '
error CS1668 : Warning as error :
Invalid search path 'C:\Program
Files\Microsoft Visual Studio
8\VC\PlatformSDK\Lib' specified in
'LIB environment variable'-- 'The
system cannot find the path specified.
'
I have checked and neiter of these paths do NOT exist on my machine.
Why would running from PowerShell change what paths MSBuild look for?
Thanks in advance
RhysC
EDIT- adding in code: NB the name of the MSBuild script is AutomatedDebug.build
POWERSHELL SCRIPT:
#Begining of script
$CurrentPath = Split-Path (Split-Path $myinvocation.mycommand.path )
#Assign the Build script paths. 1 is for building and testsing, 1 is for deployment (to keep things clean)
$MSBuildScriptBuildAndTestPath = $CurrentPath + "\Tools\AutomatedDebug.build"
$MSBuildScriptDeployPath = $CurrentPath + "\Tools\Deploy.build"
#Run the automated build with tests
Write-Host "*** Run the automated build with tests ***"
C:\Windows\Microsoft.NET\Framework\v3.5\MSbuild.exe $MSBuildScriptBuildAndTestPath "/t:AllTests" "/l:FileLogger,Microsoft.Build.Engine;logfile=AllTests.log"
if($LastExitCode -ne 0)
{
throw "AllTests failed"
}
Write-Host "*** FINISHED: Run the automated build with tests ***"
Bat File
#C:\Windows\Microsoft.NET\Framework\v3.5\MSbuild.exe AutomatedDebug.build /t:AllTests /l:FileLogger,Microsoft.Build.Engine;logfile="AllTests.log"
#pause
enter code here
Ok, what is actually happening is that I have dowloaded the Powershell Community Extensions (http://pscx.codeplex.com) many moons ago and there is a Environment.VisualStudio2005.ps1 file in there that adds EnvVars that dont exist. This is (I assume) becuase i dont use VS2005. I have commmented this out and all is well. I have tried to look for the 2008 equivilent but dint have too much luck. To be honest i dont use powershell to its full potential so i doubt i even need the PSCX on my machine anyway.
Thanks guys for your help.
It is most likely due to how you are passing parameters into the MSBuild script. There are some key parameter parsing differences between CMD and PowerShell and by using a batch file, you are implicitly using CMD's parameter parsing engine to hand off the parameters to MSBuild. If you post the command line you're using, one of the PowerShell gurus here can probably help debug where the parameters are getting confused.
I am wondering, basically you get "Warning as error" here. You can either try turning off treating warnings as errors (I mean, having a lib path which doesn't exist doesn't sound that bad to me) or you'll let your scripts print out the respective environment variables (using echo %LIB% and $Env:LIB respectively) from the scripts and look for differences.
However, since the envvars for VS aren't set globally by default (that's why there are the three Visual Studio command prompts) you have to set all variables somewhere. If you're doing this within the scripts you may have a typo somewhere?