OutDir being Ignored when run from MSBuild task in TeamBuild 2010

Topics: Developer Forum, Project Management Forum
Jul 5, 2011 at 7:52 PM

Hello,

I have been doing some work with the latest released code of the SHFB tool.  As part of my process template I want to build a shfbproj file using the MSBuild activity.  I pass in the BinariesDirectory variable from the default template.xaml to OutDir.  The output however, is being placed in the location specified in the shfbproj file.  I took the team build piece out of the equation by running the shfbproj file in MSBuild (4.0) and passed OutDir as a property directly to MSBuild from the command line.  I received the same result where the path I pass in the OutDir property is completely ignored.

Are others noticing this? 

Thanks,

-Derek

Coordinator
Jul 5, 2011 at 9:01 PM

Make sure you are using the 03/26 refresh of the v1.9.3.0 release or the v1.9.3.1 alpha release as they both contain a fix for a bug that was causing the build task to miss some command line variables.  If the project is being built with the <MSBuild> task within another project file, there is a bug that causes it to pick the wrong copy of the project being built and it doesn't apply the global variables to the project (see this thread: http://shfb.codeplex.com/discussions/260059).  I have fixed that problem and checked it into source control but I have not published a built release that contains the fix yet.  Unfortunately, I do not use nor do I have access to Team Build to test/diagnose any other issues.

Eric

 

Jul 27, 2011 at 7:48 AM

We had the same issue. I believe the core problem is a naming missmatch between what the build template (xaml) passes to msbuid and what shfb looks for (OutDir vs OutputPath).

You can "fix" this by adding the following to your .shfbproj right under the <OutputPath>

<OutputPath Condition="'$(OutDir)' != ''">$(OutDir)\$(OutputPath)</OutputPath

>

(Or whatever format you prefer).

I tried quickly to patch up the $(SHFBROOT)\SandcastleHelpFileBuilder.targets file to do the same on the buildserver, so this wouldn't have to be specified on every docu project, but haven't hat much sucess yet. Eric, do you think this would be the route to go?

Thnx

Coordinator
Jul 27, 2011 at 8:37 PM

I don't know.  I'm not familiar with how output paths from XAML files are used.  I'd have to see an example with an explanation of how things are supposed to happen in order to determine what the problem is and an appropriate fix.

Eric

 

Jul 28, 2011 at 8:19 AM
Edited Jul 28, 2011 at 8:39 AM

Well, the xaml we speak of is just a BuildActivity template that does a bunch of stuff (like checkout sources, run unit tests, etc). But in any case one of the things it does is call MSBuild which I believe is really the only thing that matters for SHFB. Among the arguments it passes to MSBUID is /p:OutDir="d:\<some Path that is different from where the sources lie>".

OutDir acts as a kind of intermediate place for things to go, before they are copied to a "DropLocation" upon sucessful build. In any case...

Inside MSBUILD, you end up with two Arguments set (seen with diagnostic logging):

OutDir = "d:\<some Path that is different from where the sources lie>"
OutputPath = "\<some relative path>"

Now this is the same for other project types too, eg. C# project files I just noticed. So my earlier comment about naming mismatch seems wrong. In any case, a C# project will end up in OutDir (which TeamBuild sets) and ignore OutputPath in this case it seems, whereas .shfbproj always seem to end up in OutputPath (which is interpretated relative to the sources directory). One of the (most obvious) problems with this is that this directory is usually not accessable by "normal" users.

Example structure (there are subfolders within each of these obviously named after eg. teamproject\Buiddefinition\Date etc.):

d:\BuildDrops -> this is where things ultimatly end up in, for us this is a network share and the only place users (other devs) can acess
d:\builds
         \sources -> this is where sources are being checked out to and build from, no output normally lands here (but shfbproj output does)
         \binaries -> this is where build output ends up in, inside this unittests etc. are run, until they are finally copied to buildDrops upon sucess

So in this example, it would pass something like 
/p:OutDir="d:\builds\binaries\TemProjectName\BuildDefinitionName_date\"
OutputPath would be set to ".\Help"
and builds end up inside something like d:\sources\TeamProjectName\BuildDefinitionName\DocuProjectName\Help
(DropLocation would be d:\BuildDrops\TemProjectName\BuildDefinitionName_date\ -> should be of no relevance to shfb)

Coordinator
Jul 28, 2011 at 5:40 PM

I misunderstood what OutDir was being used for above.  You're referring to the output of the SHFB project, not the output of the documentation sources.  SHFB will use OutDir to locate the output assemblies and comments files for documentation sources if it is defined but will not use OutDir for the location of the compiled help file/website.  The Output Deployment plug-in can be used to redirect the output elsewhere.  It's possible that I could have SHFB start using OutDir if defined but that's probably a breaking change in behavior.  I'm not sure I'd want to do that without having it be conditional in some way to preserve it's current behavior so as not to break everyone's existing builds when the output starts ending up in an unexpected location.

Eric

 

Aug 1, 2011 at 9:18 AM

I see, that makes sense, it expains how it finds assemblies and comment files.

I took a quick look at the Output Deployment plugin, but I'm not sure how to configure it to evaluate and use Outdir at compile time.

Honestly the "trick" I mentioned above is good enough for us for now. However, maybe a simple checkbox "Set OutputPath to MSBuild OutDir Parameter if set" or something like that is more obvious.

Cheers