An Easier, Better Way to Use Dotfuscator

The release of Dotfuscator v4.37 yesterday marks the first big step toward a major goal: to modernize our Visual Studio integration. This release is numbered as a “minor” release – because, as always, we work hard to not make breaking changes – but its significance is actually very major.

Our current Visual Studio integration has always been one of the primary user interfaces for Dotfuscator; nearly half of our users use it, or have used it. Of those users, most are quite happy with it. (So we know that changing it is no small undertaking!)

However, there are some users who can’t use it, or for whom it doesn’t work very well. Notably, users with especially large projects, or complex build configurations, or more-modern projects that have heavy packaging components (including Xamarin and UWP), have all only had the option of our “standalone GUI” and a custom-made build integration.

We thought we could make this better… and we’ve been working on doing so, for over a year. We think today’s release is a great first step in that direction.

This new way of using Dotfuscator:

• Is the easiest way to start using Dotfuscator, regardless of project type.
• Is the easiest way to maintain a Dotfuscator build, regardless of project type.
• Is just as effective as our other ways of using Dotfuscator, regardless of project type.
• Is more effective than our other ways of using Dotfuscator, for large, complex, or “modern” development projects.

So, how does it work?

We start by integrating Dotfuscator directly into an existing Visual Studio project file (e.g. a .csproj file). This way Dotfuscator runs right after the compilation steps, but before later steps like packaging and signing. This enormously reduces the amount of configuration that has to be done in Dotfuscator, and makes builds run faster. It is also easier to understand and to integrate than our current Visual Studio integration.

Then, once integrated, Dotfuscator will automatically generate a config file on the first build, with basic protection defaults, and use it to protect your app.

So the process to get started is:

1. Edit some XML
2. Build (in Release configuration)
3. You’ve made a protected app!

From there, you can get straight to work adding more protection and “turning up the dials” for your app – rather than fiddling with build scripts and packaging issues and signing keys and so on.

And as you continue, Dotfuscator will automatically stay up to date, even as you add and remove projects in your solution.

Our user guide has also been heavily updated to highlight this new way of using Dotfuscator, and to show how easy it is to get started. Take a look, and see for yourself.

This is a big change, and we’re eager to hear your feedback – if you try this, please let us know how it goes, especially if you’ve used one of our other integrations before.

And don’t worry! This truly is a semantically minor release – your existing builds (and existing build integrations) will work just like they always have. You don’t have to change to this new way, if you don’t want to. (But if you do, we think you’ll be happy you did!)

So upgrade now and protect your app a new way, today!