classification
Title: "for me" installer problem on x64 Vista
Type: behavior Stage:
Components: Windows Versions: Python 3.0, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: loewis Nosy List: armandorowe, barry, christian.heimes, jpe, loewis, psycoman, rpetrov, slee
Priority: release blocker Keywords: needs review, patch

Created on 2008-10-02 16:06 by jpe, last changed 2008-10-18 14:25 by loewis. This issue is now closed.

Files
File name Uploaded Description Edit
vista.diff loewis, 2008-10-06 14:48
Messages (18)
msg74168 - (view) Author: John Ehresman (jpe) * Date: 2008-10-02 16:06
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.
msg74169 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-10-02 16:08
Could you try it again with "..\\msvcr90.dll", please?
msg74172 - (view) Author: John Ehresman (jpe) * Date: 2008-10-02 16:39
Neither "..\\msvcr90.dll" or a full path work (with \ or \\) seem to work.
msg74175 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-10-02 16:50
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.
msg74193 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-02 19:49
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.
msg74196 - (view) Author: John Ehresman (jpe) * Date: 2008-10-02 21:18
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.
msg74201 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-02 22:30
> 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).
msg74208 - (view) Author: John Ehresman (jpe) * Date: 2008-10-02 23:05
> 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.
msg74215 - (view) Author: Roumen Petrov (rpetrov) * Date: 2008-10-02 23:26
May be call of SetDllDirectory with argument path to python executable 
before to load a python module may help.
msg74216 - (view) Author: Armando Rowe (armandorowe) Date: 2008-10-02 23:47
See issue 4022 for a similar problem in WIndows XP professional,
installed for all users.
msg74220 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-03 00:06
> 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?
msg74249 - (view) Author: Steve Lee (slee) Date: 2008-10-03 13:22
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.
msg74250 - (view) Author: Steve Lee (slee) Date: 2008-10-03 13:34
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.
msg74373 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-06 14:48
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
msg74379 - (view) Author: Steve Lee (slee) Date: 2008-10-06 15:25
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.
msg74681 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-13 11:34
Thanks for the confirmation. Committed as r66881, r66882, and r66883.
msg74951 - (view) Author: Waldecir (psycoman) Date: 2008-10-18 14:04
existis a 2.6 fix or a build with fix?
msg74952 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-18 14:25
> existis a 2.6 fix or a build with fix?

No, this will be fixed in 2.6.1.
History
Date User Action Args
2008-11-08 19:29:17loewislinkissue4284 superseder
2008-10-28 05:49:08loewislinkissue4215 superseder
2008-10-18 14:25:00loewissetmessages: + msg74952
2008-10-18 14:04:03psycomansetnosy: + psycoman
messages: + msg74951
2008-10-13 11:34:21loewissetstatus: open -> closed
resolution: fixed
messages: + msg74681
2008-10-06 15:25:51sleesetmessages: + msg74379
2008-10-06 15:12:51loewissetpriority: normal -> release blocker
keywords: + needs review
2008-10-06 14:48:12loewissetfiles: + vista.diff
keywords: + patch
messages: + msg74373
2008-10-03 13:34:52sleesetmessages: + msg74250
2008-10-03 13:22:36sleesetmessages: + msg74249
2008-10-03 00:06:52loewissetmessages: + msg74220
2008-10-02 23:47:02armandorowesetnosy: + armandorowe
messages: + msg74216
2008-10-02 23:26:10rpetrovsetnosy: + rpetrov
messages: + msg74215
2008-10-02 23:05:53jpesetmessages: + msg74208
2008-10-02 22:30:21loewissetmessages: + msg74201
2008-10-02 21:18:02jpesetmessages: + msg74196
2008-10-02 19:49:17loewissetpriority: deferred blocker -> normal
messages: + msg74193
2008-10-02 17:48:40sleesetnosy: + slee
2008-10-02 16:50:25christian.heimessetpriority: critical -> deferred blocker
nosy: + barry
messages: + msg74175
versions: + Python 3.0
2008-10-02 16:39:38jpesetmessages: + msg74172
2008-10-02 16:08:27christian.heimessetnosy: + christian.heimes
messages: + msg74169
2008-10-02 16:07:23christian.heimessetpriority: critical
assignee: loewis
nosy: + loewis
2008-10-02 16:06:10jpecreate