Ahh okay. There is a reference to the "COccManager" TYPEREF in a
parameter to a global method (AfxEnableControlContainer ) but maybe at
runtime AfxEnableControlContainer is never called.
Method #154
-------------------------------------------------------
MethodName: AfxEnableControlContainer (0600009A)
Flags : [Public] [Static] [ReuseSlot] [PinvokeImpl] [HasSecurity]
(00006016)
RVA : 0x000075ee
ImplFlags : [Native] [Unmanaged] [PreserveSig] (00000085)
CallCnvntn: [DEFAULT]
ReturnType: CMOD_OPT System.Runtime.CompilerServices.CallConvCdecl Void
1 Arguments
Argument #1: Ptr ValueClass COccManager
I just added MC++ obfuscation support to Demeanor for .NET so I'm
hitting a few special cases that never have appeared before. However,
your excellent IL book (Inside Microsoft .NET IL Assembler
http://www.amazon.com/exec/obidos/ASIN/0735615470 for those who don't
have it) has answered all my questions (even this one too). However, in
this case, I'm chasing TYPEREFs to fix them up in case I've obfuscated
the TYPEDEF it references. So when I can't find what it references, I
can quit. <g>
-- Brent Rector, .NET Wise Owl
Demeanor for .NET - an obfuscation utility
http://www.wiseowl.com/Products/Products.aspx
-----Original Message-----
From: Serge Lidin [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 12, 2002 1:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET] Partition II Metadata Spec question
In this case, this TypeRef could be a relic left behind by MC++ compiler
-- one of those internal intermediate types compilers introduce, but
usually purge on the final stages.
An undefined TypeRef is a harmless bloat of the metadata: as long as the
type is not referenced, it's not loaded, so you can have a ton of
unreferenced bogus TypeRefs, and the only negative effect would be waste
of space.
Thanks,
Serge
You can read messages from the DOTNET archive, unsubscribe from DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
