[python-win32] python-win32 Digest, Vol 141, Issue 3

[Blair Hall]

Update 2
-----------

I found a version of py2exe 0.6.10 (
http://www.lfd.uci.edu/~gohlke/pythonlibs/#py2exe), which does not generate
a DLL that trys to load zlib.pyd. However, that was not my problem.

By using Dependency Walker I can see that, during the registration of the
DLL complied on the win professional machine, the DLL loads a version of
MSVCR90.dll that it finds in the Windows path (which is not the one bundled
in a manifest by py2exe). However, the DLL complied in the Windows home
machine does not try to do this (when trying to register the DLL on the
same machine).

Now, I am perplexed. The source files used to create the DLL are exactly
the same in each case. The machines have the same versions of Python
(2.7.8) and roughly the same suite of modules and libraries. So I don't
understand how this can happen. Something about the machine configuration
seems to be captured by py2exe when the DLL is complied.

Can anyone offer an insight?

I would like to develop a DLL that I can distribute widely. But as it
stands, I am afraid that the process of registering the DLL will be very
sensitive to the software installed on the client's machine.

How can I make the DLL less vulnerable to this sort of problem?


Message: 1

Date: Mon, 8 Dec 2014 16:34:55 +1300
Subject: Re: [python-win32] py2exe com_server newbie problem
<
Content-Type: text/plain; charset="utf-8"
Update
--------
I now have something working, but not everywhere :-(
I have two different machines, both Win7 64-bit (one professional the other
home), both with identical versions of Python 2.7.8 and py2exe 0.6.9.
I can create a COM server DLL on the machine running Win7-Home (machine A)
but when I try the same process on the one running Win7-professional
(machine B) it does not work in the same way.
After using py2exe on machine B I cannot get regsvr32 to register the
server on either machine. But when I use py2exe on machine A the server can
be registered (on both machines).
I have used Dependency Walker to look at what is happening and I see that
during registration an attempt to load zlib.pyd is made. This file is not
available, so I think that is causing an error message. However, zlib is
not actually needed, so the registration of the DLL then proceeds (after
clearing the error dialog) and is successful. The same thing happens when
de-registering the DLL.
I have no idea why zlib is required when building on one machine and not
the other. Can anyone suggest a reason?

I have been working on this all day, with no joy. Some help would be
appreciated :-)
#-------------------------------------------------------------------
import pythoncom
import sys
#pythoncom.frozen = 1
_reg_class_spec_ = "__main__.HelloWorld"
_reg_clsctx_ = pythoncom.CLSCTX_LOCAL_SERVER
_reg_clsid_ = '{E3D5F332-F080-47B3-A319-A3A0E287E466}'
_reg_desc_ = "Python Test COM Server"
_reg_progid_ = "Python.TestServer"
_public_methods_ = ['Hello']
_public_attrs_ = ['softspace', 'noCalls']
_readonly_attrs_ = ['noCalls']
self.softspace = 1
self.noCalls = 0
self.noCalls = self.noCalls + 1
# insert "softspace" number of spaces
print "Hello" + " " * self.softspace + str(who)
return "Hello" + " " * self.softspace + str(who)
import sys
# running as packed executable.
if '--register' in sys.argv[1:] or '--unregister' in
# --register and --unregister work as usual
import win32com.server.register
win32com.server.register.UseCommandLine(HelloWorld)
# start the server.
from win32com.server import localserver
localserver.main()
import win32com.server.register
win32com.server.register.UseCommandLine(HelloWorld)
#-------------------------------------------------------------------
This works just fine as a python module. I can run it, register the COM
server and use the Hello method in VBA code inside Excel.
However, I would like to make a DLL, register it, and be able to have the
same access to the COM server. I have not been able to do that so far.
I have the following simple setup.py module
#------------------------------------------------------------------------
from distutils.core import setup
import py2exe
setup(com_server = ["test"])
#------------------------------------------------------------------------
Using this with py2exe generates both test.dll and test.exe.
I can call test.exe with '--register' on the command line and the COM
server is registered.
However, when I use regsvr32 to register test.dll, the COM server does

not

work with Excel. (although regsvr32 says that the DLL has been

successfully

registered).
What am I missing?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mail.python.org/pipermail/python-win32/attachments/20141208/e9e97160/attachment-0001.html
------------------------------
Subject: Digest Footer
_______________________________________________
python-win32 mailing list
https://mail.python.org/mailman/listinfo/python-win32
------------------------------
End of python-win32 Digest, Vol 141, Issue 3
********************************************

[Tim Roberts]

Post by Blair Hall
By using Dependency Walker I can see that, during the registration of
the DLL complied on the win professional machine, the DLL loads a
version of MSVCR90.dll that it finds in the Windows path (which is not
the one bundled in a manifest by py2exe). However, the DLL complied in
the Windows home machine does not try to do this (when trying to
register the DLL on the same machine).
Now, I am perplexed. The source files used to create the DLL are
exactly the same in each case. The machines have the same versions of
Python (2.7.8) and roughly the same suite of modules and libraries. So
I don't understand how this can happen. Something about the machine
configuration seems to be captured by py2exe when the DLL is complied.

Visual Studio 2008 still used the stupid "side-by-side" DLL installation
technique. What that means is that compiler doesn't just embed a link
to MSVCR90.dll -- it embeds a link to a specific version of
MSVCR90.dll. (As of today, there are SIX such versions.) Side-by-side
DLLs are intended to be installed centrally, in the \Windows\WinSxS
directory tree. If the version you need is in the central repository,
it will use that one. Otherwise, it looks elsewhere, including in a
subdirectory of the application, assuming the manifest allows that.

So, the likely story here is that one of your machines has the latest
Visual Studio 2008 Redistributable Runtime installed, and the other does
not.

Starting in Visual Studio 2010, they wisely dropped the side-by-side
technique for the MSVC runtime.

Post by Blair Hall
I would like to develop a DLL that I can distribute widely. But as it
stands, I am afraid that the process of registering the DLL will be
very sensitive to the software installed on the client's machine.

True. This has always been true. It's equally true on Linux, but
people put up with it. ("You must have glib 4.3.1 and foolib 1.19.2 and
barlib 2.2.1, make sure you install them first.")

Post by Blair Hall
How can I make the DLL less vulnerable to this sort of problem?

What "problem" are you seeing? You can certainly put up a link to the
Microsoft download site for the Visual Studio 2008 Runtime that you
require. Or, you can ship the redistributable installer with your app.
That was the intended solution when VS2008 came out.