Recent communications from Microsoft have resulted in a wave of interest (to put it mildly) in obfuscation. Obfuscation is not new; nor are most of the questions, concerns, and critiques that have started flying around the WP7 dev community – but some are (because there are some unique aspects to the wp7 environment).

This past Monday we released a significant update of Dotfuscator. After introducing BAML support in 4.7.1000, we are proud to announce that starting with version 4.8.1000 you can now also obfuscate embedded XAML resources, allowing significant improvement in protecting Silverlight applications.

I recently worked with a UNIX security expert setting up a small pile of servers. We hired him to handle the total system security of the servers as those servers would be charged with storing highly sensitive customer data. In fact, the vendor for this data had very strict requirements as to how we were allowed to store this data. The requirements (something similar to PCI Level I) were dictated in a 40 page document where one of the rules literally required a monitored camera to be shining directly on the primary database server at all times.

As of Dotfuscator Professional 4.37 there is a much faster, easier, and more reliable way to integrate Dotfuscator into MSBuild. These instructions are still valid, but you should consider the new approach first.

This is the first in a series of what I hope to be informative postings around the theme of “Dotfuscator Tips, Tricks, and HOWTOs”.  Today's topic, if you missed the title, is MSBuild integration. Dotfuscator Pro ships with an MSBuild task that is by default installed into the MSBuildExtensionsPath directory (e.g. C:\Program Files\MSBuild) under “PreEmptiveDotfuscator4.0”. In this directory, you will also find PreEmptive.Dotfuscator.Targets, the file that contains a common definition for the “Dotfuscate” target.