I have a solution with multiple projects. One project only needs to build if both two events, in the pre-build event, exit with error code 0.
So I thought I could do the following:
"C:\Path\To\Binary1.exe" & "C:\path\to\binary2.exe"
In my test scenario something goes wrong so Binary1.exe exits with a non-zero value. But visual studio goes on building the project anyway.
When I run the pre-build event commandline in cmd and echo %errorlevel% I see the exit code being non-zero.
When I only put
"C:\Path\To\Binary1.exe"
in the pre-build event, the build is stopped and en error is shown in the Error List window of Visual Studio.
I am definitely sure that Binary1.exe is exiting with a non-zero value as its also shows a messagebox prior to exit.
I can think of one solution. Binary1.exe calling Binary2.exe and exiting with a non-zero exit code when Binary2.exe exits with a non-zero exit code. But that is not really a flexible solution.
To summarize:
How can I run multiple pre-build events and stop buidling when one of the commands returns a non-zero value?
I think yuou can do as follows:
run command 1
if ERRORLEVEL 1 (
exit /b 1
)
run command 2
If the two projects are in the same solution, you can set the dependency in Visual studio.
Right-click on the solution in the solution explorer and choose "Project Dependencies".
Set the 'last' project to be depending on the first two. In this case Visual studio will build in the right order and will stop building if one of the dependencies fail to build.
(Visual Studio 2013)
Related
I have a simple post-build event to open Explorer. However, when I include this line, I always get an error, "exited with code 1" but Exporer opens to the folder specified.
How can I do this without reciving the error?
E.g., add the following line to a post-build event:
explorer C:\\aa
Add another line "exit /b 0". This will tell the command to exit with error code 0.
Thank you for the suggestions.
I managed to solve it by changing to:
start "" C:\aa
I have a Visual Studio 2019 project with a Post-Build-Event, that is calling an EXE file I have written in C#.
Post-Build event:
MyTool.exe "$(TargetPath)"
This EXE file is doing some stuff and then calling another EXE file.
AnotherTool.exe SomeArguments
Problem is, if that second EXE file (AnotherTool.exe) gives an error (on StandardError output) or an exit code != 0, Visual Studio is "seeing" that codes, although the AnotherTool.exe is not called directly from the Post-Build event. The Post-Build just called the MyTool.exe.
I want MyTool.exe to handle that exit codes, so Visual Studio should ignore them. But the build fails, when AnotherTool.exe exits with an error.
Any ideas?
Edit: The "MyTool.exe" is calling the "AnotherTool.exe" using System.Diagnostics.Process. I set RedirectStandardOutput = true and RedirectStandardError = true, and then call the Process with Start() and WaitForExit().
But no matter what that process result is, MyTool.exe is always exiting with Environment.Exit(0) to give a clean exit.
Not an answer, but a Workaround that is working:
I created a batch file, that is calling:
start MyTool.exe %1
With this workaround, the build succeeds without error, and the tool chain is started correctly. I get no more error messages displayed in Visual Studio.
Trade off 1: The "MyTool.exe" is now displayed in a command window while running.
Trade off 2: If "MyTool.exe" fails with exit code != 0, Visual Studio won't notice.
If I remove the "start" from the batch, behaviour is like a direct call of MyTool.exe.
I have a solution with just echo Hello post-build event and it always fails with the message The command "echo Hello!" exited with code 1.
Has someone an idea what could go wrong?
More info:
we have a team with about 15 developers. It always fails just for 3 of them
we have all Windows 10 and VS2019
we have tried different scripts and ended up with the echo Hello
we have tried with the prod solution and with an empty one as well
Full error message:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\
Microsoft.Common.CurrentVersion.targets(1328,5):
error MSB3073: The command "echo Hello!" exited with code 1.
Edit
Just have compared the Microsoft.Common.targets file from a developer with working events to one with non-working events. They have the same content.
I don't have Visual Studio in front of me to test this, but the problem feels like ERRORLEVEL may sometimes (randomly?) be non-zero on entry to the post-build script.
The problem is that ECHO does not affect ERRORLEVEL:
dir FileThatDoesNotExist Gives "File not found".
echo %ERRORLEVEL% Prints "1" ... an error.
echo Hello Prints "Hello".
echo %ERRORLEVEL% Still prints "1".
Therefore, if error-level happens to be non-zero, it will not be reset by the ECHO command. (Neither, as far as I can see, does REM affect it). There may be other ways of doing so, but DIR . > nul seems to work for me in resetting ERRORLEVEL to zero (it should always be possible to run DIR on the current directory!). The redirect should stop the output appearing in the build-log.
Obviously, if there was an earlier command in the post-build script that had failed, you probably don't want to ignore it. However, the pattern you're seeing (some users fail, some work) suggests that for some reason, Visual Studio is sometimes launching the post-build script with a non-zero error-level: with an empty script, or only ECHO commands, this will end up as the "result" of the post-build stage and the problem you're seeing.
Adding DIR . > nul to the TOP of the script should ensure that the exit-code is reset (and will allow real failures later in the script to be detected).
So the problem was the username. We had some freelancers in our company and they got a username starting with some special character. I can't remember which one, but I guess underscore. So when the admin sorts users by their user name they are on the top.
Changing the username has solved the problem in all our cases -_-
I'm trying to launch a grunt process that will watch for .js file changes and transpile them into one file using grunt tasks. I can run it manually all day long, but I want to make it a pre-build so when a new dev gets the solution, building will launch the watcher. The problem (as you may have guessed) is that the grunt process stays running, so as a pre-build event, it never continues the build. I thought that using start would be asynchronous and would launch it without VS waiting on it to complete to continue the build, but I was mistaken. So, currently, my pre-build event is
cmd /c start $(SolutionDir)ProjectName.Web\run-grunt.cmd $(SolutionDir)
and run-grunt.cmd looks like
cd %1ProjectName.Web
grunt
This works but hangs until I close the cmd window which defeats the whole purpose. So, two questions:
Is this the wrong way to get this watcher kicked off?
Is there a way to structure these such that VS will launch the cmd and then resume the build without waiting for a return?
Have you tried setting your pre-build event to simply run a batch file that executes your current pre-build event? It seems like it will work because the batch file that Visual Studio executes will actually complete, leaving another command window in its wake.
I tested my theory with two batch files:
test1.bat
call "cmd /C start test2.bat"
echo test1
test2.bat
echo test2
pause
If you're still needing some parts of the grunt task to execute pre-build, you can break them out into separate tasks, so your pre-build event may end up looking like this:
cd $(SolutionDir)ProjectName.Web\
grunt build
grunt-watch.bat
I have a batch file that's being run in a Visual Studio custom build step to copy files into an install directory. I want it to error out properly when the copy fails. The problems with the options I have are:
exit 1This works within the build sequence fine, but sometimes I want to use the batch file from the command line or from within another batch, and in these cases the exit causes the caller to exit as well.
exit /b 1This works nicely from the command line or from another batch file, but Visual Studio doesn't recognize that the return code wasn't 0 (i.e. it reports the project having "0 error(s)").
I came across a link that provides me with a solution: http://www.nabble.com/Re:-bjam-and-Windows-p17457249.html
Essentially it says I have to echo an error message before doing the exit /b. For instance,
echo MyProj : error : could not copy files.
Does anyone know exactly what message format triggers Visual Studio to recognize an error?
I've tried tweaking this and some work and some don't. Seems it has to match something like
.*\: .*error.*\:
Is this documented anywhere?
Thanks.
This is with Visual Studio 2008 SP1 on Windows XP Pro SP3 (in case cmd.exe has differing behaviour between Windows versions).
Regarding your actual question,
This page specifies the full syntax expected by VS as the output of the build tools.
Another thing you can try is this:
set errorlevel=1
exit /b
This basically has the same effect as what #Bill suggests. The return value of the last program ran is set to the environment variable called %errorlevel% and then when you exit cmd.exe this is the value returned from the process (which is what VS reads)
Are you quite sure you're testing this correctly?
I've just tried this batch file:
echo bla
exit /b 1
with VS2008, as a pre-build step and got this:
1>------ Build started: Project: XXXX, Configuration: Debug Win32 ------
1>Performing Pre-Build Event...
1>bla
1>Project : error PRJ0002 : Error result 1 returned from 'C:\Windows\system32\cmd.exe'.
1>Build log was saved at "file://c:\XXXXX\BuildLog.htm"
1>XXXXX - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I've also tried this with a custom build step for a file with the same exact result.
It should be noted that I am used VS2008-SP1 so that might be the difference.
Generally, the return value of a batch file is the return value of the last command executed from within the batch file.
Exit should work, but if it doesn't, for whatever reason, you could always use a helper program to set your return value.
Back in the DOS days, you could use ECHO in combination with the CHOICE command to set your return value, but alas, it's no longer part of windows.
So you could write a small program instead. Something that takes the desired return value as an argument, then sets and returns that as the return value:
#include <cstdio>
int main(int argc, char * argv[]) {
if (argc == 2) {
return strtoul(argv[1], NULL, 10);
} else {
return 0;
}
}
Then in your batch file, you just call the program with the desired return value, and jump to the end.
For some reason the exit /b 12 doesn't set the exit code when written into the post build step. The regular exit 12 would work.
So to properly return exit code from your bat file, you should write this:
call yourbat.bat
if %errorlevel% NEQ 0 exit %errorlevel%
The call command is important when running bat files, it creates a new context the bat file running in so when you run exit /b 1 in the bat file, it will exit that context, not the whole command interpreter. Then you can compare the errorlevel and exit with that.