64 and 32 bit builds

[Taron-art]

Hi all,
It rather a question than an issue, I've just wanted to understand what issues can be faced if I compile and use the library in AnyCPU configuration? I tried, and there is no any compilation issues. I used the compiled assembly in both 32 and 64 bit applications to query USB modems, and didn't noticed any issues either...

I didn't found any other place to post this question, so sorry if it is not a right place.

[abbfmst]

Hi @Taron-art, I have the same question. Did you try running such an AnyCPU assembly to find out whether it works or not?

[cremor]

I'm running an AnyCPU build without problems. But I'm only using a very limited feature set of this library (responding to incoming calls) so I can't say if everything works.

[abbfmst]

Thank you @cremor. @markjulmar It would be great to have your thoughts on this issue here.

[markjulmar]

When this library was built, TAPI shipped as two different binary DLLs -- x86 and x64. So you had to link against the appropriate one based on the architecture you were targeting. It's possible that's changed - although looking at the docs it still seems like it's TAPI32.DLL. AnyCPU probably works fine because it's still linking to one of the DLLs (likely TAPI32).

[cremor]

But you are always linking to Tapi32.dll anyway, aren't you? At least it looks this way when I look at the DllImport attributes in Interop.cs

Is there actually any code that changes between x86 and x64 builds? Or is it really just the PlatformTarget in the project file that changes?

[chiekku]

I was curious so I did a little investigating. I wanted to see what the bit-ness of the DLL was:

On my x64 dev machine, TAPI32 is a 64-bit binary. On the x86 target machine, TAPI32 is a 32-bit binary. So the 32 in the name has nothing to do with the bit-ness of the DLL (probably to maintain compatibility and support for legacy apps); the version of windows determines which binary you get. There is no "TAPI64.dll" for x64 machines.

If you wanted to get fancy, you could try including both versions of the binary in your source, and deploy/link depending on your target platform, like the good old days. But I'm not sure it will help at all. "Any CPU" target should work fine.

I'm still very early in my app, and other some minor changes it's working great. I'm explicitly targeting x86, not Any CPU. and since you can run an x86 targetted program on x64, there's no real disadvantage other than memory I guess.