[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
> From: Blair Hall <blairdhall at gmail.com>
> To: python-win32 <python-win32 at python.org>
> Subject: Re: [python-win32] py2exe com_server newbie problem
> Message-ID:
>         <
> CAJeTVApB_oZmOnML+-mch8NJ2CKjjstP5RJxbDSVYJ7VDX83Ug at mail.gmail.com>
> 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?
>
>
>
>
> On Fri, Sep 26, 2014 at 5:32 PM, Blair Hall <blairdhall at gmail.com> wrote:
>
> > I have been working on this all day, with no joy. Some help would be
> > appreciated  :-)
> >
> > I have a simple COM server (that I found on the internet):
> >
> > #-------------------------------------------------------------------
> > import pythoncom
> >
> > import sys
> >
> > class HelloWorld:
> >
> >     #pythoncom.frozen = 1
> >     if hasattr(sys, 'importers'):
> >     _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']
> >
> >     def __init__(self):
> >         self.softspace = 1
> >         self.noCalls = 0
> >
> >     def Hello(self, who):
> >         self.noCalls = self.noCalls + 1
> >         # insert "softspace" number of spaces
> >         print "Hello" + " " * self.softspace + str(who)
> >         return "Hello" + " " * self.softspace + str(who)
> >
> >
> > if __name__=='__main__':
> >     import sys
> >     if hasattr(sys, 'importers'):
> >
> >         # running as packed executable.
> >
> >         if '--register' in sys.argv[1:] or '--unregister' in
> sys.argv[1:]:
> >
> >             # --register and --unregister work as usual
> >             import win32com.server.register
> >             win32com.server.register.UseCommandLine(HelloWorld)
> >         else:
> >
> >             # start the server.
> >             from win32com.server import localserver
> >             localserver.main()
> >     else:
> >
> >         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
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
>
> ------------------------------
>
> End of python-win32 Digest, Vol 141, Issue 3
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20141210/806401f6/attachment-0001.html>