Dotfuscator disassociates derived class when base class is l

jimhunt22 · Joined: 01 Feb 2008 Posts: 3

I've run into an odd problem using the Dotfuscator tool. I have a
reasonably large PDA C# Winfoms application that when obfuscated "as-
is" works fine on the device. However, when I "link" together a
number of assemblies then the application becomes broken. One of the
assemblies in the Linking is a base class of a number of other
assemblies. When it's linked in the inheritance hierachy appears to
become disassocarted and calls to override functions in the base class
(which previously successfully called the derived class before
linking) now fail to call the override functions in the derived
class. It's like as far as the base class is concerned the derived
class does not exist anymore. I found that if I exclude the base
class function from obfuscation then it all works correctly again -
obvioously this then defeats the purpose of obfuscation.

I would like to understand why this is happeneing - I believe it to be
a bug in the Dotfuscator tool, but I am open to suggestions

Jim

Archived from group: microsoft>public>dotnet>framework>compactframework

jimhunt22 · Joined: 01 Feb 2008 Posts: 3

On 1 Feb, 09:53, jimhun...@googlemail.com wrote:
> I've run into an odd problem using the Dotfuscator tool. I have a
> reasonably large PDA C# Winfoms application that when obfuscated "as-
> is" works fine on the device. However, when I "link" together a
> number of assemblies then the application becomes broken. One of the
> assemblies in the Linking is a base class of a number of other
> assemblies. When it's linked in the inheritance hierachy appears to
> become disassocarted and calls to override functions in the base class
> (which previously successfully called the derived class before
> linking) now fail to call the override functions in the derived
> class. It's like as far as the base class is concerned the derived
> class does not exist anymore. I found that if I exclude the base
> class function from obfuscation then it all works correctly again -
> obvioously this then defeats the purpose of obfuscation.
>
> I would like to understand why this is happeneing - I believe it to be
> a bug in the Dotfuscator tool, but I am open to suggestions
>
> Jim

Hmmm, it seems the problem is being caused by checking the "Rename
referenced metadata defined only in input file" option on the "Rename-
>Options" tab. Anyone have any idea what this does - there is nothing
on Google and nothing in the Dotfuscator that explains its meaning.
What is the effect of unchecking this?

Jim

Simon Hart [MVP] · Joined: 03 Oct 2007 Posts: 95

I tried Dotfuscator in the early days I think way back in .NET 1.1 and could
never get it to behave and I think many other developers have found the same
problem that I have come across. There are better obfuscator tools out there
but you will have to pay for them.

See here: http://www.howtoselectguides.com/dotnet/obfuscators/

I'm just gussing but that rename referenced metadata option would obfuscate
any dependency assemblies the input assembly is dependent on.
--
Simon Hart
Visual Developer - Device Application Development MVP
http://simonrhart.blogspot.com

"jimhunt22@googlemail.com" wrote:

> On 1 Feb, 09:53, jimhun...@googlemail.com wrote:
> > I've run into an odd problem using the Dotfuscator tool. I have a
> > reasonably large PDA C# Winfoms application that when obfuscated "as-
> > is" works fine on the device. However, when I "link" together a
> > number of assemblies then the application becomes broken. One of the
> > assemblies in the Linking is a base class of a number of other
> > assemblies. When it's linked in the inheritance hierachy appears to
> > become disassocarted and calls to override functions in the base class
> > (which previously successfully called the derived class before
> > linking) now fail to call the override functions in the derived
> > class. It's like as far as the base class is concerned the derived
> > class does not exist anymore. I found that if I exclude the base
> > class function from obfuscation then it all works correctly again -
> > obvioously this then defeats the purpose of obfuscation.
> >
> > I would like to understand why this is happeneing - I believe it to be
> > a bug in the Dotfuscator tool, but I am open to suggestions
> >
> > Jim
>
>
> Hmmm, it seems the problem is being caused by checking the "Rename
> referenced metadata defined only in input file" option on the "Rename-
> >Options" tab. Anyone have any idea what this does - there is nothing
> on Google and nothing in the Dotfuscator that explains its meaning.
> What is the effect of unchecking this?
>
> Jim
>

Fabien · Joined: 08 Aug 2007 Posts: 12

Hi,

For CF, check out this, it is a very good tool:
http://fabdecret.blogspot.com/2007/09/obfuscator-for-compact-framework.html

BR

Fabien Decret (Device Application Development MVP)
Windows Embedded Consultant

ADENEO (ADESET)
http://www.adeneo.adetelgroup.com/ | http://fabdecret.blogspot.com/

On 3 fév, 14:13, Simon Hart [MVP] wrote:
> I tried Dotfuscator in the early days I think way back in .NET 1.1 and could
> never get it to behave and I think many other developers have found the same
> problem that I have come across. There are better obfuscator tools out there
> but you will have to pay for them.
>
> See here:http://www.howtoselectguides.com/dotnet/obfuscators/
>
> I'm just gussing but that rename referenced metadata option would obfuscate
> any dependency assemblies the input assembly is dependent on.
> --
> Simon Hart
> Visual Developer - Device Application Development MVPhttp://simonrhart.blogspot.com
>
>
>
> "jimhun...@googlemail.com" wrote:
> > On 1 Feb, 09:53, jimhun...@googlemail.com wrote:
> > > I've run into an odd problem using the Dotfuscator tool. I have a
> > > reasonably large PDA C# Winfoms application that when obfuscated "as-
> > > is" works fine on the device. However, when I "link" together a
> > > number of assemblies then the application becomes broken. One of the
> > > assemblies in the Linking is a base class of a number of other
> > > assemblies. When it's linked in the inheritance hierachy appears to
> > > become disassocarted and calls to override functions in the base class
> > > (which previously successfully called the derived class before
> > > linking) now fail to call the override functions in the derived
> > > class. It's like as far as the base class is concerned the derived
> > > class does not exist anymore. I found that if I exclude the base
> > > class function from obfuscation then it all works correctly again -
> > > obvioously this then defeats the purpose of obfuscation.
>
> > > I would like to understand why this is happeneing - I believe it to be
> > > a bug in the Dotfuscator tool, but I am open to suggestions
>
> > > Jim
>
> > Hmmm, it seems the problem is being caused by checking the "Rename
> > referenced metadata defined only in input file" option on the "Rename-
> > >Options" tab. Anyone have any idea what this does - there is nothing
> > on Google and nothing in the Dotfuscator that explains its meaning.
> > What is the effect of unchecking this?
>
> > Jim- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -

user · Joined: 08 Aug 2007 Posts: 286

We use Xenocode Postbuild as well, and while we've found a few quirks
(especially with strong-named CF assemblies), it works well and is
reasonably priced plus their support team is responsive when we do have
issues.

--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"Fabien" wrote in message @i12g2000prf.googlegroups.com...
Hi,

For CF, check out this, it is a very good tool:
http://fabdecret.blogspot.com/2007/09/obfuscator-for-compact-framework.html

BR

Fabien Decret (Device Application Development MVP)
Windows Embedded Consultant

ADENEO (ADESET)
http://www.adeneo.adetelgroup.com/ | http://fabdecret.blogspot.com/

On 3 fév, 14:13, Simon Hart [MVP] wrote:
> I tried Dotfuscator in the early days I think way back in .NET 1.1 and
> could
> never get it to behave and I think many other developers have found the
> same
> problem that I have come across. There are better obfuscator tools out
> there
> but you will have to pay for them.
>
> See here:http://www.howtoselectguides.com/dotnet/obfuscators/
>
> I'm just gussing but that rename referenced metadata option would
> obfuscate
> any dependency assemblies the input assembly is dependent on.
> --
> Simon Hart
> Visual Developer - Device Application Development
> MVPhttp://simonrhart.blogspot.com
>
>
>
> "jimhun...@googlemail.com" wrote:
> > On 1 Feb, 09:53, jimhun...@googlemail.com wrote:
> > > I've run into an odd problem using the Dotfuscator tool. I have a
> > > reasonably large PDA C# Winfoms application that when obfuscated "as-
> > > is" works fine on the device. However, when I "link" together a
> > > number of assemblies then the application becomes broken. One of the
> > > assemblies in the Linking is a base class of a number of other
> > > assemblies. When it's linked in the inheritance hierachy appears to
> > > become disassocarted and calls to override functions in the base class
> > > (which previously successfully called the derived class before
> > > linking) now fail to call the override functions in the derived
> > > class. It's like as far as the base class is concerned the derived
> > > class does not exist anymore. I found that if I exclude the base
> > > class function from obfuscation then it all works correctly again -
> > > obvioously this then defeats the purpose of obfuscation.
>
> > > I would like to understand why this is happeneing - I believe it to be
> > > a bug in the Dotfuscator tool, but I am open to suggestions
>
> > > Jim
>
> > Hmmm, it seems the problem is being caused by checking the "Rename
> > referenced metadata defined only in input file" option on the "Rename-
> > >Options" tab. Anyone have any idea what this does - there is nothing
> > on Google and nothing in the Dotfuscator that explains its meaning.
> > What is the effect of unchecking this?
>
> > Jim- Masquer le texte des messages précédents -
>
> - Afficher le texte des messages précédents -

jimhunt22 · Joined: 01 Feb 2008 Posts: 3

On 6 Feb, 05:00, "" wrote:
> We use Xenocode Postbuild as well, and while we've found a few quirks
> (especially with strong-named CF assemblies), it works well and is
> reasonably priced plus their support team is responsive when we do have
> issues.
>
> --
>
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Giving back to the embedded communityhttp://community.OpenNETCF.com
>
> "Fabien" wrote in message
>
> @i12g2000prf.googlegroups.com...
> Hi,
>
> For CF, check out this, it is a very good tool:http://fabdecret.blogspot.com/2007/09/obfuscator-for-compact-framewor...
>
> BR
>
> Fabien Decret (Device Application Development MVP)
> Windows Embedded Consultant
>
> ADENEO (ADESET)http://www.adeneo.adetelgroup.com/|http://fabdecret.blogspot.com/
>
> On 3 fév, 14:13, Simon Hart [MVP] wrote:
>
> > I triedDotfuscatorin the early days I think way back in .NET 1.1 and
> > could
> > never get it to behave and I think many other developers have found the
> > same
> > problem that I have come across. There are better obfuscator tools out
> > there
> > but you will have to pay for them.
>
> > See here:http://www.howtoselectguides.com/dotnet/obfuscators/
>
> > I'm just gussing but that rename referenced metadata option would
> > obfuscate
> > any dependency assemblies the input assembly is dependent on.
> > --
> > Simon Hart
> > Visual Developer - Device Application Development
> > MVPhttp://simonrhart.blogspot.com
>
> > "jimhun...@googlemail.com" wrote:
> > > On 1 Feb, 09:53, jimhun...@googlemail.com wrote:
> > > > I've run into an odd problem using theDotfuscatortool. I have a
> > > > reasonably large PDA C# Winfoms application that when obfuscated "as-
> > > > is" works fine on the device. However, when I "link" together a
> > > > number of assemblies then the application becomes broken. One of the
> > > > assemblies in the Linking is a base class of a number of other
> > > > assemblies. When it's linked in the inheritance hierachy appears to
> > > > become disassocarted and calls to override functions in the base class
> > > > (which previously successfully called the derived class before
> > > > linking) now fail to call the override functions in the derived
> > > > class. It's like as far as the base class is concerned the derived
> > > > class does not exist anymore. I found that if I exclude the base
> > > > class function from obfuscation then it all works correctly again -
> > > > obvioously this then defeats the purpose of obfuscation.
>
> > > > I would like to understand why this is happeneing - I believe it to be
> > > > a bug in theDotfuscatortool, but I am open to suggestions
>
> > > > Jim
>
> > > Hmmm, it seems the problem is being caused by checking the "Rename
> > > referenced metadata defined only in input file" option on the "Rename-
> > > >Options" tab. Anyone have any idea what this does - there is nothing
> > > on Google and nothing in theDotfuscatorthat explains its meaning.
> > > What is the effect of unchecking this?
>
> > > Jim- Masquer le texte des messages précédents -
>
> > - Afficher le texte des messages précédents -

Thanks guys - unfortunately I can't dictate what tool my client is
using...such is the life of a contractor.

I did however get a response from PreEmptive that implied they thought
it might be a bug in Dotfuscator and "explained" what that checkbox
did:

"We would like to solve the bug you reported once it is clearly
identified, so we'll investigate this case further.
As for now, this option may impact the way your app is renamed. You
may have a renaming schema that may be different from what you would
have without this option
So you may have a look at the obfuscated output , and the renaming
reports, to check if the renaming coverage you get is OK in front of
what you previously got when you were not using the linking feature."

Jim

Need help with the Stopwatch class...please help Hi, I am playing a little bit with the stopwatch class from Daniel Moth and I want to build a little stopwatch with the time format I use a timer to display it on a lable then it

Testing a class library/graphical control Hi, I have created a nice graphical control as per the instructions posted here once before. However, is there any way to test it easily without having to copy the relevant DLL's from the build to the .net compact framework directories on my computer. For

Accessing base class method using derived class object using namespace std; class A { public: void display() { cout<<"A } }; class B : public A { public: void display() { cout<<" B display "<
Accessing base class method using derived class object using namespace std; class A { public: void display() { cout<<"A } }; class B : public A { public: void display() { cout<<" B display "<
WS Serialization of ArrayList derived Class I was discussing this "issue" over at but downloading the preview of WSE 2.0 and trying the same i am now trying to figure out whether it is a feature or a bug! Post is below and a related post is ove