Help building without Sandcastle/DocProject installation

Topics: Features, General Discussion, General Questions, Sandcastle
Sep 11, 2007 at 10:09 AM
Now i can generate documentation for my project, but it requires explicit installation of Sandcastle and DocProject.
When building on build server, its desirable to minimize explicit installed products, and get all necessary tools from VCS during project checkout.
Can i use Sandcastle / DocProject such way?

Sep 11, 2007 at 10:30 AM

Sounds interesting, but how is that supposed to work? (I've never actually done that myself :)

AFAIK, you have to install Sandcastle in order to get the production tools and XSL transformations onto your system, and also the %DXROOT% environment variable. These are required by DocProject. But if you want more information on this you should ask Microsoft in the MSDN forums: Developer Documentation and Help System.

DocProject must be installed because it adds certain assemblies to the GAC, the .targets file to the bin folder, and creates the %DocProjectBuildPath% environment variable, which is also required (although, in the next release of DocProject 2008 the project templates will use the new MSBuild 3.5 Registry: property syntax so the environment variable will no longer be needed, and therefore will not be installed).

- Dave
Sep 11, 2007 at 10:48 AM
Well, i see, it is too difficult to avoid installation of Sandcastle/DocProject - too many links for environment (env.vars, registry, GAC)... :(

A lot more about my approach:

For example, i build MSI setup for my product with WiX, and WiX itself is not installed on build server - its just fetched from "vendors" SVN repository, with specified version. (See svn:externals)

MSBuild project file references to relative path ..\externals\WiX\wix.targets, and all works fine. Special MSBuild tasks assembly are located by relative path too.

So, there are always synchronized version of source code and WiX, and there are no need to any additional installs on build server - svn checkout and msbuild. And no WiX version conflicts possible with other projects, building on the same build server.

I wish to use the same approach to build help with Sandcastle, but is seems to be impossible :(
Sep 11, 2007 at 11:26 AM

Thanks for the information, it's an interesting approach.

You're right however that this won't work for DocProject because DocProject's assemblies aren't used just by MSBuild. They are also used from within Visual Studio (i.e., the Add-In and project templates) and the DocProject External UI, which means that the assemblies must be installed in a shared location - the GAC. Also, it's not just one assembly. The Sandcastle stuff is actually encapsulated in a plug-in, which also references another assembly with my HtmlEditor control (although that assembly isn't technically required for the build process). And if you're using the Sandcastle/Deployment Plug-in another assembly is required, on top of the actual DocProject assembly itself.

Ultimately, I think your WiX solution is probably useful for software that could just as easily be XCopy-deployed, although that's certainly not the case with DocProject as you mentioned.

I'm not familiar with Subversion, but I'll definitely check out svn:externals for more info anyway. If you have any more information or any ideas about how this could possibly work with DocProject then please let me know.