LONG_PTR type mismatch between exevtsnk.tlh and basetsd.h

LONG_PTR type mismatch between exevtsnk.tlh and basetsd.h

Hi, all

I'm working on an Exchange store event sink, and have a compilation error on 
64-bit builds only that I don't know how to deal with:

"d:\torzag\current\product\exchstoresink\x64\debug\exevtsnk.tlh(61) : error 
C2371: 'LONG_PTR' : redefinition; different basic types
\dev\mssdk\mar2006\include\basetsd.h(113) : see declaration of 'LONG_PTR'
d:\torzag\current\product\exchstoresink\x64\debug\exevtsnk.tlh(62) : error 
C2371: 'ULONG_PTR' : redefinition; different basic types
\dev\mssdk\mar2006\include\basetsd.h(114) : see declaration of 'ULONG_PTR'"

The issue is that basetsd.h properly typedefs these things conditionally on 
the platform type, but the .tlh file unconditionally typedefs them as 
'long'.

Since the type library .tlb file from which the .tlh file was generated is 
in the MSSDK common library, I assume that it should "win" in terms of the 
actual function prototypes, but I can't quite see how to get there in terms 
of include files, or if it will work once I'm there since the point of the 
polymorphic types is to contain a cast pointer without truncating.

Has anyone an idea about how to work around this problem, or what I'm doing 
wrong?

Thanks,
John Lowery

date: Sun, 25 Nov 2007 11:59:04 -0700 author: John Lowery

Re: LONG_PTR type mismatch between exevtsnk.tlh and basetsd.h

"John Lowery"  wrote in
news:#K2N7U5LIHA.1168@TK2MSFTNGP02.phx.gbl: 
> Has anyone an idea about how to work around this problem, or what I'm
> doing wrong?

 Well, it's ugly, but a workaround would be to run #import once to 
generate the tlh/tli files, edit the tlh/tli files to remove the bug, then 
replace the #import with #include "...tlh".

 All #import (or classwizard, or whatever you're using) does is generate 
the files and #include them -- this way you can fix them and you'll still 
get the same end result.

 Extra bonus 1: sometimes mktyplib locks the TLH/TLI files, and this 
avoids that problem.

 Extra bonus 2: if you're putting this lot into source control, it avoids 
other people building the same source needing to have exevtsnk.dll in the 
same place as on your PC.

 Watch out for: older DevStudios would sometimes crash when opening 
tlh/tli files that were too large, or at least lock up for a long long 
time while intellisense got itself together. You could use notepad to edit 
those files..

 -- dan

date: Mon, 26 Nov 2007 08:51:57 -0800 author: Dan Mitchell

Re: LONG_PTR type mismatch between exevtsnk.tlh and basetsd.h

Hi, Dan

Thanks for the ideas. Before I saw your reply I was able to work around the 
problem by changing the #import to rename the LONG_PTR and ULONG_PTR types 
for the methods defined in the type library, like so:

#import "..\..\include\exevtsnk.tlb" raw_interfaces_only, raw_native_types, 
no_namespace, named_guids,\
  rename("_SID_IDENTIFIER_AUTHORITY","EXOLEDB_SID_IDENTIFIER_AUTHORITY"), \
  rename("_SID","EXOLEDB_SID"), \
  rename("LONG_PTR","EXOLEDB_LONG_PTR"), \
  rename("ULONG_PTR","EXOLEDB_ULONG_PTR")

It seems to work, at least for the small number of methods I'm using. I'm 
still not sure how the 32-bit (U)LONG_PTR could work for those methods in 
x64 land, but I'll test for that if I ever have to use them.

Thanks again,
John



"Dan Mitchell"  wrote in message 
news:Xns99F4645CC35DEdjmitchellayahoocom@207.46.248.16...
> "John Lowery"  wrote in
> news:#K2N7U5LIHA.1168@TK2MSFTNGP02.phx.gbl:
>> Has anyone an idea about how to work around this problem, or what I'm
>> doing wrong?
>
> Well, it's ugly, but a workaround would be to run #import once to
> generate the tlh/tli files, edit the tlh/tli files to remove the bug, then
> replace the #import with #include "...tlh".
>
> All #import (or classwizard, or whatever you're using) does is generate
> the files and #include them -- this way you can fix them and you'll still
> get the same end result.
>
> Extra bonus 1: sometimes mktyplib locks the TLH/TLI files, and this
> avoids that problem.
>
> Extra bonus 2: if you're putting this lot into source control, it avoids
> other people building the same source needing to have exevtsnk.dll in the
> same place as on your PC.
>
> Watch out for: older DevStudios would sometimes crash when opening
> tlh/tli files that were too large, or at least lock up for a long long
> time while intellisense got itself together. You could use notepad to edit
> those files..
>
> -- dan

date: Wed, 28 Nov 2007 14:28:13 -0700 author: John Lowery