Jeff Lehmer

We have a post-build step that copies final dll's to a folder that is two levels up from the solution. So I changed the location of the "Source Control Folder" in our Workspace to accomodate this during a Team Build.

$/Analysis Software/Libraries

to

$/Analysis Software/ReleasedLibraries/General/Libraries

which more closely resembles the relative directory structure on our machine. However, this had absolutely no affect on where the post-build step copied the files. In both cases the post-build copied the files relative to "$/Analysis Software/" and ignored the two sub-directories (ReleasedLibraries/General). Btw, my post-build step copies the finished dll's to "../../Dlls/Debug".

My question is this...

How do I get TeamBuild to perform my build in the latter directory rather than the former Or am I looking at this the wrong way



Re: Team Foundation Server - Build Automation Workspace "Source Control Folder" seems to be irrelevant

Aaron Hallberg - MSFT

Team Build v1 doesn't give you much control over the workspace that is created - essentially it will always strip off the common root and map everything else to the "sources" directory under the BuildDirectory specified for the build. To get the folder structure you are looking for, you would need to include something at the root directory level (which will cause the common root of your mappings to be $/Analysis Software) in your workspace mappings.

One possibility would be to use $/Analysis Software as your one real mapping and then cloak out whatever is unnecessary.

Note that this issue has been resolved in Orcas, where you have much more control over your workspace mappings, and where your mappings can be manipulated directly in the Build Definition dialogs (rather than in the WorkspaceMapping.xml file).

-Aaron






Re: Team Foundation Server - Build Automation Workspace "Source Control Folder" seems to be irrelevant

Jeff Lehmer

Sadly for us, that makes perfect sense! Our biggest problem is t our solutions refer to projects and dll's that are not below the directory where the solution exists. Hence, any relative paths are completely screwed up by the fact Team Build v1 maps everything to the "sources" directory as you described. We will have to rearrange our project directory structure and maybe even create a separate solution for the projects that aren't under our solution directory.

Thank you, Aaron!




Re: Team Foundation Server - Build Automation Workspace "Source Control Folder" seems to be irrelevant

Aaron Hallberg - MSFT

If your solutions refer to projects and dlls higher up the chain, shouldn't those project and dlls be included in your workspace mappings If so, I would expect the relative paths to work out just fine on the build machine...

-Aaron






Re: Team Foundation Server - Build Automation Workspace "Source Control Folder" seems to be irrelevant

Jeff Lehmer

Aaron,

Yes, my workspace mappings on my local box include those that are higher up the chain. There are no mappings on the build machine. I assumed it built the mappings on the fly. Out of the five projects that are "higher up" two of them seem to load fine but the other three fail to load: e.g.,

error MSB3202:

The project file "..\..\Libraries\IGVControls\IGVControls.csproj" was not found.

I found the following blog where the user stated these errors are bogus and all he had to do was fix his post-build step where he did a "copy" and his MSB3202 problems went away. Yes, I am doing several "copy"s and an "attrib".

http://manicprogrammer.com/cs/blogs/michaelruminer/archive/2007/09/05/team-build-errors-may-not-always-be-what-they-seem.aspx

So I checked out my post build step that did my "copy"s and found the following:

copy $(TargetPath) $(SolutionDir)$(SolutionName)\$(OutDir)

and here is what it translates to when run in Team Build (the full error). You can see how the destination directory is out of control. It appears that Team Build is hijacking the "SolutionName" value.

error MSB3073:

The command "copy c:\ci_build\Analysis Software\ci_beadstudio\Binaries\Debug\WizardUtils.dll c:\ci_build\Analysis Software\ci_beadstudio\Sources\BeadStudio\BeadStudio\c:\ci_build\Analysis Software\ci_beadstudio\Binaries\Debug\" exited with code 1.

c:\ci_build\Analysis Software\ci_beadstudio\Sources\BeadStudio\BeadStudio.sln(0,0):

I feel as if I am flailing around wildly here. All I have is a blog that tells me to concentrate on fixing my copy command yet I have no idea how to fix it.

Any direction you can point me would be greatly appreciated.





Re: Team Foundation Server - Build Automation Workspace "Source Control Folder" seems to be irrelevant

Jeff Lehmer

I found some interesting stuff from one of your previous posts that I think might help me. I will play with this information and see what happens.

http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=620326&SiteID=1





Re: Team Foundation Server - Build Automation Workspace "Source Control Folder" seems to be irrelevant

Jeff Lehmer

Here is what I found that fixed multiple issues for me so I am posting it here in case anyone who has a similar problem finds this post.

1\ in Visual Studio you should put quotes around the paths in your post-build step. I had several "copy", "mkdir", and "attrib" post-build steps that were causing a problem in Team Build because their paths had a space in them.

2\ change any use of "OutDir" in your post-build steps to "Configuration". Team Build replaces OutDir with the absolute path to the new "Binaries" path and that ends up causing your path look like the following with two "c:\" in the path.

"c:\ci_build\Analysis Software\ci_beadstudio\Sources\BeadStudio\BeadStudio\c:\ci_build\Analysis Software\ci_beadstudio\Binaries\Debug\"