search

christopherdebow1 / obfuscar

Automatically exported from code.google.com/p/obfuscar
0 stars 0 forks source link

ArgumentException while running #39

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1.Obfuscating my codebase
2.
3.

What is the expected output? What do you see instead?
I get the following exception with a number of assemblies.  Using a config 
based on the example config.

Unhandled Exception: System.ArgumentException: An item with the same key has alr
eady been added.
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boo
lean add)
   at Obfuscar.Obfuscator.RenameTypes()
   at Obfuscar.Program.Main(String[] args)

What version of the product are you using? On what operating system?
1.5.4
.NET 1.1

Please provide any additional information below.

Original issue reported on code.google.com by brien...@gmail.com on 24 Aug 2010 at 5:38

GoogleCodeExporter commented 8 years ago 
Please check that all class names are unique within all assemblies you are 
trying to obfuscate.

Obfuscar is not designed to handle assemblies defining the same type multiple 
times.

Original comment by webbi...@gmail.com on 25 Aug 2010 at 7:23

GoogleCodeExporter commented 8 years ago 
If you mean the unqualified class name, I'm sure they are not.

This is a pretty arbitrary limitation that makes obfuscar unusable for me.

Is there any particular reason that this limitation exists?

Original comment by brien...@gmail.com on 25 Aug 2010 at 10:32

GoogleCodeExporter commented 8 years ago 
No, I meant the full qualified class name including the namespace must be 
unique.
Classes with the same name may of course exist in different namespaces or 
nested classes.
To determine the exact cause for this exception (maybe it is a different 
problem and I am wrong) check out Obfuscar from SVN and start an obfuscation 
run in the debugger. It should be easy to see which of the classes causes the 
problem.

Original comment by webbi...@gmail.com on 25 Aug 2010 at 11:00

GoogleCodeExporter commented 8 years ago 
unrenamedTypeKey.Fullname is "<PrivateImplementationDetails>"

these are .net 1.1 assemblies.

Original comment by brien...@gmail.com on 25 Aug 2010 at 11:17

GoogleCodeExporter commented 8 years ago 
<PrivateImplementationDetails> normally have a GUID appended to make them 
unique. 
Maybe this wasn't the case with the .net 1.1 compiler.

I just did some tests and it seems that skipping the offending type with the 
<SkipType> directive might help.

Original comment by webbi...@gmail.com on 25 Aug 2010 at 12:02

GoogleCodeExporter commented 8 years ago 
SkipType worked.  thanks.

Original comment by brien...@gmail.com on 25 Aug 2010 at 12:40

GoogleCodeExporter commented 8 years ago

Original comment by webbi...@gmail.com on 26 Aug 2010 at 9:02