Cumulative Custom Build Steps in Visual Studio

Question

Is it possible to have cumulative custom build steps in Visual Studio?

What I want to do is have a

if not exist "$(OutDir)" mkdir "$(OutDir)"

as a custom step for ALL configurations (current and possible future ones)

But for a specific configuration (say Deploy) I want to ADDITIONALLY do this

xcopy "$(ProjectDir)..\Resources" "$(OutDir)" /D /E /I /F /Y

Is this possible? I have tried adding a property sheet in Deploy with the xcopy command, but the All Configurations "custom build step" property (with the mkdir command) seems to completely overshadow the xcopy one!

Isn't OutDir created automatically by the build already? – stijn Mar 16 '17 at 08:49 — stijn, Mar 16 '17 at 08:49
@stijn Yeah, but I am using it as an example – Bill Kotsias Mar 16 '17 at 08:51 — Bill Kotsias, Mar 16 '17 at 08:51

score 1 · Answer 1 · answered Mar 16 '17 at 08:52

Alternative solution: you can easily have this functionality by using for instance

<Target Name="MyTarget" BeforeTargets="BscMake">
  <Exec Command="xcopy ..."/>
</Target>`

That will run right before BscMake, which is when a custom build step with default options also runs. Or you could also use AfterTargets="CustomBuildStep" to make it run after your CustomBuildStep, etc. Note this method also makes it easy to add more steps without interfering with others.

score 0 · Accepted Answer · edited May 23 '17 at 12:34

0

It seems that you need to have a %(Command) added at the end of EVERY commands list to make the commands inheritable.

Answer found here: https://stackoverflow.com/a/22749337/113718

Having to add an extra "command" feels very hackish, if there is another, better solution, please share.

edited May 23 '17 at 12:34

Community

1
1

answered Mar 16 '17 at 08:52

Bill Kotsias

3,258
6
33
60

There's not much hackish about this, it is just how one works with variables in msbuild: when declaring them again they get overwritten. Like in other languages if you say 'a = 1', then 'a=2', the latter declartion overrides the former. Why would you expect it to be '12' or '3' or whatever? So if you want to append, there's no other way than to reference the original value and add the new one to it. – stijn Mar 16 '17 at 08:56
@stijn You are right about how variables work, but one would expect *Commands* and command lines to not be interpreted as mere variables but rather as cumulative *lists*. Automagically. – Bill Kotsias Mar 16 '17 at 09:00
1

Ok but if that were the case then you woudn't be able to actually override them anymore. Unless they added another 'magic' way for that. So that's likely why the devs wanted to keep it simple and have one way which can achieve anything. – stijn Mar 16 '17 at 09:12
@Bill Kotsias, Since you have resolved this issue. Please mark your answer which is benefit to other communities who has the same problem. Thanks. – Leo Liu Mar 17 '17 at 08:57

Cumulative Custom Build Steps in Visual Studio

2 Answers2