[python-win32] Problem on com server ony in a specifie application

[Tim Roberts]

Matteo Boscolo wrote:
> I made the following test:
> I create a c# application that call the some method
> //code
>              object obj = Activator.CreateInstance
>                  (Type.GetTypeFromProgID("test.Application"));
>              object[] objArgs = new object[1];
>              objArgs[0] = "ciao";
>              obj.GetType().InvokeMember("comInit",
>                  BindingFlags.InvokeMethod, null, obj, objArgs);
>
>              object ret=obj.GetType().InvokeMember("Now",
>                  BindingFlags.InvokeMethod, null, obj, objArgs);
>
> If I compile the code under any cpu I got the some problem that in 
> thinkdesing
> If I compile the code under 32Bit cpu I have no error and the com server 
> works well ..
>
> So now my question is :
> Can I manage this situation under python code ?

This suggests that ThinkDesign is actually a 64-bit app.

First, a couple of facts.  A 64-bit application cannot call a 32-bit DLL
(nor vice versa).  Your Python code is a 32-bit DLL.  .NET applications
are kind of a strange beast.  You probably know that, when you compile a
.NET app, it is actually creating a generic "intermediate language".  It
is not creating machine CPU instructions, the way a C compiler does

When you run a .NET application, the .NET runtime does a "just-in-time"
compile, which turns the intermediate language into machine code for
whatever CPU it is running on.  That's why a single .NET application can
run in many different systems.

When you build a .NET exe as "any CPU" and run that code on a 64-bit
system, the JIT compile will turn it into 64-bit code.  That application
cannot call a 32-bit DLL.  When you build a .NET exe as "Win32" and run
that code on a 64-bit system, the JIT compile will turn it into 32-bit
code.  There, the call is OK.  Same exact code, different circumstances.

So, one answer is to build your applications as Win32 instead of "Any
CPU".  Another possible answer is to turn your COM server into an "out
of process" COM server.  That way, instead of a DLL, you will have an
EXE which will run in a separate process.  I do not know how to do that
with PythonCOM.  Hopefully, Mark will chime in here with a helpful
suggestion.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.