Sandcastle : Running Builds

Genereating Website for API documentation using Sandcastle

aram — Thu, 17 Jan 2008 09:09:00 GMT

In this blog on generating builds using Powershell, I provided details on generating a single command wrapper to build CHM and HxS files regardless of where the source assemblies and comments are located. This powershell script provided the following features:

Allows the build options to be read from a configuration file. Options specified on the command line override options defined in the configuration file.
Handles any number of target assemblies and comment files, including globbing.
Handles any number of dependencies.
Should work with .NET 2.0, 3.0, and 3.5.
Supports vs2005, prototype, and Hana presentation styles.
Provides hooks to add new presentation styles in the future, including user defined styles, and user defined function overrides.
The script is written for PowerShell 1.0.

Prerequisites

The build script has the following dependencies:

Latest release of Sandcastle from http://www.codeplex.com/sandcastle.
The DxRoot environment variable must point to the root of the Sandcastle installation.
To make it easier for the user, the PATH environment variable should contain the …/ProductionTools folder, which contains the scbuild.ps1 script.
.NET 2.0 for Sandcastle.
PowerShell 1.0, with the execution policy set to RemoteSigned or Unrestricted. [Note: In a future release we could Authenticode sign the script to make this unnecessary.]
hhc.exe to compile CHM files.
Hxcomp.exe to compile HxS files.

Running the Script

The scbuild.ps1 script can now be used to build a website, in addition to .chm and .hxs files. To build a website use the –BuildWebsite option. For example, to build a website with API documentation for an assembly named test.dll, with comments in comments.xml, use the following command:

scbuild –framework 2.0 –sources test.dll,comments.xml –BuildWebsite

The build result will be in test website. You can use the –name option to specify an output location and root name for the website.

Currently scbuild supports only the default presentation style: -style vs2005. Future versions may support other output styles.

The output from scbuild is designed to be integrated into an existing website. The master page, web.config file, and style sheet in the output directory are intended as a starting point for further customization. You will probably want to keep the contents of the icons and styles directories however, because they are used to give the generated API topics the vs2005 look-and-feel. All JavaScript functionality was disabled in this version, to minimize conflicts with the website the reference topics will be merged into.

Also note the contents of the web.config file, specifically the <globalization/> element. Make sure to copy the sample definition to your own website, to ensure that non breaking spaces get displayed properly.

The “api” directory contains one ASP.NET content file for each topic and a sitemap that you can merge into the sitemap of an existing website, as shown in the example. At runtime, the sample master page uses a tree view to display the sitemap and a simple content placeholder to display the topics.

To merge the output into your own website, you can copy the api, icons, and styles directories to the target website and include the sitemap into the master sitemap file as appropriate. Or you can use the –WebTemplate option to specify a user defined template that will be copied to the output directory, instead of the Sandcastle sample.

If you want to use the generated sitemap, include the following reference to the API topics in your own sitemap:

Further customization is possible through the –WebBuildConfig option, to specify a custom BuildAssembler config file.

For more information, please refer to the header of the scbuild.ps1 script, which shows a list of all available build options and short descriptions. Hope this helps.

Anand..

Building CHM using CHMBuilder

aram — Thu, 13 Sep 2007 08:55:00 GMT

Please see my blog about Sandcastle September 2007 release. With this release, we plan on shipping a new tool called CHMBuilder for CHM generation using Sandcastle.

What is CHMBuilder?

CHMBuilder is an executable that will be shipped under the Production Tools folder of Sandcastle. The HXS generation process in Sandcastle works much better than the CHM generation process. There are several reasons for this, but the central problem is that CHMs do not get the data to build TOC and indexes from the topic HTML files themselves. We have transforms under Production transforms folder that collect this data, but they are very slow ( http://blogs.msdn.com/sandcastle/archive/2007/02/28/sandcastle-performance-improvements-in-february-ctp.aspx) and are not localized

Given HXS-ready Sandcastle output, ChmBuilder will produce HHP, HHC, and HHK files, and transform the HXS-ready topic files to CHM-ready topic files. Using CHMBuilder the user would no longer have to do separate BuildAssembler runs to generate CHM’s and HXSs. This also solved the internal scenario for our team where we build CHM and HxS for many products.

CHMBuilder Usage:

ChmBuilder /html:htmlDirectory /toc:tocFile /project:projectName /lcid:languageId /out:outputDirectory

/html:htmlDirectory

Specify a html directory.

/project:projectName

Specify a project name.

/toc:tocFile

Specify a toc file.

/lcid:languageId

Specify a language id. If unspecified, 1033 is used. See chmbuilder.config for the list of languages.

/out:outputDirectory

Specify an output directory. If unspecified, CHM is used.

On input, htmlDirectory is a directory containing HTML topic files with XML data islands containing HXS metadata. The tocFile is the manifold TOC file, produced either using either the ReflectionToToc.xsl or DsTocToToc.xsl transforms.

Upon completion, the outputDirectory contains the files projectName.HHP, projectName.HHC, projectName.HHI, and a directory with the same name and as htmlDirectory containing topic files with the same names and contents as the input topic files, but stripped of HXS-specific elements.

CHMBuilder Details:

1. The HHP file produced references the HHC and HHK files produced, and the output topic directory. HHP file is generated with template read from config. Three items are replaced for a given project; they are {projectName}, {defaultTopic} and {language}.

2. The HHK entries are produced using the Term attributes on all <MSHelp:Keyword Index=”K” /> elements within the XML data island of all the topics.

3. The HHC file is produced using the structure defined in the tocFile, taking titles from the input topic files. If an <MSHelp:TOCTitle /> attribute is present, that title is used. Otherwise, the value in the HTML <title> element is used.

4. The output topic files do not contain the XML data island. All <MSHelp:link>linkText</MSHelp:link> elements are transformed into <span class=”nolink”>linkText</span>. Any other elements in the MSHelp namespace are removed. The topic documents are otherwise identical.

5. The input topic files are read with an XmlReader, and the output topic files are produced with an XmlWriter, for speed and low memory overhead.

6. The tool also successfully transforms topic files that do not appear in the TOC.

7. The tool supports htmlDirectorys with a directory substructure. The processing goes recursively through subdirectories and reproduces this structure in the output directory.

8. The tool supports Localization of TOC and Index. For HHK file, the encoding is “codepage” read from config file. For HHP file, the language option is set to “name” attribute from config.

9. The tool supports indented second level index. If there is a comma in K keyword, then only the second half of it will appear in index. Also this index entry is indented.

10. It also converts some special characters in index, eg: %3c (‘<’).

CHMBuilder Config file

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<languages>

<language id="1033" codepage="65001" name="0x409 English (United States)" />

<language id="2052" codepage="936" name="0x804 Chinese (PRC)" />

</languages>

<hhpTemplate>

<line>[OPTIONS]</line>

<line>Compatibility=1.1 or later</line>

<line>Compiled file={0}.chm</line>

<line>Contents file={0}.hhc</line>

<line>Index file={0}.hhk</line>

<line>Default Topic={1}</line>

<line>Full-text search=Yes</line>

<line>Language={2}</line>

<line>[FILES]</line>

<line>icons\*.gif</line>

<line>art\*.gif</line>

<line>media\*.gif</line>

<line>scripts\*.js</line>

<line>styles\*.css</line>

<line>html\*.htm</line>

<line>[INFOTYPES]</line>

</hhpTemplate>

</configuration>

Cheers.

Anand..

Documenting APIs with Sandcastle using Windows Powershell

aram — Wed, 12 Sep 2007 02:34:00 GMT

Please see my blog about Sandcastle Spetember 2007 release. With this release, we plan on shipping an example Windows powershell script to document APIs using Sandcastle.

Why Windows Powershell

I saw what Scot Hanselman did for Sandcastle with Powershell and got the inspiration for creating a Windows powershell script for Sandcastle. BTW you can view Scott's latest show on DNR TV about Windows powershell at http://www.dnrtv.com/default.aspx?showID=82.

I have details about this new scripr below. The script that will be shipped is called “scbuild.ps1” and provides the following features:

Provides a single command wrapper to build CHM and HxS files regardless of where the source assemblies and comments are located. For example, to build the sample project we ship with Sandcastle use the following command:

scbuild –buildchm -buildhxs –framework 2.0 –sources test.dll,comments.xml
Allows the build options to be read from a configuration file. Options specified on the command line override options defined in the configuration file.
Handles any number of target assemblies and comment files, including globbing.
Handles any number of dependencies.
Should work with .NET 2.0, 3.0, and 3.5.
Supports vs2005, prototype, and Hana presentation styles.
Provides hooks to add new presentation styles in the future, including user defined styles, and user defined function overrides.
The script is written for PowerShell 1.0.

Prerequisites

The build script has the following dependencies:

September 2007 release of Sandcastle.
The DxRoot environment variable must point to the root of the Sandcastle installation.
To make it easier for the user, the PATH environment variable should contain the …/ProductionTools folder, which contains the scbuild.ps1 script.
.NET 2.0 for Sandcastle.
PowerShell 1.0, with the execution policy set to RemoteSigned or Unrestricted. [Note: In a future release we could Authenticode sign the script to make this unnecessary.]
hhc.exe to compile CHM files.
Hxcomp.exe to compile HxS files.

Running the Script

To run the script, open a PowerShell window and run scbuild with the “appropriate” options. You’ll want to make sure that DxRoot points to the root folder of the Sandcastle installation and [optionally] that your PATH variable contains the ProductionTools folder. Internally all Sandcastle executables are referenced relative to DxRoot; setting PATH is only necessary to avoid having to type the entire path to scbuild each time.

NOTE: If you’ve just installed PowerShell to run this script, you have to give it permission to execute scripts on your machine. If you don’t, PowerShell will refuse to execute any scripts that haven’t been Authenticode signed. To change the execution policy, open a PowerShell window and type the following command:

set-executionpolicy RemoteSigned

This allows the shell to execute all local scripts, as well as signed remote scripts. The setting is persistent.

Once that’s done, you can run the script. For a synopsis of the command line options available, see the header of …/ProductionTools/scbuild.ps1. Most of the options should be pretty self explanatory from the synopsis. I’ll expand on a couple of the more advanced features here.

Using the –Config Option

The –config option allows you to specify the options you would normally type on the command line in a configuration file. You’ll want to use this feature to easily manage build configurations or if the command line is too long for the shell.

The config file is a PowerShell script and the command line options are exposed as variables in “Script:” scope. For example, with the following statements in a file named “testconfig.ps1”:

$BuildChm = $true

$BuildHxs = $true

$Framework = "2.0"
$Sources = "test.dll", "comments.xml"

You can then run the build with this command:

scbuild –config testconfig.ps1

Using the –Mixin Option

The –Mixin option allows you to override any of the functions defined in scbuild.ps1 and DocModel.ps1, except for Init(), which is called before the mixins are loaded. Like the config file, the mixin file is a PowerShell script. It gets loaded just after scbuild and the doc model have been initialized, but before any of the build commands are executed. You can use this feature to add new functionality or to change build details.

NOTE: This feature is experimental. Future versions of the build script may be quite different, and functions and variables that exist in this version may not be there in future versions. Anybody using this feature should expect breaking changes.

For example, to override the function that copies the CHM file to its final destination you could create a script file named “testmix.ps1”:

function CopyChmToOutputDir {

WriteInfo "copy chm file to output directory with date"
MakePath $OutputDir

copy-item –force "$TempDir\Output\$($Name).chm" "$($Name)-$([DateTime]::Now.ToString('yyMMdd'))"

}

To run the build command with this mixin use:

scbuild –buildchm -buildhxs –framework 2.0 –mixin testmix.ps1 –sources test.dll,comments.xml

When you run this command, the output file name would now include the current date: test-070910.chm.

New & Changed Files

scbuild.ps1 requires a number of support files, but touches only one previously existing file: …/Prototype/Transforms/utilities_reference.xsl. In that file, we removed the HTML 4.0 doc type declaration, because the output from the transforms is not valid HTML 4.0 and having the doc type causes validation errors later in the tool chain. Eventually, the transforms should be fixed to produce valid XHTML 1.0 transitional and then the doc type declaration should be added back in.

Also, each presentation now has a new BuildAssembler config file named Sandcastle-scbuild.config. The new config differs from the previous Sandcastle config in that it includes a different set of reflection and comment files. It is necessary to make the build script location independent, and to support any number of input files.

The doc model specific scripts include a shared script: …/Presentation/Shared/SharedDocModel.ps1. This script defines functions that are the same for all doc models.

Note that the doc model specific script must be called DocModel.ps1, and no other directory under …/Presentation that does not define a doc model must have a DocModel.ps1 file in it. The presence of this file is used to determine if a particular style specified on the command line is a doc model, or just some other support directory like “Shared.” This allows us to add/delete doc models without touching the build script itself, and to ship different configurations that include only a subset of the doc models. It also allows the user to define a custom doc model.

Futures

Better error handling when intermediate build steps fail.
The script currently rebuilds all of the framework and dependency reflection data each time it is executed. This makes it easy to handle different frameworks and doc models. In a future version we can speed things up by keeping a copy of the data around and only rebuilding it on request.

Hope you all like this new script. Cheers.

Anand..

Integrating Sandcastle doc generation to your NAnt builds

aram — Fri, 27 Oct 2006 21:42:00 GMT

NAnt is an open source software tool for automating software build processes. It is based on Apache Ant and targeted at the .NET environment whereas Ant is a more generic cross-platform tool principally used by Java programmers . Brett Burch from http://www.brettresources.net/...(read more)

Joe in Iowa – A Sandcastle Scenario

aram — Sun, 06 Aug 2006 22:56:00 GMT

This post provides steps to create CHM using Sandcastle. Some of the users have automated these steps. Mikael Söderström has a "Sandcastle Helper" here, Ashley van Gerven has a batch script available here and Scott Hanselman's has power shell script available here. Frank Kroondijk has created a Sandcastle VS 2005 add-in here.

Anders Ljusberg has some interesting finds about Sandcastle here.

Sandcastle installation adds the various tools to your path. Alternatively in the Sandcastle Examples directory, invoke setPath.bat to add the sandcastle tools to your path. Then create a subdirectory for your project and cd into it. Several of the command-line arguments and batch files referenced in the following instructions use relative path expressions that assume this directory structure. You are welcome to use a different directory structure, but if you do so you will need to change those relative path expressions.

In this post I wanted to capture “Joe in Iowa”, an user scenario for Sandcastle and provide some additional details.

Joe in Iowa: “I’m one of four developers on our team creating reusable web controls. We write our own documentation inline using C# XML documentation comments. It’s really convenient and we can see our real documentation in seconds using Sandcastle. Our customers really love the MSDN-like documentation.”

Consider the case of Joe generating documentation for a managed assembly A.dll. Suppose A.dll depends on assemblies B.dll and C.dll. (That is, classes in A.dll inherit from types in B.dll and C.dll, or APIs in A.dll use types in them as parameter and return types.).

The first step in the sandcastle process is to generate reflection data files for the assemblies. To generate a reflection data file for A.dll Joe executes the following command:

MRefBuilder A.dll /dep:B.dll,C.dll /out:reflection.org

Joe can also use wildcards. For example, if Joe’s assemblies to document are in the dll subdirectory and their dependencies are in the dep subdirectory, he can generate reflection data like this:

MRefBuilder dll\*.dll /dep:dep\*.dll /out:reflection.org

The output of MRefBuilder contains information about each API in the reflected assemblies.

If Joe is not sure on which assemblies A.dll depends, he can just go ahead an invoke MRefBuilder with A.dll. If it finds that it needs another one, it will emit an error message identifying the additional dependency assembly that it requires. Joe does not need to provide core .NET Framework assemblies (e.g. mscorlib.dll) that an assembly depends on; MRefBuilder will fetch those from your .NET Framework installation directory.

The reflection information file contains information on each API that MRefBuilder found, but to generate documentation Joe needs a file that contains information on each topic that will appear in his documentation. To generate such a file, Joe needs to apply a few transformations:

XslTransform ..\..\ProductionTransforms\AddOverloads.xsl reflection.org |

XslTransfrom ..\..\ProductionTransforms\AddGuidFilenames.xsl

/out:reflection.xml

These transforms add pseudo-API topics corresponding to overload pages and information about the name of the file in which the topic will be stored. (Why not have MRefBuilder generate this information directly? We wanted to allow the “documentation model” to change without having to change the “reflection step”. If someone decides on documentation model without overloads, or wants to change the file naming convention, that shouldn’t require changing the reflection process.)

The next step in the sandcastle process is to use the reflection data file to generate a manifest of topics to be generated. This is done by applying a transform to the reflection data:

XslTransform ..\..\ProductionTranforms\ReflectionToManifest.xsl reflection.xml /out:manifest.xml

Joe examines the manifest, and notices it is a very simple XML file that lists the ID of each topic to be generated. (If you ever want to build just a handful of topics, it should be easy to construct such a manifest by hand. If you ever develop a complex process that might require you to generate a subset or superset of the topics that this transform produces, it should be a straightforward task to automate the generation of the corresponding manifest.)

Joe is ready to generate topic pages. He needs to create a directory structure to contain them and the associated image, script, and style files. Sandcastle provides a script that creates this structure. Joe executes this script and creates an output directory structure:

..\copyOutput.bat

Now, Joe is ready to generate HTML documentation pages. To do so, he invokes the BuildAssembler tool using the following command:

BuildAssembler /config:..\..\Presentation\configuration\sandcastle.config

manifest.xml

You should see informational messages indicating that BuildAssembler is loading data, then generating topics pages. The output pages will appear in the Output\html subdirectory. Joe opens them in a web browser and peruses the fruits of his labor.

BuildAssembler is the heart of the sandcastle documentation process; all the steps Joe has taken up to now just generate files containing the information that BuildAssembler needs. These files are referenced in the sandcastle.config configuration file.

Packaging: Most documentation is delivered as CHM/HxS files. This section explains how to package the output of the sandcastle tool-chain into such a container. The necessary help compilers are not a part of sandcastle, but are available from:

Microsoft HTML Help 1.x Compiler - The HTML Help Compiler for HTML Help 1.x can be downloaded as part of the Microsoft HTML Help Workshop from msdn.microsoft.com

Microsoft Help 2.0 Compiler - The Help Compiler for Help 2 is part of the Microsoft Visual Studio 2003 .NET Help Integration Kit.

hhc (HTML Help 1.x Compiler):

The CHM compiler hhc.exe requires as input a project (HHP) file and a table of contents (HHC) file. Joe can generate a custom HHP or can copy the HHP template provided by Sandcastle:

copy ..\..\Presentation\chm\test.hhp Output

Joe can execute HHC from the topic data file via a transformation:

XslTransform ..\..\ProductionTransforms\ReflectionToChmContents.xsl

reflection.xml /out:Output\test.hhc

After generating these file, Joe can run the CHM compiler:

cd Output

and then

hhc.exe test.hhp

This creates the file test.chm containing his documentation.

HxComp (Microsoft Help 2.0 Compiler):

HxComp compiles the Sandcastle target files into an HxS/HxI pair of files. The HxS generation requires a few more project definition files than the CHM case. Sandcastle provides these definition files. Joe begins by executing a script to copy these definition files in to the output directory:

..\copyHavana.bat

Like the CHM case, though, Joe must create file that defines the packaged table of contents (HxT). This is accomplished by a simple transform of the reflection data file.

XslTransform ..\..\ProductionTransforms\ReflectionToHxSContents.xsl reflection.xml /out:Output\test.HxT

Finally, Joe invokes the Help 2.0 compiler to create an HxS file.

cd Output

and then

hxcomp –p test.HxC –l test.log

This creates the file test.hxs containing his documentation.

A few faqs about Sandcastle

aram — Sun, 30 Jul 2006 20:17:00 GMT

I’m super excited about the response to the Sandcastle CTP launch. Much of the response has been positive, and folks have asked some great questions. Let me try to address a few of the common questions people have about the site:

Where can post Sandcastle related questions?
Please post all Sandcastle related questions and discussions at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=66&SiteID=1. Please use Sandcastle: at the beginning of your questions when posting questions at this forum. You can also send feeback and bugs to sandchlp@microsoft.com.

Is Sandcastle used by Microsoft for their API documentation?
Yes. This CTP version has a new architecture and has reduced the .Net Framework build time from 10 plus hours during VS 2005 ship cycle to 30 minutes. For the current CTP release the focus was on scalability and performance.

When can we get better documentation?
Scott Hanselman's provides his honest opinion about this CTP release documentation here. Better documentation with architectural overview is on it's way and I will post them shortly.

Will there be an SDK for Sandcastle?
Most likely; Sandcastle will be a part of VS SDK release. For the current CTP release the focus was on scalability and performance.

Will Sandcastle have a GUI and viewer?
Not for Version 1.0. Several customer written GUIs are available at http://www.sandcastledocs.com.

Will there be another CTP release?
Yes; We plan to few CTP releases before Sandcastle 1.0 RTW.

How can change author comments from comments.xml to a different file name?
Please look at the following section in sandcastle.config file:

<component type="Microsoft.Ddue.Tools.CopyFromIndexComponent" assembly="..\..\ProductionTools\BuildComponents\BuildComponents.dll">
         <index name="comments" value="/doc/members/member" key="@name" cache="100">
           <data files="comments.xml" />
           <data files="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\*.xml" />
         </index>

The comments.xml in sandcastle.config file can be replaced with any other file name such as foo.xml or multiple xml files with *.xml.

How can I use MrefBuilder with /dep option?
The dependencies can be at a separate folder called dependency.
MrefBuilder can be invoked with the /dep switch as below:

MRefBuilder foo.dll /out:reflection.org /dep:dependency\*.dll

MrefBuilder also takes wildcards like the following:

MRefBuilder dll\*.dll /out:reflection.org /dep:dependency\*.dll

That is, if I put all the assemblies I want to reflect over in a directory named dll and tell it to get them from there.

Is it possible to include private members in the output from Sandcastle? If not will this be added as an option on a later CTP?
It's not possible to document private members using the July CTP version of Sandcastle. However we plan to add couple switches to the syntax invocation for MRefBuilder is as follows:

MRefBuilder.exe dll /dep:dep /out:out /internal-

The Boolean /internal option enables documentation of private APIs to be produced for the internal consumption of development teams.

Does Sandcastle resolve reference to GAC DLLs?
We do not resolve references to GAC. You have to use the /dep switch and refernce those dependent assemblies. Resolving refence to GAC is a feature request that we did not get to in this CTP release.

Can the build steps be automated?
Yes. We will be releasing automated scrips in our future releases. Mikael Söderström has a "Sandcastle Helper" here, Ashley van Gerven has a batch script availabe here and Scott Hanselman's has power shell script availabe here.

That's all for now...more coming soon. I'm trying to read as many blog posts and comments as possible to collect feedback and questions about the site, but if you have particular questions you'd like to make sure I address, please post them here!

Anand..

Creating a Chm build using Sandcastle

aram — Sat, 29 Jul 2006 10:12:00 GMT

Here are the steps to create a Chm build using Sandcastle. Please see the atatchment for the steps in text format.

Prerequisites:

1. .Net Framework 2.0

2. For Chm generation download HTML Help Workshop - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hwMicrosoftHTMLHelpDownloads.asp

How do Reference Build From /// Comments using Sandcastle V2.0:

Sandcastle can read authored triple-slash comments embedded in source files.

Sandcastle by default is installed at c:\Program files\Sandcastle. Open a command prompt and type the following:

cd \Program Files\Sandcastle\Examples\Sandcastle

In this directory, you will find only a single C# file called test.cs under Examples\sandcastle directory.

Begin by compiling the C# file and extracting the /// comments.

csc /t:library /doc:comments.xml test.cs

This creates not only test.dll, but also comments.xml file that contains the extracted /// comments

Next, run MRefBuilder:

MRefBuilder test.dll /out:reflection.org

Transform the output

For building using VS2005 transforms please use the following:

XslTransform /xsl:"..\..\ProductionTransforms\ApplyVSDocModel.xsl" reflection.org /xsl:"..\..\ProductionTransforms\AddFriendlyFilenames.xsl" /out:reflection.xml

For building using prototype transforms please use the following:

XslTransform /xsl:..\..\ProductionTransforms\ApplyPrototypeDocModel.xsl reflection.org /xsl:..\..\ProductionTransforms\AddGuidFilenames.xsl /out:reflection.xml

Generate a topic manifest

XslTransform /xsl:..\..\ProductionTransforms\ReflectionToManifest.xsl reflection.xml /out:manifest.xml

Create an output directory structure

For building using VS2005 transforms please use the following:

call ..\..\Presentation\vs2005\copyOutput.bat

For building using prototype transforms please use the following:

call ..\..\Presentation\Prototype\copyOutput.bat

Run BuildAssembler using the sandcastle component stack (Note: We are providing VS 2005 transforms under Presentation/VS2005 folder and the transforms shipped with the previous versions under Presentation/Prototype folder. For building VS2005 format please use sandcastle.config file from C:\Program Files\Sandcastle\Presentation\vs2005\Configuration folder as it uses shared content from C:\Program Files\Sandcastle\Presentation\vs2005\Content and transforms from C:\Program Files\Sandcastle\Presentation\vs2005\Transforms)

BuildAssembler /config:sandcastle.config manifest.xml

to generate topic files in HTM.

Generate HTML help project

XslTransform /xsl:..\..\ProductionTransforms\ReflectionToChmProject.xsl reflection.xml /out:Output\test.hhp

Generate intermediate table of contents

For building using VS2005 transforms please use the following:

XslTransform /xsl:..\..\ProductionTransforms\createvstoc.xsl reflection.xml /out:toc.xml
For building using prototype transforms please use the following:
XslTransform /xsl:..\..\ProductionTransforms\createPrototypetoc.xsl reflection.xml /out:toc.xml

Generate HTML help project information

XslTransform /xsl:..\..\ProductionTransforms\TocToChmContents.xsl toc.xml /out:Output\test.hhc

XslTransform /xsl:..\..\ProductionTransforms\ReflectionToChmIndex.xsl reflection.xml /out:Output\test.hhk

Run hhc (HTML Help 1.x Compiler) to generate Chm, hhc compiles the Sandcastle target files into a CHM file.

hhc output\test.hhp

Bugs/Feature Requests:

Please send you bugs, feature requests, questions and feedback to sandchlp@microsoft.com