Close this search box.

Gotcha! Visual Studio Pre/Post-Build Events

Visual Studio has a nifty feature called Pre-Build and Post-Build events. These are used to include extra DOS commands before or after the build.

But there’s a gotcha! And it will bite you when you least expect it. In Visual Studio, there is NO ERROR CHECKING except at the end of an event. Any errors that happen prior to the final step are lost. Keep reading to see a workaround.

Setting Build Events

Build Events are accessed by right-clicking on a Project in the solution explorer and choosing “Build Events”:

It looks like these were originally intended as one-line DOS commands to do tweaks in your build. But they obviously grew – and you can put any number of DOS commands in there to copy files, clean up directories, even run unit tests!

Before describing the gotcha, there are a few things you need to know if you’ve never used these before. One is that you can put any DOS commands in here. It’s really nothing more than a place to save a batch file that’s run before (or after) the project build. It also offers “macros”. The build process actually creates a batch file from your commands by replacing the macro text.

In this example, MYDEPLOY is just a regular DOS environment variable. The advantage to macros is they take into account the various differences between developers (and their file directory structure) as well as handling Debug vs. Release builds.

For example, this command:

Copy $(OutDir)*.* %MYDEPLOY%

Gets converted to this, and placed in a batch file:

Copy bin\Debug\*.* %MYDEPLOY%

The Gotcha

So, what’s the problem?

Well, VS puts these commands in a batch file and runs it. VS checks for build failures so it can tell you about them. However – it only checks for a failure of the batch file that it created – not for any failures within the batch file.

What does this mean? If you only place one command in the build event, VS will correctly report any errors that happen. But if you place multiple commands in here, the net effect is that VS will only detect an error in the last statement.

So, for example, if you put three copy commands in here, VS will only report an error if the final command fails.


The Workaround

So how can we fix this? Since VS is just creating a batch file, we use normal batch file commands to detect errors and report them. Here’s what I do:

I add a check for error after every meaningful step:

if errorlevel 1 goto BuildEventFailed

I add code at the end to handle the error so VS will report it:

REM Exit properly because the build will not failREM unless the final step exits with an error codegoto BuildEventOK:BuildEventFailedecho POSTBUILDSTEP for $(ProjectName) FAILEDexit 1:BuildEventOKecho POSTBUILDSTEP for $(ProjectName) COMPLETED OK

Here’s an example of one of my actual post build events:

echo POSTBUILDSTEP for $(ProjectName) xcopy “$(TargetPath)” “$(SolutionDir)$(OutDir)” /i /d /yif errorlevel 1 goto BuildEventFailedxcopy “$(TargetDir)$(TargetName).pdb” “$(SolutionDir)$(OutDir)” /i /d /yif errorlevel 1 goto BuildEventFailed echo GAC of: “$(SolutionDir)$(OutDir)$(TargetFileName)”gacutil.exe /nologo /i “$(SolutionDir)$(OutDir)$(TargetFileName)” /fif errorlevel 1 goto BuildEventFailed REM Exit properly because the build will not fail REM unless the final step exits with an error codegoto BuildEventOK:BuildEventFailedecho POSTBUILDSTEP for $(ProjectName) FAILEDexit 1:BuildEventOKecho POSTBUILDSTEP for $(ProjectName) COMPLETED OK

You don’t have to be as fancy, with the extra “echo” statements, but do the error checking you need so errors don’t slip through the cracks.

One final note: don’t put too much in these events. They’re pretty hard to debug when things go wrong. If you have something complex to do, put the commands in a batch file and reference the batch file yourself in the event.

But now at least, you can get notified if (make that when) something fails.

Technorati tags: Visual StudioCodeGaffesGeekswithblogs

This article is part of the GWB Archives. Original Author: Dave Chesnutt

Related Posts