Installing Sphinx on Windows

Sphinx is an open-source tool for creating documentation. Written originally for the documentation of Python projects it also supports C/C++ with plans in the pipeline for support of other languages. Right now, my interest in Sphinx is that it is the tool used by readthedocs.org where I am planning to host the documentation for BrightstarDB.

BrightstarDB is a .NET application written in C# and I’m quite happy with the output of Sandcastle for the API documentation. However the developer and user docs were all originally created using the (commercial) Help & Manual application – which is a great documentation tool in its own right but would require contributors to the project to purchase a license in order to update or extend the docs.

Getting a local version of Sphinx running is the first step in evaluating if this approach is going to be feasible and as I’m developing on Windows 8, getting it running under Windows is my priority. So my goal here is to document how to install all you need to run Sphinx on Windows – with the qualifier that I’m doing this on Windows 8. YMMV on other Windows OSes.

  1. Install Python 2.7: At the time of writing Python 2.7.5 is the latest Python 2 release. The Python project has Windows installers available at http://www.python.org/download/. As my OS is 64-bit, I used the “Python 2.7.5 Windows X86-64 Installer”.
  2. Add the Python directory to your path: By default Python will install in C:\Python27 but will not add itself to your PATH environment variable. I find it useful to do that so I don’t have to keep typing the full path to the python.exe that you use to run Python scripts.
  3. Install setuptools: The current version is 0.6c11 and you can get it from https://pypi.python.org/pypi/setuptools Installation instructions for Windows are on that page and differ for 32-bit vs 64-bit OS. The basic procedure is to download easy_setup.py and then run it. If you updated the PATH environment variable as suggested above, then this is as simple as opening a new command prompt, cd to the directory you downloaded easy_setup.py to and typing:
    python ez_setup.py

    You will see output from the script as it downloads and installs setuptools into your Python directory.

  4. Add the Python scripts directory to your PATH: The core setuptools scripts get installed under {Python Directory}\Scripts and the Sphinx scripts will get installed in the same location so it is sensible to add this directory to your PATH environment variable. If you went for the default installation location you will add C:\Python27\Scripts to your PATH.
  5. Download the Sphinx egg: Eggs are Python packages that make it easier to distribute and install Python applications. The Sphinx egg can be found at https://pypi.python.org/pypi/Sphinx. At the time of writing the version is 1.2b1.
  6. Install the Sphinx egg: Open a new command prompt (to get your updated PATH) and cd to the directory you downloaded the .egg file to. You can then use setuptools to install the egg like this:
    easy_install Sphinx-1.2b1-py2.7.egg

    The package will install the Sphinx scripts and download and install a set of dependencies. The installation process produces a number of warning messages about not finding files but the installation runs through to completion OK.

  7. Try a Sphinx “Hello World”: The Sphinx project have a more thorough tutorial. But in a nutshell this is what to do (assuming you are still in the same command prompt window) – the following assumes you have your Python directory and Python Scripts directory included in your PATH environment variable.
    1. Initialise your project. The following command create and initialize a directory that will contain your documentation:
      mkdir MyFirstDoc
      cd MyFirstDoc
      sphinx-quickstart

      There now follows a list of questions. Apart from the project name, author and release number, the questions have default answers which for this quick runthrough you can just accept by pressing enter.

    2. Edit index.rst. The initialization process creates a starter file (by default it will be called index.rst). You will want to keep the toctree directive, but you can add more content before or after it. The reStructuredText Primer on the Sphinx project site guides you through the basic constructs that are pretty simple to get the hang of.
    3. Make the docs. The initialization process for Sphinx has helpfully added a make.bat file to your documentation directory so the only command you need to produce your documentation in HTML is:
      make html
    4. View your work: You should now be able to view the glorious generated HTML by typing:
      _build\html\index.html

And that’s all there is to it – should take you about 10 or 15 minutes from start to end. Of course, now the hardest part, I have to start writing the docs…

 

MVC4 List view template error: Column Attribute is an ambiguous reference

I came across this problem when trying to create a strongly-typed MVC4 view using the List scaffolding template in Visual Studio 2010. When trying to add the view, an error is generated that reports:

c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ItemTemplates\CSharp\Web\MVC 4\CodeTemplates\AddView\CSHTML\List.tt(206,35): error CS0104: Compiling transformation: ‘ColumnAttribute’ is an ambiguous reference between ‘System.ComponentModel.DataAnnotations.ColumnAttribute’ and ‘System.Data.Linq.Mapping.ColumnAttribute’

The fix for this is to locate that .TT file (c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ItemTemplates\CSharp\Web\MVC 4\CodeTemplates\AddView\CSHTML\List.tt) and on line 206 change

var column = attribute as ColumnAttribute;

to

var column = attribute as System.Data.Linq.Mapping.ColumnAttribute;

Strangely, this error doesn’t occur in a VS2012 installation so it must have got fixed at some point but even after reinstalling MVC4 into VS2010 the error still came up.

Hopefully this post will help someone else find the fix !

Edit: This problem seems to also affect the Create.tt template (on line 122), the Delete.tt template (line 174), the Details template (line 179) and the Edit template (line 229) – the same fix works in all cases.

Chaining MSIs with WiX 3.0

In some deployment scenarios it is not possible to bundle everything into a single installer. This may be because you need to install some third-party software, or because your build process forces you to split a single product across multiple MSIs.

Although there is not much in the WiX documentation about this, it is possible to chain multiple MSI installers in a setup.exe wrapper so that the installers execute one after the other. The key to this is the setupbld.exe command-line tool that comes with the WiX 3.0 installation. Jon Torresdal has written a useful article on using setupbld.exe to force elevated privileges for an installer under Vista, and I recommend starting there for an explanation of how to prepare your build to generate setup.exe files. In addition to doing this, setupbld.exe can combine multiple MSI files into a single setup.exe installer. To do this use a command line like:

setupbld.exe -out $(TargetDir)setup.exe -msu FirstInstaller.msi -msu SecondInstaller.msi -setup $(ProjectDir)setup.exe

Custom Project Templates Not Registered with Visual Studio 2008

At the moment I’m in the middle of updating the NetworkedPlanet NPCL Schema Editor so that it works with Visual Studio 2008, a task that sets new standards for the word ‘frustrating’. Anyway, having got my whine out of the way, I did find the fix for something which no amount of Googling revealed and I’m writing it up here in the hope that it might save some other poor soul from a bruised forehead.

One of the key steps in deploying a Visual Studio package is writing all of the correct package registration details into the target machine’s registry. For my deployment I wanted to use the WiX toolset to create my installer. According to this MSDN article, you can use the tool regpkg.exe in the Visual Studio SDK to generate a .wxs file that contains the necessary WiX magic to get all of the package registration entries written by the installer. Its then just a question of writing the rest of the installer to put files in the right place, include the .wxs file with the right sort of invocation and off you go.

On testing the deployment on a clean Visual Studio installation I found that the project template I had created to allow users to choose to create an NPCL project didn’t show up in the New Project dialog box. I could see that my Project Package was properly registered with Visual Studio on the target machine (as proof of which I could see it displayed in the list of registered extensions in the Help > About dialog box). I could also see that the project template was installed into the Common7IDEProjectTemplates directory as expected.

After much cursing, rebuilding, redeploying and retesting I finally went back to first principles and decided to compare my package registration key by key with another project package extension that I knew worked – in this case the WiX installation. What I found was interesting. This is the code generated for my project package’s template registration by regpgk.exe:


<Registry Root="HKLM" Key="SoftwareMicrosoftVisualStudio9.0NewProjectTemplatesTemplateDirs{41a84a7e-462c-4a74-9559-3c2568001dc2}/1">
<Registry Name="SortPriority" Value="100" Type="integer" />
<Registry Name="TemplatesDir" Value="[$ComponentPath].NullPath" Type="string" />
</Registry>

And here, for comparison is the Wix registration

<RegistryKey Key="NewProjectTemplatesTemplateDirs$(var.WixVsPackageGuid)" Action="createAndRemoveOnUninstall">
<RegistryKey Key="/1">
<RegistryValue Value="WiX" Type="string" />
<RegistryValue Name="SortPriority" Value="30" Type="integer" />
<RegistryValue Name="TemplatesDir" Value="[VsProjectTemplatesWixDir$(var.VsVersion)]" Type="string" />

</RegistryKey>
</RegistryKey>

The key difference is that the generated registration doesn’t set the default value for the /1 registry key. It appears that this default key value is actually the label for the project type that is displayed in the New Project dialog box, but the regpkg.exe tool doesn’t generate a <Registry> tag to set its value. In the WiX schema there appear to be multiple ways to do this, and I found the syntax below worked for me:

<Registry Root="HKLM" Key="SoftwareMicrosoftVisualStudio9.0NewProjectTemplatesTemplateDirs{41a84a7e-462c-4a74-9559-3c2568001dc2}/1" Type="string" Value="NPCL">
<Registry Name="SortPriority" Value="100" Type="integer" />
<Registry Name="TemplatesDir" Value="[ptNPCL]" Type="string" />
</Registry>

As an aside, the regpkg.exe generates a .wxs file that uses the schema supported by WiX 2.0. I’m using WiX 3.0 for my installer, and it reports these <Registry> elements as deprecated. However, it does work and I can now get on with finishing off my installer.

I hope that this tip saves some one the hours that I will never get back again ;-)