Using DocProject with Team Build

Topics: Bugs, Features, General Questions
Jul 6, 2007 at 3:31 PM
When i use a team build server with DocProject 1.6.2 installed as well as Sandcastle June CTP Refresh. I get the following errors when i try to build a doc project:

Solution: WebServices.sln, Project: ChmDocumentation.csproj, Compilation errors and warnings
C:\Program Files\Dave Sexton\DocProject\bin\DaveSexton.DocProject.targets(0,0): warning : The registered build process component cannot be instantiated because the DocProject did not produce assembly output.
C:\Program Files\Dave Sexton\DocProject\bin\DaveSexton.DocProject.targets(29,3): error : The "C:\Program Files\Sandcastle\\ProductionTools\MRefBuilder" process failed with exit code: 1.

I tried compiling in visual studio without any problem, i also tried compiling from the commandline with msbuild which also works like a charm. Why is Team Build (which is just a front for MSBuild as far as I know) not working?
Coordinator
Jul 6, 2007 at 4:09 PM
Hi,

I haven't tried using Team Build myself to build a DocProject but I had assumed the same as you - that it would work as it does on the command-line using MSBuild.exe.

We may be able to diagnose the problem by starting with a basic build first and then moving up to a help-build. If you open the project file you'll see the default target is set to BuildHelp. Try changing it to Build. Then build the solution using Team Build.

Does the project produce an assembly on the build server in the project's bin directory?

Also, the MRefBuilder error doesn't provide any information about the problem. Please check the Application event log on the server to see if there are any error events with DocProject as the source. If you find one that provides more information about this error then please post it here.

Thanks,
Dave

Jul 8, 2007 at 12:46 PM
Dave,

Changing the build's default target to Build made the build perform succesfully (but ofcourse no doc output). Changing it back to BuildHelp again broke it up again. Even in the later case though, an assembly is build in the projects bin directory. The error on the event log is as follows:

Event Type: Error
Event Source: DocProject
Event Category: None
Event ID: 0
Date: 7/8/2007
Time: 1:41:14 PM
User: N/A
Computer: MARIANNETIMMER
Description:
Step 2 DaveSexton.DocProject.Engine.ExternalProcessException: Execute MRefBuilder:

DaveSexton.DocProject.Engine.ExternalProcessException: The "C:\Program Files\Sandcastle\\ProductionTools\MRefBuilder" process failed with exit code: 1.
at DaveSexton.DocProject.Engine.BuildStepExecutionEngine.ExecuteStepAsync(IBuildStep step, Boolean outOfBand)
at DaveSexton.DocProject.Engine.BuildStepExecutionEngine.ExecuteStep(IBuildStep step, Int32 number, Boolean outOfBand)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

But i think this error message is a result of the first error (The registered build process component cannot be instantiated because the DocProject did not produce assembly output.).

Help would be greatly appreciated.

Thanks,

Jeroen
Coordinator
Jul 8, 2007 at 10:52 PM
Edited Jul 8, 2007 at 11:59 PM
Hi Jeroen,

Thanks for the reply.

The fact that your DocProject's assembly is being built leads me to believe that the first error is a result of incorrect path information. I suspect that DocProject simply cannot find the assembly. I also think that the second error is a result of incorrect path information, but I'd like you to confirm that for me :)

The event log information, unfortunately, doesn't provide anything more than your original post. However, the trace that appears in VS's Build Output window should have at least described why the MRefBuilder utility is failing. If you could please scan the build output trace for more error information at the point of failure it would be extremely helpful to me.

I can't reproduce this issue because, unfortunately, I don't have TFS. I appreciate your assistance and I'm sure others will too if we can get this working :)


But i think this error message is a result of the first error (The registered build process component cannot be instantiated because the DocProject did not produce assembly output.).

Actually, I'm quite sure that the MRefBuilder error is not a result of the first error since these components are completely unrelated, but I suspect that they are both caused by the same issue (invalid paths). I appreciate the help though ;)

The build process component is the type that's defined in your BuildProcess.cs file. Having the component is optional so DocProject will just issue a warning if there is a problem loading the type and will continue with the help-build process anyway, as in your case. The MRefBuilder program will not fail because of this and, technically, it's still possible to build documentation even without your DocProject's build process component loaded.

Thanks,
Dave
Jul 9, 2007 at 10:15 AM
Dave,

It seems i was a bit to hasty saying an assembly was generated in the projects bin directory. It turns out that Team Build does not use the projects bin directory, instead it compiles to the obj directory, and a bin directory is never created. So files are created they are just not in the position expected by either DocProject or MRefBuilder.

I have tried some workaround provided by: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=472079&SiteID=1
But this doesn't seem to work either. There should be a build property that tells you the build path for the project, which you should probably use in your Add-In.

It would be very much appreciated if you could fix this. Ofcourse I can help you test it if you don't have a TFS server lying around.
Coordinator
Jul 9, 2007 at 12:19 PM
Hi Jeroen,

Thanks for the link and for offering to help me test this. I don't have a copy of TFS, but if there is a way I can get Team Build separately I can test this myself. Do you know if it's available as a separate installation for users that do not own TFS?

Currently, the code-base is not in a deployable state as I've been working on updates for 1.7.0, but if you can try to rebuild the source code with the following changes it would be helpful. For instructions see How To Use The Source Code and if you need further assistance please ask. Note that if you build the installer you don't have to worry about the vs_piaredist.exe redistributable and can ignore the warning when building the Installer project.

The following file is located in the DaveSexton.DocProject project under the MSBuild directory:

MSBuildProjectOutput.cs
http://www.codeplex.com/DocProject/SourceControl/FileView.aspx?itemId=310428&changeSetId=24093

The OutputPath property is used to determine the path to the project's output, for both DocProjects and source projects:

public virtual string OutputPath
{
  get
  {
    return Path.Combine(project.Directory, project.Properties["OutputPath"]);
  }
}
You can try changing it to use OutDir instead, according to the thread that you cited:

return project.Properties["OutDir"];
But I don't know if this will affect normal command-line builds using MSBuild.exe, which is required by the Express editions of Visual Studio. If this works, please try to build the project on the command-line as well to make sure that it didn't break.

Thanks,
Dave
Jul 10, 2007 at 9:37 AM
Dave,

I have yet to succeed in building the DocProject solution. I am having some problems with the InstallerPrep project. I did however debug the existing dll with the existing code, and i can safely say, that for normal commandline builds with MSBuild, the OutDir has the exact same value as OutputPath. I also found some more information about the use of these properties in the upcomming version of VS (2008/Orcas).

http://blogs.msdn.com/aaronhallberg/archive/2007/06/07/preserving-output-directory-structures-in-orcas-team-build.aspx

As for the InstallerPrep project, i get the following message in my build log:

DaveSexton.DocProject.InstallPrep -> C:\Program Files (x86)\Dave Sexton\DocProject\Source\DaveSexton.DocProject.InstallPrep\bin\Debug\DaveSexton.DocProject.InstallPrep.dll
"C:\Program Files (x86)\Dave Sexton\DocProject\Source\DaveSexton.DocProject.InstallPrep\BuildOutput.bat" "C:\Program Files (x86)\Dave Sexton\DocProject\Source\DaveSexton.DocProject.InstallPrep\" "Debug"

\Dave was unexpected at this time.
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets(3090,13): error MSB3073: The command ""C:\Program Files (x86)\Dave Sexton\DocProject\Source\DaveSexton.DocProject.InstallPrep\BuildOutput.bat" "C:\Program Files (x86)\Dave Sexton\DocProject\Source\DaveSexton.DocProject.InstallPrep\" "Debug"" exited with code 255.

I think somehow somewhere there are some missing quotes around a path or something. I just can't seem to find where. This might be a x64 issue though, i will have a look at it tonight at my home PC (which is x86) just to be on the safe side.

Thanks,
Jeroen
Coordinator
Jul 10, 2007 at 10:42 AM
Hi Jeroen,

Thanks for the update and for the link to that great article. I understand the different between OutputPath and OutDir now and I'll be sure to update the code-base for the next release so that the MSBuild projects use OutDir.

As for the InstallPrep issue, you may be right about x64 since I've never tried building on a 64-bit platform. But in the instructions (§Setting Up The Solution, Step #3) you'll see that I recommened to copy the Source directory to another directory (preferably your VS project's folder). I don't know of it will help this situation though. The reason that I recommend copying the directory is actually because after modifying the Source folder when you uninstall DocProject you'll have to go back and manually delete Source since it has your updates to the installled source code files so Windows Installer will not remove them.

Please let me know if this works on your 32-bit PC.

Thanks,
Dave
Jul 11, 2007 at 2:58 PM
Edited Jul 11, 2007 at 3:20 PM
Hi Dave,

I have tried what you suggested on my x86 box, and it worked. Everything is compiling well now. Problem is that with the OutDir property in place instead of the OutputPath, its still not working. Still the same error, and when i look in the build log for the Team build, i see the following:

Starting help build for Documentation...
Warning:
C:\Program Files\Dave Sexton\DocProject\bin\DaveSexton.DocProject.targets : Documentation warning : The registered build process component cannot be instantiated because the DocProject did not produce assembly output.
Preparing target directory...
Building documentation for Documentation...

Step 1 of 13: Change Directory

Changing current directory from "c:\Builds\Persephone\Nightly Build\Sources\Documentation\" to "c:\Builds\Persephone\Nightly Build\Sources\Documentation\buildhelp"

Step 2 of 13: Execute MRefBuilder

C:\Program Files\Sandcastle\\ProductionTools\MRefBuilder /config:"c:\Builds\Persephone\Nightly Build\Sources\Documentation\Presentation\Style\Configuration\MRefBuilder.config" /out:reflection.org /internal- "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Controls.Charts\bin\Debug\Vbi.Compact.Controls.Charts.dll" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Controls\bin\Debug\Vbi.Compact.Controls.dll" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Data\bin\Debug\Vbi.Compact.Data.dll" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Persephone.Business\bin\Debug\Vbi.Compact.Persephone.Business.dll" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Persephone.Client\bin\Debug\ErbisPDA.exe" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Persephone.Data\bin\Debug\Vbi.Compact.Persephone.Data.dll" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Solutions\bin\Debug\Vbi.Compact.Solutions.dll" "c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact\bin\Debug\Vbi.Compact.dll"

MrefBuilder (v2.2.64000.4)
Copyright c Microsoft 2006
Error: An error occured while loading assemblies for reflection. The error message is: Could not find a part of the path 'c:\Builds\Persephone\Nightly Build\Sources\Vbi.Compact.Controls.Charts\bin\Debug'.
Non-zero exit code: 1

Step 2 DaveSexton.DocProject.Engine.ExternalProcessException: Execute MRefBuilder:
The "C:\Program Files\Sandcastle\\ProductionTools\MRefBuilder" process failed with exit code: 1.
C:\Program Files\Dave Sexton\DocProject\bin\DaveSexton.DocProject.targets(29,3): Step 2 DaveSexton.DocProject.Engine.ExternalProcessException: Execute MRefBuilder: error : The "C:\Program Files\Sandcastle\\ProductionTools\MRefBuilder" process failed with exit code: 1.

Successful Steps: 1 of 13
Failed Steps: 1

As you can see in the commandline for MrefBuilder, its still using the bin paths. Problem is however, i am not sure what the value of OutDir is. I will try to edit your source to include some logging of several property value, just after it says "Starting help build for". I will keep you updated on my findings.

Regards,

Jeroen
Coordinator
Jul 11, 2007 at 3:23 PM
Edited Jul 11, 2007 at 3:23 PM
Hi Jeroen,

Thanks for the update.

You can output all of a project's properties to a file using the WriteProperties method. The best place to do that would probably be in the DaveSexton.DocProject.MSBuild.BuildDocProject.Execute method (in the DaveSexton.DocProject project). Try something like this:

public override bool Execute()
{
  try
  {
    if (DocProjectAddIn.RunningInHost)
      return BuildController.Build(Project);
    else
    // The following code is used by express editions of Visual Studio since they don't support Add-Ins
    // and when using MSBuild on the command-line.
    {
      MSBuildTrace trace = new MSBuildTrace(this.Log);
      BuildContext context = new BuildContext(Engine, trace);
 
/**** ADD THE FOLLOWING LINE */
      Project.WriteProperties(@"c:\builds\props.txt", false, false)
 
      Engine.Build(context);
 
      return context.BuildState == BuildState.Successful;
    }
  }
  catch (Exception ex)
  {
    DaveSexton.DocProject.Log.Exception(ex, Resources.Errors.MSBuildGeneralError, ProjectFile);
 
    throw;
  }
}
Maybe looking at the complete list of properties you'll find one with the correct value ;)

Thanks,
Dave
Coordinator
Jul 11, 2007 at 3:59 PM
Edited Jul 11, 2007 at 4:00 PM
Hi Jeroen,

I just thought of something that might help.

According to that article you cited, Team Build sets the OutDir property on the command-line when it runs MSBuild.exe. The MSBuildAnyProject.Properties property returns all of the evaluated properties, yet OutDir would actually be a global property when set on the command-line.

So try updating the MSBuildProjectOutput.OutputPath property so that it uses the global properties collection instead:

public virtual string OutputPath
{
  get
  {
    return project.ConfigurationProperties["OutDir"];
  }
}
Thanks,
Dave
Jul 13, 2007 at 8:19 AM
Dave,

The problem seems to be very subtle. It looks like Team Build doesn't use an output dir. The property IntermediateOutputPath has the value where the build file is placed (obj\Debug), but it also has the same value on a MSBuild build. Also non of the referenced assemblies from the same solution are placed there. Theoretically though, things should work fine if this property is used since the search path for all references is set to a path that contains them (in MSBuild this is bin\debug, and in Team Build this is the binaries folder in the build dir ($(BinariesRoot)\$(Flavor)). I am not certain if this $BinariesRoot property works on MSBuild. So i think there are three options:

Either $BinariesRoot works on MSBuild and it points to bin, then we use the $(BinariesRoot)\$(Flavor) approach.
Use different cases for Team Build and MSBuild (which will require a lot of testing i guess).
Or we use $(IntermediateOutputPath), which should probably work, but needs some testing (since there might be some references missing).

I'm currently at the office again on my x64 machine so i can't test it at the moment, but i'll have a look at it tonight (hopefully).
Jul 13, 2007 at 8:29 AM
Oh, here is a forum post about the output dir not being created as expected:

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

The second post (marked as solution) might be helpfull.

Regards,

Jeroen
Coordinator
Jul 13, 2007 at 1:17 PM
Hi Jeroen,

Thanks for the update.

You already posted that forum link, but I don't think it specifies any solution other than to actually use OutDir. Perhaps you posted the wrong link this time?

Even the blog post indicated that OutDir should work fine. Did you try it using the ConfigurationProperties collection instead of the Properties collection?

My original suggestion to use Project.WriteProperties(@"c:\builds\props.txt", false, false) doesn't write out the global properties, which is where OutDir should be defined. To write out the global properties use: Project.WriteProperties(@"c:\builds\props.txt", true, false).

The problem with using IntermediateOutputPath is that it points to the obj directory. I'd like DocProject to use the final destination, which in team build is the Binaries directory apparently.

BTW, you may be able to build on your x64 machine if you just copy the solution from the Source directory to another folder outside of Program Files. Did you try that?

Thanks very much for helping me with this :)

- Dave
Jul 13, 2007 at 3:55 PM
Hi Dave,

I was sure i posted the link but i couldn't find it anymore, so i thought i must have been mistaken, so i posted it again.

I tried the ConfigurationProperties collection instead of the Properties collection, but there don't seem to be any properties in it. So the build crashes (ArgumentNullException in the Path.Combine method when providing a null value from project.ConfigurationProperties"OutDir"). This is strange because i think the $(BinariesRoot) should be a global property as well, as it is not in the evaluated properties collection.

Somehow the global properties from Team Build are not getting through to the project build. Problem is also that the $(BinariesRoot) or $(OutDir) as described in that forum post will contain the outputs of all the solutions built in that build. There are no subdirectories for each solution. This might lead to problems. While investigating i noticed that Orcas will provide solutions to all of this, too bad its not going to be released before 28 of February.

Do you have any idea why there are no global properties in the ConfigurationProperties?

Regards,

Jeroen
Coordinator
Jul 13, 2007 at 4:51 PM
Hi Jeroen,

So at this point OutDir might still work but we haven't been able to test it yet because the global properties for the project aren't available. Correct?


Do you have any idea why there are no global properties in the ConfigurationProperties?

I think I do.

When I started developing DocProject's MSBuild interfaces and components I noticed that MSBuild's Task class does not provide a way to access MSBuild's in-memory Project class in which the Task is executing. This presented a big problem since DocProject needed access to configuration properties and extension properties.

The work-around was to actually create a new Project from the project file, which is obtained by simply passing a parameter to the build task. (In the DaveSexton.DocProject.targets file you'll notice that $(MSBuildProjectFullPath) is passed to the build task). This is also required for managed Visual C++ projects, which require automation since they are not supported by MSBuild.

Anyway, global properties are not used by DocProject so they weren't tested, but apparently now I'm realizing that the global properties are in-memory in MSBuild's Engine and Project, which as I just stated, DocProject cannot access.

This is a shortcoming of MSBuild and unfortunately, I don't know of any workaround. I'll post a question in a forum for MSBuild to see what can be done about this, but I suspect that the answer will be nothing.

If DocProject's build task cannot access global properties then I really don't know how we could solve this problem, but I'll let you know what I find.

Thanks,
Dave
Coordinator
Jul 13, 2007 at 5:18 PM
Edited Jul 13, 2007 at 5:20 PM
Hi,

I think I found an explanation as to why I can't access global properties from the build task:

http://channel9.msdn.com/wiki/default.aspx/MSBuild.PassingInAllPropertiesToATask

I guess the only solution is to update the DaveSexton.DocProject.targets file to pass in the OutDir property to the BuildDocProject task. The BuildDocProject class and the MSBuild classes need to be refactored to use the property from the targets file.

I find this to be ridiculous since it means DocProject is always going to be restricted to what has been hard-coded as properties in the targets file. Users can't simply change global properties on the command-line now to switch directories, etc. IMO, it was a poor decision by the MSBuild team to prevent tasks from accessing a project's properties; especially global properties.

The code-base is not in a deployable state right now so I can't give you an updated version, but I'll see if I can make the appropriate changes for the next release and make sure that it still works for normal builds. Hopefully it will fix your problem as well. As you know, I can't actually test it because I don't have TFS but if you have any problems with the next release then please let me know.

I'm sorry for any inconvenience. If you still have any ideas for a possible work-around that you can code yourself, I can put in my two sense if you'd like.

Thanks for helping me diagnose the problem,
Dave
Jul 13, 2007 at 5:47 PM
Dave,

I completely agree that this restriction was a poor design choice. I know they have some major changes in store for us in the Orcas release, so hoepfully they did something about this particular issue.

Ofcourse i will test the new release on my own test TFS server as soon as you have one online. In the meanwhile, since we only need the functionality in one of our solutions, i'll just hardcode the path i need in the DocProject source, build it, and deploy it on the server. I have tested it with a test project and that works. (So after the path issue there were no other issues with DocProject on Team Build, which was a big relief)

Also as soon as Orcas Beta 2 comes out, i'll get that version of TFS running on a Virtual Machine, so i can test with some of the improvements they made.

Thanks for making such a convenient solution for building SandCastle,
Jeroen
Coordinator
Jul 13, 2007 at 6:33 PM
Hi Jeroen,

It sounds like a plan ;)

Hard-coding the path is a good, quick work-around. I'm also glad that it works without any other issues!

About Orcas though, DocProject won't install without VS 2005, but you can update the Installer project to check for Orcas as well if you want. The InstallPrep project also has support for Orcas but it's been disabled. If you need help enabling it just let me know.

FYI, I did test DocProject on a VM with Orcas Beta 1 and I discovered that it doesn't work due to out-of-date automation interfaces. It appears that DocProject has to actually be rebuilt for Orcas otherwise it doesn't work. I plan to see if I can build a single version of DocProject in the future that will run for VS 2005 and VS 2008, but I don't know if it will be possible yet and to be perfectly honest, I doubt that it'll work.

Maybe sometime soon I'll create a CTP build of DocProject for Orcas ;)

Thanks,
Dave
Coordinator
Jul 18, 2007 at 3:19 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Aug 13, 2007 at 9:05 PM
Hi Jeroen,

1.7.0 Release Candidate and 2008 Beta contains the updates that we've discussed. Please let me know if it works for you.

Thanks,
Dave
Aug 14, 2007 at 10:55 AM
Dave,

Thanks for the update. I could only test 1.7.0RC on Team Foundation 2005 for now since i am having some problems installing Team Foundation 2008. The new version builds like a charm on TFS 2005 so no stange error messages and stuff. I have tested with 5 projects now (none of them DocSites, only DocProject), 2 large ones (resulting chm files around 6 or 7 mb) and 3 smaller ones (under 1mb chm files). These all work well for me so good job on the update :-)

Kind regards,

Jeroen
Aug 14, 2007 at 11:22 AM
Edited Aug 14, 2007 at 11:24 AM
Dave,

It seems i spoke too soon. The XML documentation generated by the C# compiler is not included in the chm output files. So essentialy there is only metadata information present in the chm files. I have a feeling this has something to do with the fact that the C# compiler does not use the obj dir to output the xml files in, they are generated straight to the outdir. This happens only on TFS, everything works ok on normal build.

I hope this makes some sense.

Thanks,

Jeroen
Coordinator
Aug 14, 2007 at 12:13 PM
Hi Jeroen,

Thanks for the reply.

Your assumption is probably correct, but I'm not sure how to solve this issue. Currently, the path is taken from the DocumentationFile property - but apparently that's no good in TFS. But just to be sure, can you please check your project's buildhelp\assembler\Comments folder for the xml documentation files?

If they weren't copied then I need some way of discovering their location dynamically. Do you know of any MSBuild properties that DocProject could use to get the xml documentation output path? Well, even if one exists, there also must be some way for DocProject to know whether to use DocumentationFile or another property by determining if it's running in TFS.

I'm going to ask the community forums for help on this one. If you have any ideas please let me know.

Thanks,
Dave
Aug 14, 2007 at 1:25 PM
Dave,

I analyzed the output folders some more. The documentation files are not present in the location you describe, but i found them in another place. It seems that in TFS the dll files are compiled to the obj dir, but the xml files go to the path put into the project options. This defaults to the bin folder instead of the obj folder. So this means the xml files are not always in the same directory as the dll files. If you have access to the xml documentation property from the project options in your build routine, then you can use that to locate the xml. This should work on all platforms (VS, MSBuild, TFS).

Regards,

Jeroen
Coordinator
Aug 14, 2007 at 7:42 PM
Hi Jeroen,

The DocumentationFile property is the property that specifies the relative path to the XML documentation file. I thought it would work too ;)

If you open the .csproj file of one of your source projects you'll see <DocumentationFile>bin\Debug\asm.XML</DocumentationFile> under each <PropertyGroup> with a Condition="'$(Configuration)|$(Platform)'=='{type}'" attribute for Debug and Release configurations.

This property appears not to be working in TFS. I'm not sure what property will work though.

Thanks for the reply.
Dave
Coordinator
Aug 15, 2007 at 2:24 AM
Edited Aug 15, 2007 at 2:24 AM
Hi Jeroen,

I've asked the community for help in this matter:

DocumentationFile Property
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2006773&SiteID=1&mode=1

If I discover anything else I'll be sure to post it here.

Thanks for your help,
Dave
Coordinator
Aug 16, 2007 at 10:23 PM
Hi Jeroen,

The respondent, Aaron, has made some good points in this thread:

DocumentationFile Property
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2006773&SiteID=1&mode=1

So have you modified the OutputPath or DocumentationFile properties in you source projects at all?

Aaron seems to believe that the xml documentation file should have been generated in the bin directory if the DocumentationFile property is something like, bin\Debug\asm.XML, but you've claimed that Team Build only outputs to the obj directory and that a bin directory is never even created. If you're using the default settings then please let me know.

There are also a few new things that I'd like to try out, such as the ResolvedProjectReferencePaths property group, which Aaron stated may provide the paths to all of the assemblies and xml documentation files of project references. If that's true then it should solve our problem, and maybe other users' problems outside of Team Build as well.

Thanks,
Dave
Aug 17, 2007 at 7:58 AM


davedev wrote:
Hi Jeroen,

The respondent, Aaron, has made some good points in this thread:

DocumentationFile Property
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2006773&SiteID=1&mode=1

So have you modified the OutputPath or DocumentationFile properties in you source projects at all?

Aaron seems to believe that the xml documentation file should have been generated in the bin directory if the DocumentationFile property is something like, bin\Debug\asm.XML, but you've claimed that Team Build only outputs to the obj directory and that a bin directory is never even created. If you're using the default settings then please let me know.

There are also a few new things that I'd like to try out, such as the ResolvedProjectReferencePaths property group, which Aaron stated may provide the paths to all of the assemblies and xml documentation files of project references. If that's true then it should solve our problem, and maybe other users' problems outside of Team Build as well.

Thanks,
Dave


Ok, the bin directory has been created and contains the xml file, but its not being used in the DocProject build since nothing shows up in the CHM files. I thought i already said this in my last post. If i didn't, i appologise. I noticed on one project i actually changed the documentation path to a different value by accident, that project was the only one that was ok in the chm file. In this case the documentation was output to the project folder itself. So in theory this is a work around, but i really don't like changing 100 projects or so manually to output it to the project dir instead of the default bin\Release or bin\Debug. And then i don't know if it would still work from Visual Studio itself.

Hope this helps, also posted this stuff in the MSDN forums. And btw, really annoying Codeplex bug you have here. ;-)

Thanks for the time you are putting in to this,

Jeroen
Coordinator
Aug 17, 2007 at 9:03 AM
Hi Jeroen,

Thanks for the reply. I'll respond in the MSDN forums so that Aaron can read it.


And btw, really annoying Codeplex bug you have here. ;-)

It's terrible, I know. I reported it to CodePlex here. You should vote on it. BTW, it seems to be happening on all projects for me, not just this one :|

Thanks,
Dave
Coordinator
Aug 18, 2007 at 12:03 AM
Hi Jeroen,

I've zipped the files that needed to be updated with the appropriate changes already made and uploaded it as an attachment to the related work item: Team Build. You simply need to replace these files in your copy of the source code and then rebuild. The files are as follows:

  • DaveSexton.DocProject\MSBuild\BuildDocProject.cs
  • DaveSexton.DocProject\MSBuild\MSBuildProjectProperties.cs
  • DaveSexton.DocProject\MSBuild\MSBuildAnyProject.cs
  • DaveSexton.DocProject\VSProjectProperties.cs
  • DaveSexton.DocProject\IProjectProperties.cs
  • DaveSexton.DocProject.InstallPrep\DaveSexton.DocProject.targets
Here's the synopsis of what I did:

  1. Added Platform and Configuration properties to the BuildDocProject task (in code and the .targets file).
  2. Updated IProjectProperties and its concrete implementations to support writing property values (although the set accessor throws NotSupportedException in VSProjectProperties).
  3. Updated the MSBuildAnyProject constructor to override the evaluated Platform and Configuration with the values supplied to the task, if they are not null or empty.
In my testing using MSBuild on the command-line it seemed to work fine without any global properties being set (defaults to Debug) and when Release is explicitly set: /p:Configuration=Release.

If you need further assistance please ask, and please let me know if it works in Team Build.

I'll make sure that these updates are in the next build of 1.7.0 (presumably, a new version of Sandcastle will be released before 1.8.0 so expect the changes in 1.7.1).

Thanks,
Dave