Fishery

Another possible diversion is using a technique I’ve discussed before: strong-naming your assembly. Unfortunately, the best you can do with strong-naming your assembly is that you can prevent others from reverse-engineering your code and putting your brand on it. It doesn’t prevent others from at least being able to see the underlying code.

There are a couple of options you may try to prevent a user from reverse-engineering your assembly. In this section, I’ll cover the following techniques:
•    Native image generation
•    Strong-naming the assembly
•    Hiding the implementation via a Web service
•    Obfuscation
Native Image Generation
One technique you may try is to create a native image of your assembly. This is done via the ngen tool that comes with .NET. This tool doesn’t work with CIL source files; rather, it takes a .NET assembly and transforms it into a native assembly. For example, you can create a native image of AI.dll as follows:
ngen AI.dll
The tool creates a native image of the assembly, but it puts the result into the Native Image Cache (NIC). You can see what’s in the cache by using the /show argument of ngen:
ngen /show
Unfortunately, the results aren’t what you might expect. The problem is that you still need the original assembly for the client code to run properly. ngen essentially creates implementations of your methods, but the metadata is contained in the original assembly. If you try to run an assembly that uses AI.dll after you employed ngen on it and deleted (or renamed) the source AI.dll, the client will throw a FileNotFoundException.
The runtime will always load the CIL-based assembly, but it’s smart enough to use the native implementations if they exist in the NIC. Therefore, you can’t distribute a native image without the regular assembly. Someone will always be able to reengineer the code like I did before, and if you rename the resulting assembly and target the client to use this new assembly, you can prevent the runtime from using the native implementations.