Blair Hall wrote:
>
>
>
>     One ugly alternative would be to edit sys.path in your code before you
>     start your imports.  If you remove everything but the Windows
>     directories, that should solve the problem.
>
>
> I don't follow. Surely sys.path has nothing to do with it? It is the
> LoadLibrary("msvcr90") call from _cytpes.pyd that seems to be the
> problem here and that is not using the sys.path (or is it?).

Absolutely, yes.  DLLs are found through the path exactly like any other
executable.  You can read about the DLL search algorithm in excruciating
detail here, although this omits some of the ugly subtleties of the
side-by-side nonsense used by msvcr90 and friends:
    https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx


> I have used py2exe on another project that creates an EXE. This
> project also imports uuid (it basically imports the same stuff I am
> using now, but for a different application). In that case, the
> manifest seems to work as expected. So, I wonder what is different in
> the case of my DLL? Well one thing that I can think of is that the
> problem arises when registering the DLL as a COM server, using
> regsvr32. Could it be that Windows does not know to look for the
> manifest in the right place because it is regsvr32 that is running?!

It's not that easy.  As I said, the manifest you have provided is not
actually connected to your DLL.  It merely lets the operating system
know about the runtime library that you have included.  If the DLL
search path comes to your folder, the fact that you have provided a
manifest means that the system is allowed to find your version of
msvcr90.  If there is someone else earlier in the search order that also
has one, it will find that one instead.

-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.

_______________________________________________
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Reply via email to