Visual Studio Post Build Event - Copy to Relative Directory Location

Question

On a successful build, I wish to copy the contents of the output directory to a different location under the same "base" folder. This parent folder is a relative part and can vary based on Source Control settings.

I have listed a few of the Macro values available to me ...

$(SolutionDir) = D:\GlobalDir\Version\AppName\Solution1\build

$(ProjectDir) = D:\GlobalDir\Version\AppName\Solution1\Version\ProjectA\

I want to copy the Output Dir contents to the following folder :

D:\GlobalDir\Version\AppName\Solution2\Project\Dependency

The base location "D:\GlobalDir\Version\AppName" needs to be fetched from one of the above macros. However, none of the macro values list only the parent location.

How do I extract only the base location for the post build copy command ?

Chesterton

Answer 1

If none of the TargetDir or other macros point to the right place, use the ".." directory to go backwards up the folder hierarchy.

ie. Use $(SolutionDir)\..\.. to get your base directory.

---

For list of all macros, see here:

http://msdn.microsoft.com/en-us/library/c02as0cs.aspx

Palmira

Answer 2

Here is what you want to put in the project's Post-build event command line:

copy /Y "$(TargetDir)$(ProjectName).dll" "$(SolutionDir)lib\$(ProjectName).dll"

EDIT: Or if your target name is different than the Project Name.

copy /Y "$(TargetDir)$(TargetName).dll" "$(SolutionDir)lib\$(TargetName).dll"

Moise

Good tip. I forgot the quotes. – Mendelson

It wasn't working for me because I forgot the /Y. Thanks for showing the whole command. – Lifelike

One can use xcopy with wildcards and the appropriate switches to achieve a similar result, whilst maintaining the source folder's (tree) structure, such as: xcopy /i /e /s /y /f "<source>\MyFolder\*" "<destination>\MyFolder" – Hyozo

+1 for quotes (if you path has spaces) and /Y to force in case of overwrite. – Kapellmeister

I would suggest to use $(TargetName) instead of $(ProjectName) in the source-part. – Williemaewillies

nice; I ended up going with copy /Y "$(TargetPath)" "$(SolutionDir)\somewhere\" – Halogenate

update to my prev. comment: copy /Y "$(TargetPath)" "$(SolutionDir)somewhere\" , without the extra backslash, since $(SolutionDir) includes a trailing backslash (at least in VS2012) – Halogenate

For more advanced users, this answer assumes the use of the basic Windows command line. If you configure your machine to use another command shell (e.g. PowerShell) by default, you will have to use a copy command compatible with your selected shell. – Fanaticize

Answer 3

You could try:

$(SolutionDir)..\..\

Actinic

Please keep in mind that the variable $(SolutionDir) already has the back slash. Source: "The directory of the solution (defined with drive and path); includes the trailing backslash '\'." msdn.microsoft.com/en-us/library/42x5kfw4.aspx – Konstanze

Answer 4

I think this is related, but I had a problem when building directly using msbuild command line (from a batch file) vs building from within VS.

Using something like the following:

<PostBuildEvent>
  MOVE /Y "$(TargetDir)something.file1" "$(ProjectDir)something.file1"
  start XCOPY /Y /R "$(SolutionDir)SomeConsoleApp\bin\$(ConfigurationName)\*" "$(ProjectDir)App_Data\Consoles\SomeConsoleApp\"
</PostBuildEvent>

(note: start XCOPY rather than XCOPY used to get around a permissions issue which prevented copying)

The macro $(SolutionDir) evaluated to ..\ when executing msbuild from a batchfile, which resulted in the XCOPY command failing. It otherwise worked fine when built from within Visual Studio. Confirmed using /verbosity:diagnostic to see the evaluated output.

Using the macro $(ProjectDir)..\ instead, which amounts to the same thing, worked fine and retained the full path in both build scenarios.

Rubstone

cross-linking to the same hack in case I forgot to give credit... – Rubstone

Start worked for me (for xcopy at a shared folder). – Unborn

Answer 5

Would it not make sense to use msbuild directly? If you are doing this with every build, then you can add a msbuild task at the end? If you would just like to see if you can’t find another macro value that is not showed on the Visual Studio IDE, you could switch on the msbuild options to diagnostic and that will show you all of the variables that you could use, as well as their current value.

To switch this on in visual studio, go to Tools/Options then scroll down the tree view to the section called Projects and Solutions, expand that and click on Build and Run, at the right their is a drop down that specify the build output verbosity, setting that to diagnostic, will show you what other macro values you could use.

Because I don’t quite know to what level you would like to go, and how complex you want your build to be, this might give you some idea. I have recently been doing build scripts, that even execute SQL code as part of the build. If you would like some more help or even some sample build scripts, let me know, but if it is just a small process you want to run at the end of the build, the perhaps going the full msbuild script is a bit of over kill.

Hope it helps Rihan

Ribose

thx Rihan, but apparently VS 2003 doesn't seem to support this ! I am of course quite content with the post build event ;-) – Chesterton

I did not realize it was vs2003, and hence the using msbuild as a possible solution, if I recall vs2003 was pre the msbuild era? Thanks for the response. Best of luck with VS 2003, I did not look back after moving over to VS2005 – Ribose

Answer 6

I solved my problem by reinstall VS and then download .Net Core (3.x and 2.x) sdk packages

Diamagnetic

Answer 7

Here is my post build script

1. Creates the custom path for my own. Including library and version.
2. Copies the .dll (target file)
3. Copies the *.md files.

script:

md c:\_References\$(ProjectName)\$(AssemblyVersion)
xcopy $(ProjectDir)$(OutDir)$(TargetFileName) c:\_References\$(ProjectName)\$(AssemblyVersion) /y
xcopy $(ProjectDir)*.md c:\_References\$(ProjectName)\$(AssemblyVersion) /y

Onetime