Blair Hall wrote: > > > > > > I get your point that the first manifest I provided is not specific to > > the DLL, but the second (embedded in the DLL) manifest that I posted > > seems to identify a particular version of msvcr90.dll. Sadly, Windows > > does not worry about matching the version of msvcr90.dll: it just > > loads the first one it finds with the correct name. So what is the > > embedded manifest in the DLL really there for? > > There's a "greater than or equal to" aspect to this as well. There is a > way for a package to say "I can also be loaded when apps ask for earlier > releases". > > There can also be a conflict between the needs of an EXE and the needs > of a DLL. If the EXE has a manifest that requests a certain version of > the CRT, then a DLL can't really override it. > > You have an ugly, icky problem, and I'm not quite sure what to advise > you. The traces you are showing don't necessarily match with what I > would have expected. I don't understand why the Intel version of the > CRT is getting chosen, and I don't understand why it's failing to link > up with it again later. >
Oh well, thanks for trying. Google searches on this type of problem throw up a few other instances that look similar, but I have not found a definitive answer. Perhaps it's simply old technology and people have moved on. I suppose that if I were using Python 3.x there would be no problems at all. I have a work-around (wrote my own version of the function I needed from the uuid module), so I might not have to worry about this anymore, but if anyone finds this thread and has an answer, I'd sure like to know.
_______________________________________________ python-win32 mailing list python-win32@python.org https://mail.python.org/mailman/listinfo/python-win32
