Header graphic 4 of 8

How-To: Compile Zope 3.2.0 with the free Microsoft .NET Toolchain and ActiveState Python 2.4

This is currently ongoing work, not the final version of this article. I pushed this website online, because a discussion about PHP erupted on Tim Bray’s weblog. So bear with me…

In my book, it’s always bad if software isn’t self-contained. This view, of course, clashes with the module deployment pattern of Perl and Python, for example, but it makes software deployment easier and testing more deterministic. For my personal development environment, i.e. my own machine, I usually stick with whatever the vendor or community throws at me, but in this case, i.e. Zope and ActiveState Python, the installer of one product tries to install itself in the other product.

Please note, that parts of this article are directly based on Mike Fletcher’s article Python 2.4 Extensions w/ the MS Toolkit Compiler. So his disclaimer also applies to this article.

Note that this document represents the findings of a very limited set of tests with what is essentially an unsupported approach to building extensions. You should expect to find bugs. No warranty is made that the approach outlined is safe or appropriate.

It should be noted that the Python directory tree can be just copied to another location. So you can reach the same outcome by making a backup copy of your Python directory, installing Zope, renaming the Python w/ Zope directory and copying the old tree back. Using the PYTHONHOME environment variable, you can easily relocate the installation.

So this article is aimed at people who explicitly want to compile Zope’s Python extensions themselves.


ActiveState Python is compiled with Visual Studio .NET 2003, so there are a couple of compatibility issues with the .NET Framework SDK 2.0, i.e. Visual Studio 2005. I’ve documented some of them under caveats.

So you should either have Visual Studio .NET 2003 or the .NET Framework SDK 1.1 installed. If you only have the .NET Framework SDK, you also need Microsoft’s Platform SDK for Windows Platforms, because you need Microsoft’s Windows C header files.

You also need a Zope 3.2.0 source distribution and Python 2.4.


I just copied the Python 2.4 directory tree in a subdirectory of the Zope source tree. So for the sake of this article, %ZOPESRC% points to the Zope source tree and %ZOPESRC%\python2.4 points to Python 2.4.

There are two files that you need to patch for the build to work.

Patching the first file is necessary as Python 2.4 was released before Microsoft released the .NET Framework 2.0.

Patching the second file is necessary as it tries to include basetsd.h, if the Win32-preprocessor directive is defined. This header file presumably was part of Visual Studio 6.0, but it’s not part of Visual Studio 2005 or the .NET Framework SDK 1.1 or the Microsoft Platform SDK. In fact, it seems to have been integrated in other standard header files.

Download the source patch


C library

The most obvious problem is that all ActiveState-supplied binaries depend on msvcr71.dll, Microsoft’s C runtime. Version 7.1 is the last version that was redistributed in the %SystemRoot%\system32 directory. Since the first incarnation of .NET, Microsoft talks about “xcopy deployment”. The .NET 2.0 redistributable package and the C runtime redistributable for Visual C 8.0, installs the C runtime in the side-by-side cache (in %SystemRoot%\WinSxS), theoretically allowing multiple versions of the library to exist. An application declares which version it depends on using a XML file, called the “manifest”. An application can also carry its own dependencies in its files. To fix security issues a “policy” can be added in the host system that redirects a dependency to another library. If you have .NET 2.0 installed you can take a look at the existing policy files in %SystemRoot%\WinSxS\Policies.

Using the patches above you can compile Python extensions with Visual Studio 2005 or the .NET Framework SDK 2.0, but, at least in my tests, the different versions of the C runtime (7.1 and 8.0) between Python and its extensions don’t cooperate. Put simply, starting a Visual Studio 2005 compiled Zope crashes the Python interpreter on my system.

Still, Microsoft’s VS2005 linker creates a default manifest file that declares a dependency on “Microsoft.VC80.CRT” for each library.

I think that this problem can only be solved by recompiling Python with Visual Studio 2005. For now, as far as I get into those things, reading mailing-lists and all, it seems that, the Python developers have decided to only maintain a Visual Studio 6.0 and a Visual Studio .NET 2003 project file.

Of course, someone might release a Visual Studio 2005 project file for Python 2.5, but it seems that that would require a lot of work as Microsoft seems to have deprecated functions that are actually part of the ISO-C standard.

However, Visual Studio 6.0 is now unsupported by Microsoft, so this work has to be done sooner or later.

Non-optimizing compiler

If you don’t own “Visual Studio 2005 Professional Edition” or better, and you want to use your self-compiled extensions in a production environment, you might also want to consider your performance requirements. The .NET Framework, at least in the versions 1.1 and 2.0, and Visual Studio’s Standard Edition does not include Microsoft’s optimizing C compiler, but only the standard C compiler. The produced binaries might still suffice, but you should be aware of the compiler’s limitations.