CODEWITHSUNDEEP
visual-studio-2010msbuildtfsbuild
Pete Stensønes
Pete Stensønes

Reputation: 5685

TFS2010 solutions PostBuild macro values differ in Team build

I have a PRISM app in a single TFS solution (shell, comon library, two modules and several test projets. for simplcity I chose a DirectoryModuleCatalog and in order to run apps locally after a build added a postbuild step to teh module projects buils that copied the build dll to a modules subfolder of the GUI apps output path.

This works just fine on a local client build, but when the same postbuild event is triggered from the TFS build agent it fails. On inspection this is becuase the $(OutDir) macro which is a relative path locally is an absolute path in teh TFS build agent MSBuild logs!

to quote MSDN 

$(OutDir) 

Path to the output file directory, relative to the project directory. 
This resolves to the value for the Output Directory property. 
It includes the trailing backslash '\'.

Locally this resolves to "bin\Debug\" on the build agent it resolves to "C:\Builds\5\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\"

Given this orginal local post build definition;

mkdir "$(SolutionDir)Gui\$(OutDir)Modules\"
copy "$(TargetPath)" "$(SolutionDir)Gui\$(OutDir)Modules\"

You can see why it fails on the build agent like this:

mkdir "C:\Builds\4\XXXX\Gui.DEV_Cortex7_Iteration0.CI\Sources\Gui\C:\Builds\4    \XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\Modules\"
copy "C:\Builds\4\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\Apdcomms.Cortex.Gui.Example2.Module.dll" 
    "C:\Builds\4\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Sources\Gui\C:\Builds\4\XXXX\Gui.DEV_XXXX7_Iteration0.CI\Binaries\Modules\"
The filename, directory name, or volume label syntax is incorrect.
The filename, directory name, or volume label syntax is incorrect.
      0 file(s) copied.

So looing at the values of the macros it would seem I need a different set of commands in postbuild when building under TFS build agents to that in local mode, that is pretty sucky.

SO to the qestion: How can I move the binary output of one project in a solution to a sub-folder of another project in that same solution in a way that works on a locla client build AND a TFS team build?

Upvotes: 2

Views: 2016

Answers (1)

TimWagaman
TimWagaman

Reputation: 1008

I personally don't like relying on post build scripts when building from TFS. It would be much better to customize your build template. While the postbuild script is certainly easier, the build template will manage your environment (in my opinion) better. I'm linking to a Microsoft article to give you a bit more info on how to accomplish this. I'm also pasting the content so that StackOverflow can stay self contained.

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

The default build process (as defined in DefaultTemplate.xaml), drops the binaries that it compiles from all your code projects into a single directory. However, in some cases, you want to organize the binaries into a more granular and organized folder structure.

You can use techniques in this topic to create a custom build process that drops your binaries into a directory structure that you design. You can also customize build processes in different ways by using the same principles. This topic explains the following techniques:

Customize the Windows Workflow segment of the build process. You should make changes in this segment to customize most aspects of your build process except for compilation and handling of binaries. Specifically, this topic describes how to perform the following tasks:

Create a custom build process by modifying a copy of the Default Template (DefaultTemplate.xaml).

Declare and use arguments to pass data into the workflow.

Declare and use variables to collect and pass data throughout the workflow.

Modify how the workflow uses the MSBuild activity to call MSBuild.

Download a file to the build server and use the ConvertWorkspaceItem activity to make that file available to the build process.

Customize the MSBuild segment of the build process. By making changes in this segment, you can more effectively customize how binaries are compiled and handled. Specifically, this topic describes how to perform the following tasks:

Pass arguments to MSBuild and then use them in your code projects to change how your compiled binaries are handled.

Set up a centralized common code library of your own MSBuild elements, such as property groups or targets. By setting up this type of library, you enable your team to easily reuse and modify key pieces of your build process logic.

Upvotes: 2

Related Questions