 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / Interop / March 2008.net assemblies exposing COM interfaces, linking to C++
Hi... We've got some objects written in C# that expose COM interfaces that we're now trying to move to/use in an x64 environment. The .Net assemblies are compiled Any CPU, which as I understand it means they will run under the best/most compatible framework it can find on the system. If you have the x64 framework and/or are running with an x64 app, it runs under x64. If you have an x86 app or don't have the x64 framework it runs under the 32-bit framework. One odd thing I've run into now that we're actually trying to compile on an x64 box (compiling with the x64 solution definition on a 32-bit box isn't quite the same thing apparently) is the interaction with .net-based COM. Our solution builds the .net objects then executes a .bat file to use REGASM on them with the /tlb option. We have some C++ projects that import the tlbs to compile against. Even though the C++ code is compiling x64 on an x64 box, the interface it's reading from the tlb still seems to be confused with 32-bit. Specifically we have some interfaces that exchange longs. On the C++ side, we're using __int3264 to declare our variables for platform independence, but when we compile and import the .net tlb we're getting mounds of errors about __int64 to long may lose data. Is there a way to tell the compiler that they really are on the same page? Thanks Mark > Hi... > [quoted text clipped - 33 lines] > Thanks > Mark long's are "64-bit" entities in C# (and all other managed languages), irrespective how it's compiled and irrespective the underlying platform, that means, that at the C++ side you need to declare them as __int64 or as "long long". Willy. Hi Willy... Thanks for answering. > "Mark" <mmodrall@nospam.nospam> wrote in message > > Specifically we have some interfaces that exchange longs. On the C++ [quoted text clipped - 11 lines] > that means, that at the C++ side you need to declare them as __int64 or as > "long long". As I mentioned, our C++ code is using __int3264 in its declarations, which I believe is supposed to be 32 bits on a 32-bit target machine and 64 bits on a 64-bit target machine. The "long" being referred to in the compiler warning I believe coming from the import of the .Net tlb (the methods that the C# object is exposing, despite them being compiled Any CPU). Thanks Mark > Hi Willy... > [quoted text clipped - 30 lines] > Thanks > Mark But you should not use __int3264 in C++, the type of corresponding variable in C# is a "long", which is always a 64-bit entity no matter the target platform. The exported typelib should declare this type as int64, did you look at the tlb using oleview? The .tlh file produced from the .tlb file by MSC++ typelib importer, should declare that variable as __int64, did inspect this variable? Willy. Hi Willy... The missing bit of information that I didn't provide is that the C# code is using IntPtr in its declared methods. The C++ code is passing a pointer into the C# code, not as unmanaged memory but as a unique identifier. So that's what needed to be platform-specific. So I use __int3264 as the type in the C++ code and IntPtr in the C# code. The C# code is compiled Any CPU. The difference comes down to how the tlb was getting generated. If you use the 32-bit framework regasm to register the object, the tlb produced exposes the method parameters as long. If you use the 64-bit framework regasm, it produces a tlb with long long. I just needed to add something to our build process to use the right regasm for the right target platform. Thanks Mark > But you should not use __int3264 in C++, the type of corresponding variable > in C# is a "long", which is always a 64-bit entity no matter the target [quoted text clipped - 3 lines] > The .tlh file produced from the .tlb file by MSC++ typelib importer, should > declare that variable as __int64, did inspect this variable? Oh I see, but in this case I would use the UINT_PTR or INT_PTR Windows data type in C++. Also, I would never distribute an MSIL assembly (actually I removed this completely from the project templates), relying on regasm to do the right thing is too risky. I'm always building both a 32-bit and a 64-bit assembly and distribute the application with the "bit-ness" correct assembly, or both when the assembly can serve both 32 and 64-bit clients. Also, I never distribute 64-bit COM exposed assemblies when not thoroughly tested on 64-bit. Willy. > Hi Willy... > [quoted text clipped - 30 lines] >> should >> declare that variable as __int64, did inspect this variable? Hi Willy... Mostly I'd filed this discussion away in my head, but lately I've been coming back to it. I've been testing Purify's profiler on some of our .Net applications, and I've been surprised how much of the time it reports going to the JIT processes and how much time it says keeps going to JIT even though I run the same test script multiple times running. That's got me thinking more about going in the direction you mentioned here. I've been reading up on Ngen and I've got a couple of questions: 1) it sounds like ngen has to be run on an msil assembly on the deployment environment, to get it in the cache. Is that correct? It sounded from your post like you were producing a binary at build process and sending that without the msil 2) There were a number of (old) posts saying that the JIT can do so much better optimization because it has so much more data at runtime. In practice how many of those runtime tweaks end up paying off so much? There were a few skeptics about the idea that JIT will produce that much better code, but at least a few years ago it seemed like msil was the Microsoft line. Thanks Mark > Hi Willy... > [quoted text clipped - 15 lines] > post like you were producing a binary at build process and sending that > without the msil No, when I'm refering to MSIL I'm talking about what is now called the "AnyCPU" platform compiler option, this option was called msil in previous versions of VS and the managed code compilers. What I meant was that I'm only deploying X86 or X64, never "AnyCpu" builds. You are right, you have to ngen on the target machine, you can't deploy a pre-jitted assembly, simply because the JIT may produce less optimized or simply invalid code for the target (for instance produce SSE2 while the target CPU doesn't support it). > 2) There were a number of (old) posts saying that the JIT can do so much > better optimization because it has so much more data at runtime. In [quoted text clipped - 4 lines] > at > least a few years ago it seemed like msil was the Microsoft line. Don't know for sure what you mean here, but it's obvious that a JIT can produce "better code" than a native code compiler, because it know exactly what processor type and family he's running on when compiling the actual code. Willy. Thanks for responding > "Mark" <mmodrall@nospam.nospam> wrote in message > > 2) There were a number of (old) posts saying that the JIT can do so much [quoted text clipped - 10 lines] > what processor type and family he's running on when compiling the actual > code. Sorry I wasn't more clear. I found a number of articles ca. 2002-2004 arguing against the use of NGEN because the JIT compiler "would know more about the execution environment and be able to optimize better" (like being able to merge string pools across an app domain) than NGEN. A lot of the things that were mentioned that the jit could do that ngen couldn't seemed more like theoretical benefits than big, concrete wins, and I didn't see anything that looked like such an obvious win that it paid for the hit you take with the jit re-compiling everything at runtime. As I said, I was surprised how long the JIT stayed the #1 processor time consumer in the Purify profiling. Thanks Mark
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.