To build PTVS on your own PC, for example to pick up the latest bug fixes, make modifications, or contribute back to the project, please use the following instructions.

Cloning

First, you will require a local copy of our Mercurial repository. It can be cloned from https://hg.codeplex.com/pytools. (If you’re behind a corporate firewall you may need to enter your proxy settings. These can be found in TortoiseHg’s Global Settings dialog.)

If you do not want to use Mercurial, you can download the latest commit as a ZIP file from the Source Code page.

If you intend to contribute back to PTVS, you will need to Create a Fork and use the source URL provided there.

Prerequisites

The following list of software is required in order to build PTVS from source. All of these are required for a complete build, though a complete build is not required to be able to contribute. The next section outlines the projects that may be omitted when building PTVS.

Note that you do not need both Microsoft Visual Studio 2010 and 2012. You'll need VS 2010 to build PTVS for VS 2010, and VS 2012 to build PTVS for VS 2012. Instructions in this document describe how to build using VS 2012 -- building with VS 2010 is very similar.

Be aware that the Windows Azure SDK for Python installer will install the latest release of PTVS. A system-wide PTVS installation may interfere with the build process, so you should remove it from the list of packages to install (or uninstall it later).

Some other prerequisites are included with the source code.

Our automated tests use a separately installed tool for controlling Visual Studio. These can be installed by running Prerequisites\TCTestHostAdaptersDev11.msi.

Finally you'll need to disable strong name verification for the Python Tools binaries. This can be done by merging the Prerequisites\EnableSkipVerification.reg file (or Prerequisites\EnableSkipVerificationX86.reg, depending on your own system).  This will install registry keys which disable strong name verification for the assemblies built by PTVS.  If you also want to use the installer you may need to stop and restart the Windows Installer service (from an elevated command prompt, type net stop "Windows Installer" and then net start "Windows Installer").

Optional Projects

Visual Studio 2010 Professional requires the Standalone Profiler to build the Profiling, VsPyProf, VsPyProfX86 and ProfilingUiTests projects. These can be unloaded from the solution if you do not want to install or build the profiler.

The HPC Pack and SDK are required to build the Hpc and MpiShim projects. You can unload these from the solution if you do not want to install the HPC tools.

The Kinect SDK is required to build the PyKinect and PyKinectAudio projects. These can be unloaded from the solution if you do not want to install the Kinect SDK.

The Azure SDK is required for building the Django, WebRole, AzureSetup, DjangoTests, DjangoUITests and FastCgiTests projects. You can unload these if you do not want to install the Azure SDK.

The IronPython, IronPythonResolver and Pyvot projects, as well as those already mentioned, can be unloaded to reduce build time if you do not require these features (note that they can be built without requiring IronPython or Excel being installed). When you are not working on tests, you can unload all projects with “Test” in their name to further reduce the build time, though we do expect most contributions will require appropriate unit tests to be included.

Core projects are always required to be built, and you will receive build errors if you unload one by mistake. These projects are Analysis, Analyzer, Attacher, AttacherX86, Debugger, PyDebugAttach, PyDebugAttachX86, PythonTools and ReplWindow. The PythonTools.sln solution file includes a solution platform called “Minimal” that may be selected within Visual Studio to only build these projects. This will give the fastest possible build times, while only providing core functionality. All of the prerequisites above that are marked optional can be omitted when only building core projects.

Building with MSBuild

PTVS can be built from the Visual Studio Command Prompt by typing

msbuild PythonTools.sln

in your cloned directory. This will install PTVS into the VS Experimental hive, but does not create an installer or affect your main VS installation. Building should complete with zero warnings or errors.

To build using the Release configuration, which produces optimized code, type:

msbuild PythonTools.sln /p:Configuration=Release

in the cloned directory. As above, this does not create an .msi file, but it will install PTVS into the VS Experimental hive.

The VS Experimental hive can be started from the Start menu or by typing

devenv /rootSuffix Exp

at the Visual Studio Command Prompt.

Building with Visual Studio

PythonTools.sln can be opened and built in Visual Studio using the Build Solution command. To debug, ensure that PythonTools is selected as the startup project and use F5 to run PTVS inside of the VS Experimental hive. If an error appears rather than a new instance of VS, ensure the Project|Debug settings are correct.

Building in Visual Studio may produce a number of warnings related to potentially incompatible assemblies and missing references. As long as all projects build successfully, these warnings are benign and can be ignored.

If you already have PTVS installed for all users then you will get an error while compiling. The solution is to uninstall PTVS, or to reinstall it for the current user only. To install for the current user, when installing choose Advanced and then select Install just for you.

Running Automated Tests

PTVS contains a large number of automated tests, including a mix of UI-based tests (which will start another VS, take control of your mouse, etc.) and non-UI tests. Some of the UI-based tests may fail intermittently or interfere with each other, while some tests may make incorrect assumptions about your system configuration (such as the availability of certain versions of Python). It is best to select the tests you need from the Test Explorer window and supervise them as they run.

Building the Installer

The simplest way to build the installer is to run the release script Release\Product\Setup\BuildRelease.ps1 with PowerShell. This script updates the version to the current date/time, builds all flavors (Release, Debug) for each version of Visual Studio installed (VS 2010, VS 2012), and archives the source code, binaries, symbols, and installers into an output directory.

powershell -ExecutionPolicy RemoteSigned .\BuildRelease.ps1 D:\PTVS_Out –skiptests

The output directory will contain VS 2010\Debug and VS 2010\Release folders (if VS 2010 is installed), VS 2012\Debug and VS 2012\Release folders (if VS 2012 is installed) and Sources folders. The Debug and Release directories will contain the installers. This is the same script which we use to builds releases of PTVS, so you'll get an installer which works just like the released versions. However, unless you sign the binaries with your own code signing certificate, the installer will only work if the EnableSkipVerification.reg (or EnableSkipVerificationX86.reg) file has been merged into the registry on the destination computer.

A quicker way to build an installer for a single configuration is to use MSBuild in the Release\Product\Setup directory. You'll need to specify dirs.proj as the source, as well as the configuration and version of VS targeted. For example:

msbuild dirs.proj /p:WixVersion=1.5.0.0 /p:VSTarget=11.0 /p:Configuration=Release

creates a Release build for Visual Studio 2012 including the installer. The resulting .msi file is in the main binaries directory: \Binaries\Release11.0.