Home - Forums-.NET - Spices.Net - Error code 64: TypeDef (token=xxxxxx) has same name as TypeRef (token=yyyyyy)?


NET code security, tools to protect, obfuscate, tamper defense, code and data safety, recover, convert, optimize, explore, browse and analyze .Net software.

This forum related to following products: Spices.Net Suite, Spices.Net Obfuscator, Spices.Net Decompiler

Error code 64: TypeDef (token=xxxxxx) has same name as TypeRef (token=yyyyyy)?
Link Posted: 11-Aug-2012 12:00

Could you please help with the error in the subject?
Console version:

First time I have ever seen this - .NET 3.5 SP1 project.

Kind regards,


More info:

  --- Checking consistency ----
  Consistency checked successfully.
  --- Checking consistency finished ----
  ---- Start preparing substitutions and excludes ----
  Obfuscation Statistics
  Members             Assembly Obfuscation   Percentage
  Namespaces:               12           0       0.00 %
  Types:                    81           0       0.00 %
  Fields:                  327           0       0.00 %
  Methods:                 796         175      21.98 %
  Properties:              173           0       0.00 %
  Events:                    9           0       0.00 %
  ManagedResource:           0           0       0.00 %
  AssemblyRefs:             14           0       0.00 %
  TypeRefs:                334           0       0.00 %
  MemberRefs:              887           0       0.00 %
  ---------------Anonymizer and Encryption--------------
  Encrypted strings:         -           0
  Anonymized methods:        -           0
  Method stubs:              -           0
  MetaData Size:        113944      107254      94.13 %
  ----End of obfuscation
  Total obfuscated members 175
  Finish time:8:46:21 PM
  Finish obfuscating project.
  Verification of assemblies:
  [MD] Error: TypeDef (token=0x02000002) has same name as TypeRef (token=0x010000bd).
Link Posted: 13-Aug-2012 17:01
Seems you've tried to obfuscate already obfuscated assembly or incorrectly resolved referenced assemblies.
Please check original assemblies used for obfuscation and search paths (/PATHS parameter) to correctly resolve references.
Link Posted: 10-Sep-2012 08:27
Thanks for the response,

Is there any way to debug this.  A simple way to replicate this error is to create a new Office 2010 Outlook Add-In using Visual Studio 2012.  Obfuscating the output assembly results in this error.


Link Posted: 11-Sep-2012 17:00
We've tried to reproduce this problem, created Office 2010 Outlook Add-In project targeted to .Net Framework 3.5, applied the same obfuscation options but couldn't receive the same error.
Seems you incorrectly resolved references to assemblies. Could you provide us with your original and obfuscated assembly (that's strange when typeref name (type name in referenced assembly) and typedef name has the same names if you have single assembly obfuscated, this problem can be appeared when you try to obfuscate already obfuscated assembly)?
Please zip your project and change extension to .zap or .txt before attaching to your message.
Link Posted: 11-Sep-2012 23:28
Thanks for the response,

I do believe that the problem lies with the .NET 4.5 template. And maybe with the 'Embed interop' encorporated into .NET 4.

Link Posted: 13-Sep-2012 14:30
Thanks for additional information, yes names conflict can be caused by incorporation of Interop assemblies (with references to the same Interop assembly).
Have you tried to verify original assembly (Spices.Net: select assembly in assembly browser, right click on selected assembly and click "Verify Assembly")? Probably original assembly has the "Has TypeDef the same name as TypeRef" issue already.
Or you can try to create the same MSOffice Outlook10 addin with VS2010 (we've tested this project also - no problem).
Link Posted: 13-Sep-2012 23:31
Link Posted: 27-May-2015 02:19

I have been working on another (huge) project (running the latest and greatest version of the Console edition) and I am currently running into this error again.  I have a number of assemblies with the [InternalsVisible] attribute set and the obfuscation of all the assemblies only occur at the last possible time - now trying to work back the error is nearly impossible...

I desperately request that the error message be made more descriptive.  Something like a type definition (full name) is a duplicate or the same as another full name.

Link Posted: 27-May-2015 06:56
Hi John,
Could you send us the log and project used for obfuscation?
InternalsVisible attribute is good, but Spices.Obfuscator uses cross-obfuscation of all included to spices.project assemblies, so if some internal or public member is obfuscated in one assembly it will be obfuscated in all references in referenced assemblies(if they included to current spices.project).
Really the error is descriptive because token number is unique identifier of assembly member, so you can easily find the problem assembly member in Spices.Net or in disassembled listing created by ILDASM (in original and in obfuscated assemblies, doesn't matter, htat's will be the same member).
Link Posted: 28-May-2015 07:08
Sorry for that - I have not worked enough with ILDasm before to be able to figure out how to resolve this issue.  I found the problem - the very problem with InternalsVisibleTo and linked source files:(