I'm trying to run a web app build process from Visual Studio and I got trouble running my scripts as the executable from the PATH config aren't included in the runned scripts.
Is there a way I can make sure the script is executed in a normal command line process? Or is there a way I can load these executable so they're available in the post/pre build script?
I'm using ruby and node.js in the build process (managed via Grunt). I can get Grunt to run easily by specifying the full absolute path, but then it fails when it tries to access Ruby commands.
So I found a solution working for me, I just launch the command in the cmd.exe process like so:
start cmd /C myCommand
With grunt, the full command can be this if someone is wondering:
start cmd /C %USERPROFILE%\AppData\Roaming\npm\grunt.cmd release --no-color > grunt_output.txt
Related
I use IntelliJ to launch a gradle build task for my project, but it seems that IntelliJ is using the command prompt (or cmd.exe) to launch the gradle wrapper, because during my build I'm getting the error:
'cp' is not recognized as an internal or external command,
operable program or batch file.
I have git bash installed, and running gradlew build from my bash shell succeeds without any such errors.
Is there a way to tell IntelliJ to use my bash executable to run gradle tasks rather than the default Windows cmd.exe?
I tried changing the default IntelliJ terminal (File->Settings->Terminal) from cmd.exe to my bash.exe, but that didn't work.
I solved this problem by first opening a Git Bash, and then running IntelliJ from there. The IntelliJ terminal is then automatically set to a Bash terminal, and all of the great Bash commands are available to Gradle.
If you want the Git Bash window to close automatically after starting IntelliJ, try running this command from PowerShell:
& git-bash.exe -c 'cmd //c start idea64.exe'
I use the Bash for Windows terminal in Intillij by setting the following as my default terminal.
cmd.exe "/K set LINES=9999&C:\windows\system32\bash.exe"
I recently started using the Windows Subsystem for Linux (WSL) to see if my Linux Makefile & arm-none-eabi-gcc based microcontroller project would build "natively" in Windows. To my surprise, the tool chain and Linux based development tools installed and worked perfectly on first go, without any modifications to the Makefile.
So that got me thinking to try doing all my code editing in Visual Studio using the IDE features while doing the actual build in the Linux & bash environment provided in WSL.
Unfortunately, when specifying a "Build Command Line" in the NMake options for my Visual Studio project, putting in "C:\Windows\System32\bash.exe build.sh" doesn't work because:
'C:\Windows\System32\bash.exe' is not recognized as an internal or external command,
operable program or batch file.
This is strange to me because I specified the full path and it couldn't find the WSL bash executable, and also attempting to add it as an "External Tool" doesn't seem to work because the executable doesn't show up in the selection window despite being able to see other executables in the same directory.
Some off topic opinion: If Microsoft can make Visual Studio and WSL work together seamlessly then I would likely switch from my Ubuntu virtual machine setup for a WSL based development environment.
Here's how you have to do it:
Nmake is not a 64-bit application, so when it tries to use Windows utilities and system32, WoW64 tricks it into looking in a different location.
The way you have to launch it from a 32-bit application is:
%windir%\sysnative\bash.exe
However, your command is also malformed. You will need to do it like this:
%windir%\sysnative\bash.exe -c "sh build.sh"
or maybe
%windir%\sysnative\bash.exe -c "./build.sh"
if DriveFS permissions allow execution.
otherwise it will attempt to execute build.sh as a command in your linux user's $PATH.
Source:
https://github.com/Microsoft/BashOnWindows/issues/870
This is what I have in my Build Command Line setting. It works fine.
start /WAIT %windir%\sysnative\bash.exe -c "cd /mnt/d/Projects/IoT/ESP8266/;./gen.sh -m DEBUG; read -n 1; exit;"
I'm trying to automatically download Nuget.exe from a Rakefile, in order to minimize the amount of initial setup needed to run my samples on GitHub.
I've understand how to download a file (I'm using HTTParty) and how to save a binary file (using the b flag on File.new) but now I've got problem running Nuget.exe. In particular:
if I launch it directly or from PowerShell, the executable runs fine;
if I launch it from cmd or from a Rakefile (which in turn runs cmd), Windows tells me that the program "stopped working".
I reproduced the same behavior with the Nuget bootstrapper, so I thought that the cause was some configuration in my computer.
It then occured to me that I installed ansicom, a library to handle ANSI sequences. I disabled it and then Nuget started without any problem.
I am trying to build a VS .sln that has multiple C++ .vcproj's in it. The solution file is generated using CMake and I've got this part working in Jenkins (with the CMake builder plugin). To build the solution file, I am using msbuild. I am able to build the solution using both Visual Studio and from the command line with the following command:
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" /t:Rebuild bin/SonIO.sln
This builds successfully (on the same machine that Jenkins resides).
However, I am trying to automate this portion of the build in Jenkins and the build ends up failing with a couple of C1083 errors ("Cannot open source file: '..\path\to\file.ext': No such file or directory). I have tried using both the Jenkins msbuild plugin and using the exact same command that works in the terminal as a "Execute Windows batch command" build step, with the same result.
When using the Windows batch command build step, I can see in the log that the command being executed:
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319 msbuild.exe" /t:Rebuild bin/SonIO.sln
... is exactly the same as the one that works from the command line, including the working directory.
I am running Jenkins as a service and I have the service logon as my account (with administrator privileges). Anyone know what directory Jenkins will execute batch commands out of?
Any ideas why I'm seeing this difference of behavior between Jenkins and the command line?
This is as much a workaround as a solution, but I ended up using devenv instead of msbuild and it works fine.
I know that this hints strongly as it being an environmental issue, but since it's not a problem to have VS installed on the build server, I decided to save the time that would be spent in the msbuild rabbit hole.
The environment being used by the account that the Jenkins slave agent is not the same environment as you use when doing the same command line from a prompt. Compare the two environments, note the difference, then add them to the Jenkins job.
To get the environment of the slave while running, have it do a "set" from a Windows Command Prompt
Without knowing much about VS build, it looks mostly like an environment setup.
My first advice would be to make sure, in Jenkins, you change directory to the same directory you ran the good command from and try it then.
Also, might want to try running Jenkins as a standalone app first.
And as a service, maybe allow service to "interact with desktop".
I may be late to the party, but I still ran into this problem on a new Jenkins setup on Server 2016.
My solution was to use the MSBUILD straight from the VS2017 installation C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin. No more errors.
I am using windows XP at my office and have set the development environment for building the embedded mobile projects of the company i am working for. I had set up the linux environment using cygwin but after that linux environment works fine, but the command line donot recognise the build commands(build mypath, build , build link) for my embedded projects. Is there any way to have both the environments working simultaneously ?
CMD or BAT file for fixing your PATH and other environment variable to match the target build environment.
cmd.exe can take a "/k" option to run your BAT file
Desktop shortcut to launch cmd.exe with the /k option start a command shell with the script that configures your environment.