After installing the 32 bit .msi or the 64 bit .msi "for me" on a fairly
clean Vista x64 machine, the socket module won't import because of a
side-by-side configuration error. The output below is from the 32 bit
build.

Microsoft Windows [Version 6.0.6000]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Users\maint>\python26\python
Python 2.6 (r26:66721, Oct  2 2008, 11:35:03) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\python26\lib\socket.py", line 46, in <module>
    import _socket
ImportError: DLL load failed: The application has failed to start
because its si
de-by-side configuration is incorrect. Please see the application event
log for
more detail.
>>>

The event log entry for this is:
Activation context generation failed for
"C:\python26\DLLs\_socket.pyd".Error in manifest or policy file
"C:\python26\DLLs\Microsoft.VC90.CRT.MANIFEST" on line 12. The value
"../msvcr90.dll" of attribute "name" in element
"urn:schemas-microsoft-com:asm.v1^file" is invalid.

Changing ../msvcr90.dll to ..\msvcr90.dll does not fix the problem

Importing socket does work when the msi is installed for everyone.

Could you try it again with "..\\msvcr90.dll", please?

Neither "..\\msvcr90.dll" or a full path work (with \ or \\) seem to work.

I don't have a Vista box at my disposal. Martin might be able to help you.

Barry:
I've marked this bug as blocker because it makes Vista installations
useless. It's not a blocker for the upcoming beta but it should be fixed
before the next rc. It's a rather nasty issue with side-by-side
assemblies. It can only be debugged on a Vista machine *WITHOUT* any
development tools like Visual Studio or 3rd party programs shipped with
msvcrt90 assembly.

I had noticed the problem myself, and I don't know any solution to it.
It's still part of the aftermath of switching to VS 2008, maybe we
should have stayed with VS 2003 :-(

Out of curiosity: Is this Vista SP1? If so, can somebody try Vista RTM?
I recall that it used to work, but I don't have any Vista RTM
installation anymore.

In short, the problem is that Vista now complains about the .. in the
name attribute of the manifest; XP considers the manifest file fine.

A work-around is to place another copy of msvcr90.dll into the DLLs
order, and adjusting the manifest to point to this copy. I rejected this
solution, as it causes two copies of the CRT to be loaded (as can be
seen in sysinternals process explorer). Loading two copies of the CRT
itself caused problems in the past (e.g. when FILE* is passed across DLL
boundaries).

As a consequence, I propose that the "for me" installation just isn't
supported on Vista; it should be easy to adjust the UI accordingly.
Vista users should invoke the "for all installation" (and I should
change the installer back to invoking UAC).

In any case, I don't think this should block the release, given that no
real solution seems possible.

I think one of the tested machines is Vista RTM, though it's been
updated. I also tried of Vista x32 SP1 and it fails there.

If non-admin installs can't be made to work, I agree that the "for me"
option be dropped and the installer changed to invoke UAC. I looked for
a solution to this, but so far can't find any -- and this would also
mean that .pyd files in site-packages and elsewhere would need .manifest
files that contain the path to where msvcr90.dll is located. I think
requiring an admin install might cause problems for py2exe though.

This is rather important because it means that python is unusable using
the default installation options and I suspect that many users won't
know how to install for everyone.

I'd still like to see the need to depend on a C runtime dll dropped at
some point in the future, but I know that it's not an easy thing to do.

I looked for
a solution to this, but so far can't find any -- and this would also
mean that .pyd files in site-packages and elsewhere would need .manifest
files that contain the path to where msvcr90.dll is located.

I don't think this could even work: apparently, Vista disallows putting
a path into the name field. So extension modules will have to ship with
their own copy of the CRT (or link statically).

I don't think this could even work: apparently, Vista disallows putting
a path into the name field. So extension modules will have to ship with
their own copy of the CRT (or link statically).

I agree that this is the case. The closest thing I found to
documentation of this is
http://msdn.microsoft.com/en-us/library/ms235291.aspx under Deploying
Visual C++ library DLLs as private assemblies. It specifies that the
assembly be copied twice, once into the folder with the .exe and again
into the folder with the .dll.

I think the best option is to always install for everyone as
administrator on Vista.

May be call of SetDllDirectory with argument path to python executable
before to load a python module may help.

See bpo-4022 for a similar problem in WIndows XP professional,
installed for all users.

May be call of SetDllDirectory with argument path to python executable
before to load a python module may help.

I'm skeptical. According to the documentation, "The directory from which
the application loaded." is already in the search path, and even before
lpPathName. Can you try it out and propose a patch if it works?

I spotted the problem on Vista Home Premium SP1 32bit

As John indicates the problem with the 'all users' install is that it
requires elevation to run as admin even if logged in as an
administrator. That is rather non obvious (John suggests running cmd.exe
as administrator which works fine). As most people doing it will be
developers and have own machine it is not a big issue (assuming use
py2exe, eggs etc. is used for end user setup ;-)) Oh I wonder if the
same problem exists there?

I ran into SxS problems on XP when building Python 2.5.? from source for
use in Mozilla XULRunner and needed to use VC8 Express for both (so same
CRT). I moved on so never fully resolved it apart from dropping copies
of the CRT in various system folders.

The mozilla bug is https://bugzilla.mozilla.org/show_bug.cgi?id=371359
but looking at it now, especially comment 4, it's not much help.

Here is a patch that fixes the problem as proposed. An installer built
with that patch is available from

http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-3.0.14158.msi

Works for me on Vista, Not tried on XP.

Seems a reasonable temporary compromise though we are now stopping all
possibility of an 'all' install but as noted there is probably little
need for it when application installers are created.

Thanks for the confirmation. Committed as r66881, r66882, and r66883.

existis a 2.6 fix or a build with fix?

existis a 2.6 fix or a build with fix?

No, this will be fixed in 2.6.1.