Sandcastle (software)

Sandcastle is a documentation generator from Microsoft. It automatically produces MSDN-style code documentation out of reflection information of .NET assemblies and XML documentation comments found in the source code of these assemblies. It can also be used to produce user documentation from Microsoft Assistance Markup Language (MAML) with the same look and feel as reference documentation.

Sandcastle
Developer(s)Microsoft
Initial release2006 (2006)
Stable release
2.6.10621.1 / June 23, 2010 (2010-06-23)
Repositorygithub.com/EWSoftware/SHFB
Written inC#
Operating systemMicrosoft Windows
Platform.NET Framework
TypeDocumentation generator
LicenseMicrosoft Public License
Websitegithub.com/EWSoftware/SHFB

Overview

Sandcastle is a set of command line programs, configuration files, build components and XSLT files that work together to convert XML-based documentation into help topics that are fit for viewing in a help system. Sandcastle is typically used to automatically generate web-ready, XML-compliant HTML documentation in one of three built-in presentation styles from .NET assemblies and XML documentation files that are generated by compilers. The resulting HTML files are then used as input to tools such as the HTML Help Workshop to produce compiled help for distribution with the corresponding computer program.

Sandcastle currently features a lightweight graphical user interface (GUI) as an alternative to the MSBuild project, batch script and Windows PowerShell scripts that are also provided. Several community GUI tools are also available for Sandcastle, providing additional features and simplifying its usage.[1]

The Visual Studio SDKs for 2005 and 2008 include older CTP versions of Sandcastle,[2] although the latest release is available on GitHub.

Sandcastle tools

Sandcastle consists of several programs, not all of which are used in the typical help build process. Commonly used tools are listed below.

  • MrefBuilder uses Common Compiler Infrastructure (CCI) to reflect against managed assemblies and generate an output file.
  • XslTransform applies XSL transformations to an XML file. Typically, the specified input file is or derives from a file that is generated by MRefBuilder.
  • BuildAssembler executes a build component stack, once for each topic defined in an XML manifest. A build component stack is defined in an XML file with a .config extension. Sandcastle provides several build components that are used in build component stacks to perform tasks such as generating in-memory data indexes, resolving links, including shared content, executing XSL transformations and saving the final output to a file.

Community tools

Because in its current state Sandcastle by itself is rather complex to use, people have come up with tools and scripts that can automate the task for them. This section contains a list of such tools and scripts.

Output

Sandcastle produces XML-based HTML files in a chosen presentation style. (This does not mean, however, that the files are XHTML-compliant.) The HTML is defined by XSL transformation files that are included in the particular presentation style being used. A build normally uses only one presentation style at a time.

The HTML files that Sandcastle produces are either conceptual (user) documentation, being the result of a transformation from Microsoft Assistance Markup Language (MAML) topics, or they are reference documentation, which is automatically generated from reflection data and XML documentation comments. These two different types of HTML output share the same presentation style and may be compiled together to produce mixed user/reference documentation.

The processes for building conceptual documentation and reference documentation are similar, with one of the main differences being that conceptual documentation does not require the MRefBuilder program to be used.

Conceptual documentation consists of topics written using a MAML document type schema such as how to, walk-through, troubleshooting and several others. Sandcastle provides a conceptual build component stack (conceptual.config) that resolves shared content and links, and uses XSL files to transform MAML elements into HTML.

Reference documentation is generated automatically for managed Application Programming Interfaces (APIs) from reflection data and XML documentation comments. A "doc model" XSL transformation, provided by the chosen presentation style, is applied to define the files that will be generated. Sandcastle provides a reference build component stack (sandcastle.config) that builds in-memory indexes of the data, resolves shared content and links, and uses XSL to generate the final HTML output.

Compiled help

Sandcastle does not produce compiled help output itself (although, the HTML files that it produces can be used as input to HTML help compilers such as the HTML Help Workshop and Microsoft Help 2).

For example, the typical Help 1.x build process starts by running MrefBuilder.exe to produce an XML reflection file for one or more assemblies. The reflection file is then processed by the XslTransform.exe tool multiple times to apply various XSL transformations that add data such as a "doc model" and optional version information. Next, an XML-based topic manifest is generated and used by the BuildAssembler.exe program, which generates HTML topic files from the reflection data and XML documentation comments. An XML-based table of contents (TOC) file is generated and used by CHMBuilder.exe, along with the HTML files produced by BuildAssembler, to generate HTML Help Workshop project, index and TOC files. Finally, the HTML Help workshop is used to generate a compiled help file (.chm).

Some tools are used multiple times during a single build, like XslTransform and BuildAssembler. Depending upon the requirements, other tools and XSL transformations may be used at various stages during the process to modify Sandcastle's output.

Background

The Sandcastle application was developed by Microsoft to create a scalable and performing documentation generator for their API documentation. Microsoft released Sandcastle as a Community Technology Preview (CTP) version in July 2006, a few days before NDoc was declared dead [3][4] The author of NDoc, Kevin Downs, cited in an email sent through his mailing list reasons for discontinuing development of his popular tool as a lack of community support, both financially and as development contributions, an automated mail-bomb attack on his public email address and the NDoc2 mailing list address, and also his impression that Sandcastle "will become the de facto standard and that NDoc will slowly become a stagnant side-water."

Sandcastle averaged 217 downloads per day [5] during the month of September 2010, making it one of the top 25 most downloaded projects on CodePlex.

On June 6, 2008 the SandCastle project was removed from CodePlex website[6] after a discussion thread on the CodePlex site pointed out that source code was not available; despite CodePlex requiring this and the SandCastle project being touted as "open source".[7] On July 2 the project returned to CodePlex and the source code was published.[8]

History

  • July 29, 2006 the July 2006 CTP version was released, this version mainly focused on performance and scalability. No GUI was present yet, the application did not contain a feature to resolve GAC DLLs yet.
  • August 28, 2006 the August 2006 CTP version was released, the bugs fixed in this release seem to primarily for fixing crashes of the application. HTML output of the application is now compatible with Firefox. Some changes were made to the command line interface.
  • October 1, 2006 the September 2006 CTP version was released, bug fixes primarily seem to focus on fixing bugs in the output, and adding better support for some XML comment tags.
  • November 11, 2006 the November 2006 CTP version was released, along with bug fixes other items being supported are a few nDoc tags, and also transforms support Firefox.
  • December 10, 2006 the December 2006 CTP version was released, providing a DXROOT environment variable used by configuration files, an API "ripping" feature, pass-through HTML, and presentation updates that included support for Firefox in the VS 2005 style.
  • March 6, 2007 the March 2007 CTP version was released, adding 4 new and removing 3 XSL transformations, a batch build script and performance improvements.
  • March 17, 2007 the March 2007 CTP Technical Refresh version was released, fixing the "ripping" feature and a utility bug, and including a file that was missing from the previously released installer.
  • June 19, 2007 the June 2007 CTP version was released, providing an MSBuild project, a new version of the Common Compiler Infrastructure (CCI) reflection engine, a new presentation style named, "VS ORCAS", a new build component, new executable utilities, and several other enhancements.
  • June 27, 2007 the June 2007 CTP Refresh version was released, renaming the previously released "VS ORCAS" presentation style to "Hana" to prevent confusion since the Orcas Beta 2 and RTM documentation shipping in MSDN was going to continue to be built in the VS 2005 presentation style.
  • October 1, 2007 the September 2007 CTP version was released, with the first appearance of the CHMBuilder, VersionBuilder and DBCSFix tools, a Windows PowerShell build script, presentation style updates (most notably to the VS 2005 style), and without the .NET Framework reflection files that were normally included in previous installers.
  • October 30, 2007 the October 2007 CTP version was released, including the .NET Framework files that were missing from the previous release, a new conceptual documentation build process requiring Microsoft Assistance Markup Language (MAML) topics as input, and also improved Firefox support.
  • January 16, 2008 the Sandcastle 2.4.10115 version was released, being the first official non-CTP version of Sandcastle released to the web (RTW). An example graphical user interface (GUI) was provided, including an XSL transformation for Script# and the option to output an ASP.NET website.
gollark: The controller page code contains the SPUDNET key so probably not without removing that.
gollark: I'd have to ask heav.
gollark: Or recognition of common captive portal UIs and filling with junk data.
gollark: Solution: accursed DNS tunneling for limited remote access to operate those.
gollark: They can't be battery operated with the current protocol due to frequent ping requirements.

See also

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.