4

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.

Miroslav Mikus
  • 486
  • 4
  • 12
  • I've come across this problem occasionally and still don't really know what causes it! However, a sort of 'fix' that works (at least, most of the time) is simply to add a second line in the list of "Post Build" (or whatever) commands with something like "rem foo" (it's the **rem** that seems to do the trick - what comes after it is irrelevant). – Adrian Mole Dec 18 '19 at 10:53
  • Hey, thanks @AdrianMole, this trick does not work for me – Miroslav Mikus Dec 18 '19 at 14:50

2 Answers2

1

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).

TripeHound
  • 2,721
  • 23
  • 37
  • Thanks, I have tried `rem foo DIR . > nul echo Hello rem foo`. **[Here](https://gist.github.com/MiroslavMikus/77aa3ad4ede85396c82e3f5436751637)** is the build result as *secret* gist. Thank you in advice :) – Miroslav Mikus Dec 18 '19 at 14:51
  • Perhaps you are interested in this question: [What is the easiest way to reset ERRORLEVEL to zero?](https://stackoverflow.com/q/1113727) – aschipfl Dec 18 '19 at 20:00
1

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 -_-

Miroslav Mikus
  • 486
  • 4
  • 12