Order in XML seems to matter?

[GoogleCodeExporter]

I am running into an issue where it appears Obfuscar is not obfuscating 
properly. I have a number of modules with different rules, and for about half 
of them it seems to use the unobfuscated names.

Does Obfuscar use the rules from the current Module for referenced assemblies 
or somesuch? I can't quite see why it isn't working. For instance, in one case 
it referenced A.e.OnPropertyChanged, where for the real module, 
OnPropertyChanged was obfuscated. Any idea?

I get different errors if I reorder the files in the .xml, by the way.
Still haven't been able to get a working build. It's a rather large project.

Original issue reported on code.google.com by xoc...@gmail.com on 11 Feb 2011 at 6:14

[GoogleCodeExporter]

By the way, I am getting this on 2.0.

1.5.4 crashes on me:

Loading project...Loading assemblies...
Unhandled Exception: System.NullReferenceException: Object reference not set to 
an instance of an object.
   at Obfuscar.Helper.GetScopeName(TypeReference type)
   at Obfuscar.AssemblyInfo.Init()
   at Obfuscar.Project.LoadAssemblies()
   at Obfuscar.Obfuscator..ctor(String projfile)
   at Obfuscar.Program.Main(String[] args)

so I am unable to use earlier versions.

Original comment by xoc...@gmail.com on 11 Feb 2011 at 6:16

[GoogleCodeExporter]

If it makes any differnce, I am prefixing all filenames with $(InPath)\ as per 
the example. Other than that, hmm.. it looks pretty standard. About half of my 
assemblies use SkipMethod, SkipType, etc. and about half use rx=".*_.*" (only 
skip methods with underscores). Not sure what else I can say..

Original comment by xoc...@gmail.com on 11 Feb 2011 at 6:20

[GoogleCodeExporter]

The order of the modules and rules shouldn't matter. Maybe there is indeed a 
problem, as obfuscating WPF projects is not tested very much. But without a 
small sample reduced to the problem (preferably with source code), I cannot 
tell.
Rules apply only to the module they are defined for, but if a virtual method of 
a class was not obfuscated, then the overriding methods in the derived class 
(in another assembly) keep their names.
Obfuscating an existing large project the first time which was not designed 
with obfuscation in mind, can be pretty hard. The best thing is to start with 
all types excluded from obfuscation and then adding types step by step. GUI 
code (esp. WPF) relies heavily on the names of types and members and therefore 
doesn't work well with obfuscation, but usually doesn't include important logic 
which would be worth protection.

Original comment by webbi...@gmail.com on 11 Feb 2011 at 9:16

[GoogleCodeExporter]

Well, the WPF bits I have excluded. I am just getting strange 'method 
implementation not found' and type initializer exceptions. In almost all of the 
cases, it is either not obfuscated in the caller or in the callee, as viewed 
from ildasm. This is very strange.

Original comment by xoc...@gmail.com on 12 Feb 2011 at 12:08

[GoogleCodeExporter]

OK, this is a nonissue. I found in my script a /> instead being a >, and a 
later </Module> which had never been removed. In other words, it was valid XML, 
but there were <Module> tags inside a <Module> tag, hence they were skipped.

It would be nice if Obfuscar warned about stray tags like <Module> where it 
does not belong, though, as it looks like valid XML to anyone using Notepad2, 
etc.

Original comment by xoc...@gmail.com on 3 Apr 2011 at 5:43

[GoogleCodeExporter]

This should be marked as Closed.

Original comment by lextu...@gmail.com on 28 Apr 2013 at 7:46