I have a 32-bit on windows 7 x 64 A third-party COM library that is having problems running the net application This setup is:
Our application was written for 32-bit Windows XP, but we tried to set things so that it could run properly on 64-bit Windows. It depends on P / Invoke and COM Interop with many 32-bit third party libraries. It is not possible to get a 64-bit version of these libraries.
The library in question is a COM wrapper provided by the vendor for their C-based framework library (not supported last Windows XP). This interface is easy to work with NAT. However, on 64-bit Windows 7, the COM library seems to be faulty during its initialization. In the outline there is a function called int, which gives success, but it does not behave "ok" later on.
During the initialization, the structure is considered to look at structure information (names of custom DLLs we create and other metadata). Using the Secondary Processor Monitor I can query it in the 32-bit compatibility section of the registry, but it does not appear to be used .
I am able to reproduce this behavior by interacting with the COM interface with PowerShell (x86) so I do not think I have a setting wrong in Visual Studio.
Here the kicker is though if I run my application on the X64 platform with the hosting process from Visual Studio, then it works every time if I disable the hosting process or from the outside Visual Studio If I run, he fails every time.
Any ideas about hosted environments that allow this COM interaction to succeed?
Update: The application is definitely running in 32-bit mode. Visual Studio is configured to make it for X86 and I can see 32 * after its name in Task Manager. Process Monitor also uses WOW64 DLL.
One difference is that Visual Studio does not process the hosting, depending on your code. . So it launches for the first time, the net loads and the appdomain is created, and then your .exe loads as if it is DLL.
If this is a significant difference, then you should be able to recreate this scenario and run your application outside of the debugger. Make a dummy .net exe that does nothing other than starting, and then dynamically load a dll in which the actual program is
This gives you a step closer to understanding / solving the problem. Can be brought, because it depends on other issues, and lets you move forward with something that works
Comments
Post a Comment