Issue 2642: MSVCRT packing in Windows Installer (3.0a4) (original) (raw)

I've searched and did not find any open ticket to make suggestions on, so I'm posting it here.

You currently have posted "The MSI installers for Python 3.0a4 are compiled with the new Visual Studio 2008 Professional version. Therefore Python depends on the -Visual C++ runtime library 9.0. We currently don't package this library properly, which means that non- Administrator installation is currently not supported. Contributions to fix this problem are welcome."

Two potential fixes, both of which should be very readily doable. First one is to set the Linking option in MSVC++ to a static link to the CRT. This in-builds the library with Python. (Options /MT and /MTd, for release and debug versions, respectively.)

The other potential resolution for Non-Admin installs, which may or may not be more stable, is to include the MSVCRT DLLs into the directory containing the Python installation. If needed, you may have to register these files manually into the HKCU hive.

Hope that helps with your described packaging issue with the installer.

(Classified under Build and Installation, since it deals with both halves -- feel free to reclassify as appropriate.)

To do a private, SxS install, see:

http://msdn.microsoft.com/en-us/library/ms997620.aspx

I once made a private SxS installation of a MSVC-reliant app (that you could install with non-admin privileges), and if recall correctly, it required disabling the generation / embedding of the manifest file in MSVC++, and then include the MSVC dlls and hand-edited manifest files in the installation. (Or perhaps you could somehow edit the options for the embedded manifest's generation? never tried this myself...). (Or, if you don't like .manifest files littering the install directory, turn off the auto-generation of the manifest, but embed your own hand-edited manifest as a resource. I'm sure this is possible, but figuring out the exact steps to do it may be more headache then it's worth...)

I don't remember exactly, but I think in order to make a manifest that worked for non-Admin install, I think all I had to do was remove the 'publicKeyToken' property from the assemblyIdentity... if it's present, I believe it tries to find a registered, "signed" version of the dlls - and registering signed SxS dlls requires admin privileges. What I don't remember is, if 'publicKeyToken' is present, if it just gives up if it doesn't find a signed version, or it simply means that it will use a signed version preferentially to a 'local' copy if both are present...