On init: The C++ invoke assembly is loaded and started and all C++ Invoke Attributes on any prototype methods in the calling assembly are searched out and wired up to point back to the C++ Invokes dynamic resolver method. On function call: 1. On call of one of these extern methods at runtime, the C++ resolver will check to see if their is an assembly call cache for the invoke. If there is then the calls is passed directly to that assembly and no further action is needed. 2. If there is not a cache for the call, then the C++ resolver will check the library export cache to see if the native library has already been decoded. 3. If not the C++ resolver will then open the native shared library and pass the file to the file type detector. It will determine the file type is PE, ELF, Dylib/Mach-0, and load the approrate reader for that file type. After all the exports have been read, they are then passed to the export mangling detector. Unless the platform is IA64 (which has a standardized mangling for all C++), a string based patern detection will be used on all the exports (yet to be determined how this will work) to detect the correct mangling scheme. The partern detector will load the approrate demangler for the file (MS C++ v6/v7/v8 style, GCC/ICC/IA64 style, OpenVMS style, Borland style, or Digital Mars style) and all the exports will be be decoded. After all the exports are demangled they are then stored in cache using a universal common reference string (hopefully the same as c++filt outputs if at all possible). 4. The current invoke call being called is then searched for in the cache based on its universal reference string. 5. If found, the dynamic pinvoke service be launched and will create an assembly in memory using reflection.emit and emit a pinvoke statement setup to access that C++ export directly at runtime. 6. After wireing up, the assembly will is cached, and the cache will persist unless the native library being called has changed based on a basic file checksum, or may also be flushed when the application is closed based on the calling assembly's setting. 7. The call will then be pased to the dynamic pinvoke running in memory.