[python-win32] py2exe com_server newbie problem

[Tim Roberts]

Blair Hall wrote:
>
> 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.


> 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.")


> 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.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.