Managed/unmanaged 32 bit DLL and 32 bit C# under windows x64 compatibilityissues.

[A n g l e r]

Hi all.

Can you please tell me if you have any problems to use managed C++ DLL
libraries that wrap some code from unmanaged external DLL 32 bit
libraries? If you called such managed 32 bit DLL from C# 32 bit code
under Windows x64 environment, would it all clash?

Can you confirm if this configuration works out for you? I'm really
puzzled whether this is some configuration bug going on here, or more
profound issue.

Cheers,
Peter.

[Pavel Minaev]

On Jun 19, 5:50*pm, A n g l e r <p|k|o|n|i|u|...@h-o-t-m-a-i-l.c_o_m>
wrote:

Can you please tell me if you have any problems to use managed C++ DLL
libraries that wrap some code from unmanaged external DLL 32 bit
libraries? If you called such managed 32 bit DLL from C# 32 bit code
under Windows x64 environment, would it all clash?

It should work, but do not forget to explicitly set the target
platform of your C# project to 32-bit ("x86"). Problems with P/Invoke
and COM interop to 32- bit unmanaged libraries on 64-bit platforms are
very often associated with forgetting to set this property. If you do
not do that, your C# project will try to run in 64-bit mode, and then
die with an exception the moment it tries to invoke 32-bit code.

[A n g l e r]

>Can you please tell me if you have any problems to use managed C++ DLL

>libraries that wrap some code from unmanaged external DLL 32 bit
libraries? If you called such managed 32 bit DLL from C# 32 bit code
under Windows x64 environment, would it all clash?

Are you referring to /Platform:X86 and /MACHINE:X86 ? I did it on both
and still get this sick effect like it was trying to mix 32 and 64 bit
codes. This happens when I start calling external 32 bit LIB from the
managed 32 bit DLL ... I'm not sure whether this triggers some hidden
dependences or what ... ?

[A n g l e r]

Are you referring to /Platform:X86 and /MACHINE:X86 ? I did it on both

and still get this sick effect like it was trying to mix 32 and 64 bit
codes. This happens when I start calling external 32 bit LIB from the
managed 32 bit DLL ... I'm not sure whether this triggers some hidden
dependences or what ... ?

Actually, I reckon it happens somewhere on a joint with C# as I've tried
to compile a similar project with 32 bit DLLs provided (so didn't
compile them on the x64 machine). The only bit compiled here is C# code
utilising the DLL. And guess what, it crashes in the same way although
it's fully configured for 32 bit platform. Blooming C# - I haven't seen
such a mess in ages :///////

[Ben Voigt [C++ MVP]]

A n g l e r wrote:

>>Can you please tell me if you have any problems to use managed C++
DLL libraries that wrap some code from unmanaged external DLL 32 bit
libraries? If you called such managed 32 bit DLL from C# 32 bit code
under Windows x64 environment, would it all clash?

Are you referring to /Platform:X86 and /MACHINE:X86 ? I did it on both

Yes, and it's the setting on the .exe file that counts.

and still get this sick effect like it was trying to mix 32 and 64 bit
codes. This happens when I start calling external 32 bit LIB from the
managed 32 bit DLL ... I'm not sure whether this triggers some hidden
dependences or what ... ?

[A n g l e r]

Yes, and it's the setting on the .exe file that counts.

Yeah, it is on exe because it runs as 32 bit. I have checked it with the
process explorer. I'm having a sneaky suspicion this has something to do
with DLL unmanaged libraries called by this static library linked to
managed one.

I guess this may be due to some arbitrarily assumed folder locations for
a bunch of unmanaged DLL libraries that was fine in case of windows x86,
but windows x64. I dunno what else could pose this issue...

[Pavel Minaev]

On Jun 19, 10:06*pm, A n g l e r <p|k|o|n|i|u|...@h-o-t-m-a-i-l.c_o_m>
wrote:

Yeah, it is on exe because it runs as 32 bit. I have checked it with the
process explorer. I'm having a sneaky suspicion this has something to do
with DLL unmanaged libraries called by this static library linked to
managed one.

I guess this may be due to some arbitrarily assumed folder locations for
a bunch of unmanaged DLL libraries that was fine in case of windows x86,
but windows x64. I dunno what else could pose this issue...

A 32-bit process running on Win64 should automatically load any system
DLLs from C:\WINDOWS\SysWOW64, so it shouldn't be a problem.

I've worked on project which used interop between managed and
unmanaged code (both written for the project) extensively, including
frequent callbacks between the two, and we did not have any issues
such as you describe.

Can you detail further on the nature of your managed/unmanaged calls?
Is it P/Invoke or COM interop, for starters? Are there callbacks?

[A n g l e r]

Hi, I've sorted this finally out. It turned out there was a x64 library
called by another unmanaged library. Anyway, all looks good but
intellisense which keeps bugging me with some error:
There was a problem reading metadata from
'{BF5AC628-BB8E-4B99-8601-8CFE58405E9E}' ('The system cannot find the
file specified.'). IntelliSense may not work properly until the solution
is reloaded.

I've experimented a lot and it happens when managed C++ project with
references to unmanaged C++ is added as a reference to C# code. This is
the case each time I go for this sort of solution. Alternatively, if a
managed DLL is added as a reference (rather than a whole project), the
intellisense keeps quiet.

Any thoughts how to shut it up?
Thanks in advance,
Peter.

A 32-bit process running on Win64 should automatically load any system
DLLs from C:\WINDOWS\SysWOW64, so it shouldn't be a problem.

I've worked on project which used interop between managed and
unmanaged code (both written for the project) extensively, including
frequent callbacks between the two, and we did not have any issues
such as you describe.

Can you detail further on the nature of your managed/unmanaged calls?
Is it P/Invoke or COM interop, for starters? Are there callbacks?