SHFB Wiki & Documentation Rss Feed

Updated Wiki: Future Enhancements and Features

EWoodruff — Mon, 18 Mar 2013 01:52:03 GMT

Below is a list of future enhancements and features for the Sandcastle tools and the Sandcastle Help File Builder. No planned release dates have been set for these items. Each item may be implemented all at once or a little at a time depending on its scope and complexity. If you'd like to comment on any of these, please do so on the related work item page (see the links below) or, to make additional suggestions, please start a new discussion.

Sandcastle Tools

Investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread-safe though. Possible changes and issues:
- Add a configuration property to enable parallel builds but default to the current synchronous build behavior.
- All build components would need an overriden virtual property to indicate if they support parallel execution. The default if not overridden would be false. Each build component and syntax generator would need checking to make sure it is thread-safe. For components that contain nested components, they would need to check each nested component too.
- Concurrent updates to static members. Use thread-safe constructs where needed.
- Use of non-thread-safe objects like the code colorizer. Wrap them in ThreadLocal<T>?
- Copying of content files. Track source and destination files to copy in thread-safe constructs. Then, when the component is disposed of, copy the content.
- http://shfb.codeplex.com/workitem/33859

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add more information to the Sandcastle tools help file that describes the various tools and how they work. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Sat, 09 Mar 2013 21:39:13 GMT

Sandcastle Tools

Investigate improving the performance of BuildAssembler. Things to consider:
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add more information to the Sandcastle tools help file that describes the various tools and how they work. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 03 Mar 2013 02:22:48 GMT

Sandcastle Tools

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add more information to the Sandcastle tools help file that describes the various tools and how they work. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 03 Mar 2013 02:20:48 GMT

Sandcastle Tools

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add more information to the Sandcastle tools help file that describes the various tools and how they work. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 23 Dec 2012 20:11:45 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add more information to the Sandcastle tools help file that describes the various tools and how they work. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Documentation

EWoodruff — Sun, 16 Dec 2012 21:59:45 GMT

Installation and Usage

Download the latest release, extract it to a folder, and then run SandcastleInstaller.exe to run the guided installation of Sandcastle, the various extra items from the Sandcastle Styles project, and the Sandcastle Help File Builder.

See the Installation Instructions topic for more information about the required set of additional tools.

If you are new to Sandcastle and the help file builder, see the topics in the Getting Started section to get familiar with it, set up your projects to produce XML comments, and create a help file project. A full copy of the help file is also included with the installer and a shortcut to it can be found in the Sandcastle Help File Builder folder in the Start | All Programs menu.

Viewing Downloaded Help Files

The help files contained in the project downloads may need to be unblocked before you can view their content. If you do not see any information in the content pane after opening a help file, do the following:

Copy the help file to your hard drive and open it from there. Trying to view a help file from a network share can cause the content to be blocked.
If a security dialog appears asking if you want to open the file, uncheck the "Always ask before opening this file" checkbox.
If the file is still blocked, open Windows Explorer, right-click the CHM file, select Properties, and then click the Unblock option.
Apply the file property changes and open the help file again.

Online Help and Guides

Future Enhancements

For a list of planned future enhancements and features, see the Future Enhancements and Features page.

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 16 Dec 2012 21:30:22 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add more information to the Sandcastle tools help file that describes the various tools and how they work. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages). http://shfb.codeplex.com/workitem/33232

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Tue, 27 Nov 2012 03:06:04 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add a help file for the Sandcastle tools that describes the various tools and how they work and also provides a location to place the version history for them. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages). http://shfb.codeplex.com/workitem/33232

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Mon, 19 Nov 2012 01:09:18 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

Perhaps update the tools to enable them to run as MSBuild tasks. Also, there are a lot of obsolete files that should be removed (i.e. Microsoft-specific configuration files that serve no apparent useful purpose). If possible, update the Sandcastle tools and build scripts to utilize a modified version of the presentation style definition file. http://shfb.codeplex.com/workitem/33373

As time permits, add a help file for the Sandcastle tools that describes the various tools and how they work and also provides a location to place the version history for them. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Add the ability to preview the referenced code snippets in the Topic Previewer. http://shfb.codeplex.com/workitem/32897

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages). http://shfb.codeplex.com/workitem/33232

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Mon, 22 Oct 2012 22:24:43 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

As time permits, add a help file for the Sandcastle tools that describes the various tools and how they work and also provides a location to place the version history for them. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Factor the presentation style information out into a configuration file. This would eliminate the dependency SHFB has on the presentation style names and locations and would make adding new or custom presentation styles much easier. If this works out, it may be possible to push this feature down into the Sandcastle tools as well. http://shfb.codeplex.com/workitem/33229

Add the ability to preview the referenced code snippets in the Topic Previewer. http://shfb.codeplex.com/workitem/32897

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages). http://shfb.codeplex.com/workitem/33232

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 14 Oct 2012 01:22:58 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

In BuildAssembler, add a message logging overload that takes the topic key. This would be useful for warning and error messages so that the topic key is reported and you don't have to turn on full logging to find the topic in which it occurred. Also, modify the message logging methods to take a params parameter for easier formatting of message with a list of parameters. http://shfb.codeplex.com/workitem/33221

Have the TransformComponent raise a BuildAssembler.ComponentEvent passing the ID and topic as event args to allow other components that have already been executed earlier in the stack to modify the topic post-transform. This would eliminate the need for a partnered post-transform component as the components such as CodeBlockComponent could add their additional stuff in their event handler. http://shfb.codeplex.com/workitem/33222

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Investigate whether or not a folder name can safely be introduced into the GUID and hashed member name naming methods to reduce the number of files in the root HTML output folder. http://shfb.codeplex.com/workitem/33058

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

As time permits, add a help file for the Sandcastle tools that describes the various tools and how they work and also provides a location to place the version history for them. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Factor the presentation style information out into a configuration file. This would eliminate the dependency SHFB has on the presentation style names and locations and would make adding new or custom presentation styles much easier. If this works out, it may be possible to push this feature down into the Sandcastle tools as well. http://shfb.codeplex.com/workitem/33229

Create a code block component in Sandcastle that contains just the stuff necessary to normalize the whitespace and import code from external files. Add title attribute support to the XSL transformations in each presentation style. The SHFB code block component could then be reduced to just colorization. That would allow the removal of the title, Copy Code stuff, and presentation style specific restructuring code and allow the whole implementation to be greatly simplified. The code colorizer build component could then function with any presentation style, existing or future, without change. http://shfb.codeplex.com/workitem/33230

Add the ability to preview the referenced code snippets in the Topic Previewer. http://shfb.codeplex.com/workitem/32897

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages). http://shfb.codeplex.com/workitem/33232

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Documentation

EWoodruff — Sun, 14 Oct 2012 01:16:17 GMT

Installation and Usage

Viewing Downloaded Help Files

Copy the help file to your hard drive and open it from there. Trying to view a help file from a network share can cause the content to be blocked.
If a security dialog appears asking if you want to open the file, uncheck the "Always ask before opening this file" checkbox.
If the file is still blocked, open Windows Explorer, right-click the CHM file, select Properties, and then click the Unblock option.
Apply the file property changes and open the help file again.

Future Enhancements

For a list of planned future enhancements and features, see the Future Enhancements and Features page.

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 14 Oct 2012 01:14:45 GMT

Sandcastle Tools

See if there is a way to improve the keyword index in Help 1 and Website output so that member names common to multiple classes are differentiated in the index. http://shfb.codeplex.com/workitem/32262

In BuildAssembler, add a message logging overload that takes the topic key. This would be useful for warning and error messages so that the topic key is reported and you don't have to turn on full logging to find the topic in which it occurred. Also, modify the message logging methods to take a params parameter for easier formatting of message with a list of parameters. http://shfb.codeplex.com/workitem/33221

Have the TransformComponent raise a BuildAssembler.ComponentEvent passing the ID and topic as event args to allow other components that have already been executed earlier in the stack to modify the topic post-transform. This would eliminate the need for a partnered post-transform component as the components such as CodeBlockComponent could add their additional stuff in their event handler. http://shfb.codeplex.com/workitem/33222

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components. http://shfb.codeplex.com/workitem/33223

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.
- http://shfb.codeplex.com/workitem/33224

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages. http://shfb.codeplex.com/workitem/33225

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle. http://shfb.codeplex.com/workitem/33226

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page. http://shfb.codeplex.com/workitem/33227

As time permits, add a help file for the Sandcastle tools that describes the various tools and how they work and also provides a location to place the version history for them. http://shfb.codeplex.com/workitem/33228

Sandcastle Help File Builder

Factor the presentation style information out into a configuration file. This would eliminate the dependency SHFB has on the presentation style names and locations and would make adding new or custom presentation styles much easier. If this works out, it may be possible to push this feature down into the Sandcastle tools as well. http://shfb.codeplex.com/workitem/33229

Create a code block component in Sandcastle that contains just the stuff necessary to normalize the whitespace and import code from external files. Add title attribute support to the XSL transformations in each presentation style. The SHFB code block component could then be reduced to just colorization. That would allow the removal of the title, Copy Code stuff, and presentation style specific restructuring code and allow the whole implementation to be greatly simplified. The code colorizer build component could then function with any presentation style, existing or future, without change. http://shfb.codeplex.com/workitem/33230

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file. http://shfb.codeplex.com/workitem/33231

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages). http://shfb.codeplex.com/workitem/33232

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation. http://shfb.codeplex.com/workitem/33233

Updated Wiki: Home

EWoodruff — Sun, 14 Oct 2012 00:12:39 GMT

Welcome to the Sandcastle Help File Builder Project

This project is composed of two separate parts that work together: the Sandcastle tools and the Sandcastle Help File Builder. The Sandcastle tools are used to create help files for managed class libraries containing both conceptual and API reference topics. API reference topics are created by combining the XML comments that are embedded in your source code with the syntax and structure of the types which is acquired by reflecting against the associated .NET Framework assembly. Conceptual topics are created by converting XML documents that you author containing Microsoft Assistance Markup Language (MAML). The Sandcastle tools are command-line based and have no GUI front-end, project management features, or an automated build process.

The Sandcastle Help File Builder was created to fill in the gaps, provide the missing NDoc-like features that are used most often, and provide standalone GUI and command line based tools to build a help file in an automated fashion. A Visual Studio integration package is also available for it so that help projects can be created and managed entirely from within Visual Studio.

Sandcastle was originally created by Microsoft back in 2006. The last official release from Microsoft occurred in June 2010. Until October 2012, it was hosted at the Sandcastle project site on CodePlex. In October 2012, Microsoft officially declared that they were ceasing support and development of Sandcastle. The Sandcastle tools have been merged into the Sandcastle Help File Builder project and all future development and support for them will be handled at this project site. The Sandcastle tools themselves remain separate from and have no dependency on the help file builder. As such, they can be used in a standalone fashion with your own scripts and build tools if that is your preference.

See the Installation Instructions for information about the required set of additional tools that need to be installed, where to get them, and how to make sure everything is configured correctly. The guided installer also provides information on the necessary tools and walks you through the installation steps.

If you are new to Sandcastle and the help file builder, see the topics in the Getting Started section to get familiar with it, set up your projects to produce XML comments, and create a help file project.

Future Enhancements

For a list of planned future enhancements and features, see the Future Enhancements and Features page.

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Future Enhancements and Features

EWoodruff — Sun, 14 Oct 2012 00:10:07 GMT

Sandcastle Tools

In BuildAssembler, add a message logging overload that takes the topic key. This would be useful for warning and error messages so that the topic key is reported and you don't have to turn on full logging to find the topic in which it occurred. Also, modify the message logging methods to take a params parameter for easier formatting of message with a list of parameters.

Have the TransformComponent raise a BuildAssembler.ComponentEvent passing the ID and topic as event args to allow other components that have already been executed earlier in the stack to modify the topic post-transform. This would eliminate the need for a partnered post-transform component as the components such as CodeBlockComponent could add their additional stuff in their event handler.

Expose as public many of the internal BuildAssembler-related classes used for stuff like target info. That will make it easier to reuse the classes in third-party components and third-party components derived from existing Sandcastle build components.

Investigate improving the performance of BuildAssembler. Things to consider:
- Sharing information between build components that use the same info rather than loading it again.
- Use pre-built cache files to save on initialization time.
- Use pre-built cache files to load information on demand to reduce memory usage.
- Longer term, investigate the possibility of having BuildAssembler build topics in parallel. That would require that all build components in the stack are thread safe though.

Remove the remaining branding stuff from the VS2010 style and SHFB. Branding support seemed like a good idea but with the changes in HV2, that is not the case and it has proven to be more trouble than it was worth. Sandcastle output requires some level of self-branding as non-self-branded content would not be able to use any custom scripts and stylesheets used for things like code colorization or other such features added by custom build components that rely on them. Supporting alternate branding packages doesn't seem to make sense as that's what presentation styles are for. In short, it makes better sense to treat all Sandcastle presentation styles as self-branded and remove the use of branding packages.

Create an Open XML presentation style with any related build components that outputs the help as an Open XML document. The resulting output document should be readily convertible to other formats such as PDF without having to add additional presentation styles or conversion tools to Sandcastle.

Create an MSDN Lightweight presentation style for website output that mimics the current MSDN website pages with the TOC info in each page.

As time permits, add a help file for the Sandcastle tools that describes the various tools and how they work and also provides a location to place the version history for them.

Sandcastle Help File Builder

Factor the presentation style information out into a configuration file. This would eliminate the dependency SHFB has on the presentation style names and locations and would make adding new or custom presentation styles much easier. If this works out, it may be possible to push this feature down into the Sandcastle tools as well.

Create a code block component in Sandcastle that contains just the stuff necessary to normalize the whitespace and import code from external files. Add title attribute support to the XSL transformations in each presentation style. The SHFB code block component could then be reduced to just colorization. That would allow the removal of the title, Copy Code stuff, and presentation style specific restructuring code and allow the whole implementation to be greatly simplified. The code colorizer build component could then function with any presentation style, existing or future, without change.

Update MRefBuilder to support the Visibility options from SHFB directly. This would be more efficient as the unwanted members could be stripped during the reflection phase rather than after the fact which requires loading the reflection data XML file.

Move some of the SHFB build components that aren't tied to SHFB such as the IntelliSenseComponent, ShowMissingComponent, etc. into Sandcastle along with any related resource items (i.e. Show Missing messages).

Add a transformation to match the SHFB hashed member naming option method. That would get rid of the need to load the reflection file in SHFB after applying the doc model transformation.

Updated Wiki: Documentation

EWoodruff — Sat, 13 Oct 2012 21:03:21 GMT

Installation and Usage

Viewing Downloaded Help Files

Copy the help file to your hard drive and open it from there. Trying to view a help file from a network share can cause the content to be blocked.
If a security dialog appears asking if you want to open the file, uncheck the "Always ask before opening this file" checkbox.
If the file is still blocked, open Windows Explorer, right-click the CHM file, select Properties, and then click the Unblock option.
Apply the file property changes and open the help file again.

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Home

EWoodruff — Sat, 13 Oct 2012 21:01:00 GMT

Welcome to the Sandcastle Help File Builder Project

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Home

EWoodruff — Sat, 13 Oct 2012 20:56:41 GMT

Welcome to the Sandcastle Help File Builder Project

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Home

EWoodruff — Sat, 13 Oct 2012 20:53:54 GMT

Welcome to the Sandcastle Help File Builder Project

This project is composed of two separate parts that work together: the Sandcastle tools and the Sandcastle Help File Builder. The Sandcastle tools are used to create help files for managed class libraries containing both conceptual and API reference topics. API reference topics are created by combining the XML comments that are embedded in your source code with the syntax and structure of the types which is acquired by reflecting against the associated .NET Framework assembly. Conceptual topics are created by converting XML documents that you author containing Microsoft Assistance Markup Language (MAML). The Sandcastle tools are command-line based and have no GUI front-end, project management features, or an automated build process.

The Sandcastle Help File Builder was created to fill in the gaps, provide the missing NDoc-like features that are used most often, and provide standalone GUI and command line based tools to build a help file in an automated fashion. A Visual Studio integration package is also available for it so that help projects can be created and managed entirely from within Visual Studio.

Sandcastle was originally created by Microsoft back in 2006. Until October 2012, it was hosted at the Sandcastle project site on CodePlex. The last official release from Microsoft occurred in June 2010. In October 2012, Microsoft officially declared that they were ceasing support and development of Sandcastle. The Sandcastle tools have been merged into the Sandcastle Help File Builder project and all future development and support for them will be handled at this project site. The Sandcastle tools themselves remain separate from and have no dependency on the help file builder. As such, they can be used in a standalone fashion with your own scripts and build tools if that is your preference.

See the Installation Instructions for information about the required set of additional tools that need to be installed, where to get them, and how to make sure everything is configured correctly. The guided installer also provides information on the necessary tools and walks you through the installation steps.

If you are new to Sandcastle and the help file builder, see the topics in the Getting Started section to get familiar with it, set up your projects to produce XML comments, and create a help file project.

Other Resources

Sandcastle Help File Builder - Benefits and Features
Sandcastle Help File Builder Overview
Visual Studio Integration Package
Links to Resources
Version History
Make a Donation to Support the Project

Updated Wiki: Sandcastle 2.7.1.0 Release Notes

EWoodruff — Sat, 13 Oct 2012 02:16:35 GMT

Installation Issues

IMPORTANT: The new release uses a brand new MSI installer. As such, you must manually remove Sandcastle releases older than v2.7.0.0 using the Add/Remove Programs or Programs and Updates option in the Control Panel. In addition, you should check for and remove the old Sandcastle folder (i.e. C:\Program Files (x86)\Sandcastle) if it still exists after removal to delete any old patch files that could interfere with the new release.

General Changes

Added "/arg:project=Project" to the Generic.targets file in the Reflection target to include a root namespace container in the manifest. This works around an issue with the web output from the example GUI failing if there is more than one namespace in the documented assemblies.

Merged changes from Dany R. into the HTML to MAML Converter to support image alignment, topic ID and revision number metadata, and optional movement of leading topic text into the introduction element.

Thanks to Alex Sherman and Sergey Zhurikhin for the Russian translations of the Sandcastle resource item files that have been added to the language pack.

MRefBuilder

Added code to Duplicator.VisitTypeReference() in MRefBuilder so that it doesn't get stuck in an endless loop when a type contains a nested type that itself implements a nested type from within the containing type.

Added a check condition to MRefBuilder in RecordExtensionMethods() to prevent a crash in an odd case where a potential extension method has no parameters.

Added support to MRefBuilder for defining assemblies to ignore if unresolved. This is useful for ignoring assemblies that cannot be resolved for which you do not have a copy such as the Crystal Reports BusinessObjects.Licensing.KeycodeDecoder assembly. See the MRefBuilder.config file for an example definition.

Added a new Frameworks.xml file for MRefBuilder to use in loading framework assembly information. This new style of framework definition is enabled by using the framework and version attributes on the platform element in the MRefBuilder.config file. This ensures that the reflection information is accurate for the selected framework type and version. The framework and version attribute values correspond to one of the framework sets defined in the Frameworks.xml file. Using this method allows for automatic referencing of core framework assemblies as well as automatic binding redirection from older versions to the defined version for all assemblies in the framework's assembly set (i.e. automatically redirecting the RIA SDK dependencies from the Silverlight 4 versions to the Silverlight 5 versions when producing information for a Silverlight 5 project that uses the RIA SDK). In other words, you no longer need to specify the dependencies or define binding redirections for the standard framework assemblies.

XSLTransform

Added UnauthorizedAccessException check in XSLTransform to ignore temporary files that may be locked when attempting to delete them (i.e. virus scanners have them open).

Build Components

Made a couple of fixes to BrandingComponent that allows the content to show up in the Help Viewer 2.0 that comes with Visual Studio 2012.

In the MSHCComponent, removed the ContentType metadata as it's output by the XSL transformations. Changed "SelfBranded" to "Microsoft.Help.SelfBranded" for Help Viewer 2.0 support. Help Viewer 1.0 doesn't care which name you use for self-branded content but Help Viewer 2.0 requires the qualified name or it attempts to brand the content which causes some odd display issues. Also removed the header table fix code from MSHCComponent as it wasn't needed anymore (it's already handled by the script, see below).

Added an extra slash to the "ms-xhelp" links generated by ResolveConceptualLinksComponent and ResolveReferenceLinksComponent2 so that they work properly with Help Viewer 2.0. Without it, Help Viewer 2.0 renders invalid links for some reason.

Presentation Styles

Replaced conceptualLink elements with anchor links to the corresponding MSDN topics in the VS2010 style's resource item files.

Removed the style attribute from VS2010\Branding\ps-codesnippet.xslt as it was causing issues with FireFox and Chrome when viewing website output. The attribute appears to be unnecessary and its removal does not appear to affect the results.

Added a case for using the currently defined target attribute value on an external link in VS2010\Branding\ps-instrumentedLink.xslt so that it honors the user-defined link target rather than always forcing it to "_blank".

Fixed a bug in Presentation\VS2010\Branding\ps-instrumentedLink.xslt that caused local links to be rendered with an incorrect URL in Help Viewer 2.0.

Removed the background attribute from the nsrBottom table element in the VS2005 style as it was breaking the language filter links at the top of the page in Help Viewer 2.0. The script sets the background so it was not needed anyway.

Fixed various other issues in the VS2005 and VS2010 presentation styles to get them to work properly with Help Viewer 2.0.

Fixed the VS2005 and VS2010 presentation styles so that F1 keywords work properly when looking up API members via F1 in Visual Studio with MS Help Viewer.

Merged the collapsible section changes for MAML content from Microsoft into the Prototype style.

The dev10.mshc file from Visual Studio 2010 is no longer required. Due to differences in the way Help Viewer 2.0 works and the fact that the file is not part of Visual Studio 2012, a temporary file of the same name has been included with a set of transformations necessary to get the content built with Sandcastle. A future release will probably get rid of it altogether in favor of integrating its various parts directly into the presentation style.