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