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.

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

[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.

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?

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,...