[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.interop

C#, exposed as COM with pointers as parameters

Mark

11/28/2007 10:05:00 PM

Hi...

We've got a mix of old legacy code and new versions in various states of
porting being used in our system.

One of the objects ported to C# and then exposed back to the legacy code as
COM takes a pointer as a parameter. The use of the pointer is opaque (kind
of like HANDLE); we're just using it as a unique identifier. Currently in
the interface, this parameter is declared as a uint.

Now we're trying to move to a 64-bit system and are running into all of the
usual 32-to-64 conversion issues.

I thought of changing
[DispId(2)]
void Method(uint id);

to
[DispId(2)]
void Method(IntPtr id);

which I think would give it the compilation flexibility I want.

But I'm not sure how the interop stuff is actually getting translated to
unmanaged apis (I saw one object exposed as com declaring a StringBuilder as
the output for example; got to be some massaging going on there).

Since you can build/run 32- and 64-bit on a 64-bit system, I was wondering
what declaring a COM parameter an IntPtr would do to the object
registration/use? Obviously it would be bad to try and register both
versions on the system.

Thanks
Mark
4 Answers

jialge

11/29/2007 8:02:00 AM

0

Hello Mark,

From your post, my understanding on this issue is: (1) how to make a COM
client works well in both 32bit and 64bit environment and (2) how is IntPtr
translated to unmanaged environment. If I'm off base, please feel free to
let me know.

(1) how to make a COM client works well in both 32bit and 64bit environment
I find a good article that talks about "Accessing 32-bit Dlls from 64-bit
code" http://dnjonline.com/article.aspx?ID=jun07_.... As the article
says, 64bit code and 32bit code cannot co-exist in one process. I
reproduced it when I registered a COM object written in C# with 64bit
regasm.exe, and use a 32bit C++ client application to create the COM
object. The 32bit application is not able to create the object and throws
an exception.

The possible workarounds are:
1. As the article http://dnjonline.com/article.aspx?ID=jun07_...
says, we could use DCOM, an out-of-process COM component. DCOM is still
supported on 64-bit Windows platforms, so both 32-bit and 64-bit COM
modules can be built. The only limitation is that 64-bit and 32-bit modules
cannot reside in the same process space, so they have to interoperate
across process boundaries.
2. As you said, building 2 versions of the COM DLL may not be a good
resolution, but it can help to resolve the problem indeed. The 32bit
version of COM object is for 32bit clients, and the 64bit version is for
64bit applications.

(2) how is IntPtr translated to unmanaged environment
According to the MSDN article
http://msdn2.microsoft.com/en-us/library/sys...(VS.71).aspx, The
IntPtr type is designed to be an integer whose size is platform-specific.
That is, an instance of this type is expected to be 32-bits on 32-bit
hardware and operating systems, and 64-bits on 64-bit hardware and
operating systems. It is translated to "long" in my test C++ client
application and it works well both in both 32bit system and 64bit one.

Please let me know if you have any other concerns, or need anything else.

Sincerely,
Jialiang Ge (jialge@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
For MSDN subscribers whose posts are left unanswered, please check this
document: http://blogs.msdn.com/msdnts/pages/posting...

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default....
ications. If you are using Outlook Express/Windows Mail, please make sure
you clear the check box "Tools/Options/Read: Get 300 headers at a time" to
see your reply promptly.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/de....
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Christian Fröschlin

11/29/2007 8:55:00 AM

0

> Since you can build/run 32- and 64-bit on a 64-bit system, I was wondering
> what declaring a COM parameter an IntPtr would do to the object
> registration/use? Obviously it would be bad to try and register both
> versions on the system.

The obvious is not always correct ;)

On a 64-bit Windows systems, the registry has a separate area
for 32-bit compatibility stuff (confusingly named WOW64, btw),
so you can indeed register both versions of a COM DLL. The
tool is called regsvr32 in both cases - although you might
need to use the version in SysWOW64 for the 32-bit case.

Which version of the library is loaded depends on whether
the process runs in 64-bit mode or not.

Mark

11/29/2007 2:39:00 PM

0

Thanks Christian (and Jialiang)...

> On a 64-bit Windows systems, the registry has a separate area
> for 32-bit compatibility stuff (confusingly named WOW64, btw),

WOW... that does seem counter intuititve... :)

> so you can indeed register both versions of a COM DLL. The
> tool is called regsvr32 in both cases - although you might
> need to use the version in SysWOW64 for the 32-bit case.
>
> Which version of the library is loaded depends on whether
> the process runs in 64-bit mode or not.

What about the interface guids and progids? If I have one project using
IntPtr as the method parameter but with the same progids and guids used
throughout, would regsvr32 sort that out correctly if I built for 32-bit and
64-bit then registered both?

Mark

Christian Fröschlin

11/29/2007 4:38:00 PM

0

> What about the interface guids and progids? If I have one project using
> IntPtr as the method parameter but with the same progids and guids used
> throughout, would regsvr32 sort that out correctly if I built for
> 32-bit and 64-bit then registered both?

You can use the same ids, as they will be registered in separate
portions of the registry and only the appropriate one is visible to
a process. In fact, you *must* use the same IDs because VS 2005 is
itself a 32-bit process and will only "see" the 32-bit COM DLLs.
Thus, a programmer using your DLL will add a reference to the
32-bit version, but it resolves to the 64-bit DLL at run time.