Viewing Your Data

The Informer is another great feature that you can access from Explorer. You get four levels of information: token information, an inheritance view, an implementation view, and members usage statistics. The token information tells you about the token class, visibility, and which member declared the token.

The inheritance view shows the base class of various objects; it doesn't really tell you much when working with a standard application. However, this view does provide some helpful information, when you work with applications that rely on custom delegates (or other interesting customizations) because you can follow the path of inheritance easily.

The member usage statistics is probably the best part of Informer. I can see someone using this feature extensively to verify that every object is actually used and to determine how often the application uses it. You could use this feature to remove unused application code and target areas for performance testing. Although I've seen other packages that provide better functionality in this area (such as FxCop), the member usage statistics feature is still a very nice addition to the package and will help most developers refine their code.

I never did get the implementation view to work. It was at this point that I started noticing significant deficiencies in the help system. The implementation view documentation consists of a single sentence that shows you how to display it; yet, it doesn't even provide a screenshot of what to expect. As I went through the review process, I found that some help file sentences were nearly incomprehensible; they were incomplete, contained misspelled words, and generally required a lot of editing.

Viewing the Properties Tab

It's essential that you visit the Properties tab shown in Figure 4 before you attempt to obfuscate your application. The default settings bury the output in the \Program Files folder.

In addition, the amount of obfuscation is limited with the default settings. If you really want to obfuscate your application fully, you need to modify the settings to perform the task more aggressively.

For example, you probably want to set the Anonymizer property to High and the AntiILDASM property to either True or Complete. You can also add features, such as a software watermark, and give the assembly a strong name.

In short, the default settings really don't do much in the way of obfuscation, but setting the defaults higher produces output that is nearly impossible to decompile.

Figure 4: Always visit the Properties tab before you obfuscate an assembly.

I tried various obfuscation settings; the results varied quite a bit. A good example of the maximum obfuscation level appears in Figure 5. Although there are a few readable entries here and there, the resulting file is pretty much unreadable by anyone but the computer. You'd really have to work hard to obtain results that look anything like the original program shown in Figure 1. For an application of any complexity, this level of obfuscation will probably protect your trade secrets from even the most determined cracker.

Figure 5: The maximum level of obfuscation works very well.

This leaves open the question of whether you can decompile an application that you obfuscated using the Spices.Net application. After quite a few tries, I'm confident that you can't, as long as you set the AntiILDASM property to Complete. Of course, the completeness of the obfuscation means that you can't retrieve your code either. The essential lesson here is that you must keep a copy of your source code in a safe place (several places is better) once you obfuscate the executable.

Working with the Portable Executable (PE) and Metadata

I found the PE/Metadata tab the most interesting feature. It illustrates that there's a great deal most developers don't know about the executables on which the .NET Framework relies. As shown in Figure 6, just like any native executable, a managed application includes all of the usual headers, sections, directories, and tables.

Figure 6: You'll find all of the usual executable information in managed applications; that's a surprise for many developers.

It's interesting to analyze your application with this tool, because some of it never appears anywhere else. You'll find all kinds of hidden details that you may not find using any other method — at least not easily. Obviously, a hex editor will also display this information, but not in an easily readable form. I really like the fact that Spices.Net organizes the information in a hierarchical structure, making it quite easy to move from area to area of executable file.

Diagramming Your Application

Many developers will love the diagramming capabilities in Spices.Net. You can diagram all or part of your application, by right clicking the required object in Explorer and choosing Modeler from the context menu. This action displays the Diagrams panel, from which you can choose one or more diagrams.

Figure 7 shows a typical example. In this case, you're viewing the types of inheritance and implementation in the current assembly.

Figure 7: Modeling your application presents a graphical view of its construction from several perspectives.

Although Spices.Net can't model every aspect of your application, it does provide consistent coverage of modeling for assemblies — even those that you don't own. For example, Figure 8 shows the results of modeling the Microsoft.VisualBasic.dll assembly. The diagrams include assembly types, inheritance/implementation (both the current assembly and the project as a whole), assembly relations, assembly dependencies, and assembly namespaces.

Figure 8: It's easy to model any assembly so that you have a better idea of how it works.