System.TypeLoadException

.NET obfuscator and automated error reporting

Moderators: Luke Jefferson, Alex.Davies, melvyn.harbour

System.TypeLoadException

Postby Ben1628 » Thu Jul 01, 2010 3:40 pm

I got TypeLoadException after obsfucate the exe I have that is trying to load a plugin.

The error seems to point to one of the type that is used by the plugin.

Anyidea?
Ben1628
 
Posts: 9
Joined: Thu Jul 01, 2010 3:37 pm

Postby Paul.Martin » Thu Jul 01, 2010 6:57 pm

Does it tell you what type it is failing to load?

If not:
  • If you turn on the Self Diagnosis feature (on the Build Succeeded page of the SmartAssembly UI) or, if you are testing on a different machine to the one with SmartAssembly on, turn on the Automated Error Reporting.
  • When the error occurs you will then get an error report which will tell you the unobfuscated name of the type which is causing issues.



Is the type defined in the main assembly and then used by the plugin?
How is the type being created/used in the plugin?


The mostly likely cause is that the type is mistakenly being obfuscated or pruned (this can occur if the type is defined in an exe or is only being called by reflection).

If you open up the SmartAssembly project for the assembly that contains the type.

If you are applying pruning to your assembly, then under the Pruning section next to the name of the assembly there will be an "Exclusions..." link. If you click on this link and then navigate through the namespace to find the type
If the type is described as being a "Fully useful class" or is only listing a few members or attributes to prune then that is good and SmartAssembly has correctly identified it as being used. If it is described as a "Prunable Class" click the "Exclude from Pruning" button in the middle of the page. This will tell SmartAssembly not to prune the type.

If you are applying obfuscation to your assembly, then under the Obfuscation section next to the name of the assembly there will be an "Exclusions..." link. If you follow the same procedure as I described for the pruning to make sure that it is not obfuscating the name of the typel.
Paul.Martin
 
Posts: 83
Joined: Wed Feb 03, 2010 11:20 am
Location: Cambridgeshire

Postby Ben1628 » Fri Jul 02, 2010 12:00 am

Thanks. :D
That gets me further, however, I'm now getting

system.typeloadException

Method 'soso" in type 'abc' from assembly 'abc .... publickeytoken=... ' does not have an implemention.

abc is the plugin (not obfuscatged yet), I don't know why it is referred to as type, method soso is one of the methods that is described in the interface and is defined in the plug in, of course (since it is all working without obsufcation.

The interface is excluded using Eclusions link in obfuscation section.

I actually perferred to use [DONONOBFUSCATE], or should I use [DONOTOBUSCATETYPE], may be that is what I should use in the my code for the interface instead of exclused them using smartassembly
Ben1628
 
Posts: 9
Joined: Thu Jul 01, 2010 3:37 pm

Postby Paul.Martin » Fri Jul 02, 2010 12:41 pm

[DoNotObfuscate] will only stop the name of the type (or what ever the attribute is applied to) from being obfuscated.
In this case you'll want to use [DoNotObfuscateType] as the method signature of the interface need to be left unobfuscated as well as the type name.

"The Method X in type A.Y from assembly A does not have an implementation" error can mean various things. The usual cases are either it can't find the method signature in the interface (for instance because it is obfuscated or because it is referencing an incorrect version of the assembly), or if the interface is in an assembly which is not referenced.
Paul.Martin
 
Posts: 83
Joined: Wed Feb 03, 2010 11:20 am
Location: Cambridgeshire

Postby Ben1628 » Fri Jul 02, 2010 1:58 pm

Thanks.

What I did is I copied everything in a bin directory to a directoy, make sure it is working in that directory without obfuscation. I then run smartassembly to put a obsufcated exe to that directory.


I choose the second option (obfuscate both class and method...) in the exculsion. Does that means DoNotObfuscateType?

>>"The Method X in type A.Y from assembly A does not have an implementation" error can mean various things. The usual cases are either it can't find the method signature in the interface (for instance because it is obfuscated or because it is referencing an incorrect version of the assembly), or if the interface is in an assembly which is not referenced<<

Since the program is working without obfuscation, does that mean it has something to do with obfuscation? What can smartassembly do to help me isolate the problem?

I have


[DoNotObfuscateType]
public interface A : IDisposable
{
[DoNotObfuscateType]
bool X();
}


Is that sufficent to make sure method X is not obsfuscated, and with that, the main exe should be able to load a plugin and access it's method X.
Ben1628
 
Posts: 9
Joined: Thu Jul 01, 2010 3:37 pm

Postby Paul.Martin » Fri Jul 02, 2010 3:33 pm

Yes the second option (obfuscate both class and method names) in the GUI has exactly the same effect as adding the [DoNotObfuscateType()].

You only need to add the DoNotObfuscateType attribute to the interface, in fact the compiler will give an error if you add it to a method...


As long as the interface type and methods are visible, the references are there, the assembly full name (i.e. name + cutlure + public key token) and the files are all local there shouldn't be any problems.


If all of the above is true, the only other thing I can think is to try compiling the plugin against the obfuscated main assembly. It isn't the recommended way but the compiler might give a more helpful error message.


Ben1628 wrote:Method 'soso" in type 'abc' from assembly 'abc .... publickeytoken=... ' does not have an implemention.

abc is the plugin (not obfuscatged yet), I don't know why it is referred to as type,...

I'm as confused as you why abc is referred to as a type.
Paul.Martin
 
Posts: 83
Joined: Wed Feb 03, 2010 11:20 am
Location: Cambridgeshire

Postby Ben1628 » Fri Jul 02, 2010 4:47 pm

okay, :(

I guess I have to dig in a little bit deeper then.

>>If you want to be able to use breakpoints in a debugger to debug your assembly, it is recommended that you do not obfuscate the documents' URLs.<<

So I think have to setup some kind of breakpoint and see what it is doing in an obfuscated assembly. However, I am confused as to how I go about doing it.

In the normal situation without obfuscation, I just load up the sln, setup some breakpoint and debug my program.

In smartasembly situation, how do I do that? Do I let the obfuscated program runnng, and then attach my debugger to it?

What is the role of the pdb in that situation.
Ben1628
 
Posts: 9
Joined: Thu Jul 01, 2010 3:37 pm

Postby Paul.Martin » Fri Jul 02, 2010 4:54 pm

Yes, in the SmartAssembly settings specify to create a PDB file and make sure the Obfuscate document URLs check box is unticked.

If you then build it and run, then just use Attach to Process in your debugger.
Paul.Martin
 
Posts: 83
Joined: Wed Feb 03, 2010 11:20 am
Location: Cambridgeshire


Return to SmartAssembly 5

Who is online

Users browsing this forum: No registered users and 0 guests