Solved! Go to Solution.
SOLUTION
I had thought upon posting this topic that I would not be able to import the compiled code before arcpy, or that if I found a work-around that let me do so, it would fail some other way.
It turns out I was wrong. For whatever reason, importing the compiled code before arcpy works just fine.
I believe the issue is still relevant and I would like to get to the bottom of it.
# embed the manifest # XXX - this is somewhat fragile - if mt.exe fails, distutils # will still consider the DLL up-to-date, but it will not have a # manifest. Maybe we should link to a temp file? OTOH, that # implies a build environment error that shouldn't go undetected. mfinfo = self.manifest_get_embed_info(target_desc, ld_args) if mfinfo is not None: mffilename, mfid = mfinfo out_arg = '-outputresource:%s;%s' % (output_filename, mfid) try: self.spawn(['mt.exe', '-nologo', '-manifest', mffilename, out_arg]) except DistutilsExecError, msg: raise LinkError(msg)
ArcGIS uses a different version of the msvc libraries than what you're including, so once they try to load there's a version conflict when it tries to import your local ones. I'd recommend getting rid of the manifest altogether.
If you're using a setup.py to build, the thing I do is patch \PythonInstall\Lib\distutils\msvc9compiler.py ...
And just comment them all out.
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
import numpy
regiongroup = Extension("RegionGroup", ["RegionGroup.pyx"])
setup(
cmdclass = {'build_ext': build_ext},
include_dirs = [numpy.get_include()],
ext_modules = [regiongroup]
)
C:/Path/to/python.exe setup.py build_ext --inplace
<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level='asInvoker' uiAccess='false' /> </requestedPrivileges> </security> </trustInfo> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
Commenting out those specific lines will not prevent the manifest from being created, only bypass the part where it embeds it in the PYD.
Have you tried 1. NOT packaging those DLLs with your library, and then 2. making sure the <PYTHON>\Lib\site-packages\<yourlib> is completely cleared out of all files before rebuilding and testing?
SOLUTION
I had thought upon posting this topic that I would not be able to import the compiled code before arcpy, or that if I found a work-around that let me do so, it would fail some other way.
It turns out I was wrong. For whatever reason, importing the compiled code before arcpy works just fine.
I believe the issue is still relevant and I would like to get to the bottom of it.
You'll notice a bunch of Microsoft.VC* folders in <ArcGIS Install>\bin\. That has the various DLLs that ArcGIS uses. You can use one of many methods to determine their versions, set those versions as your dependencies, and then go back to embedding the manifest.
Though, based on how you're describing the symptoms, it may be something else at play here.