Dotfuscator 4.9.6 to Ship February 11
New features include:
If you think your app is at all sensitive to our (or anyone else’s) analytics traffic, I would encourage you to download the new version and retest. If you haven’t downloaded Dotfuscator and Runtime Intelligence for Windows Phone yet, you can get it right now at http://www.preemptive.com/windowsphone7.html
This performance enhancement applies to any Silverlight app - not just WP7 apps. Please note: multi-threaded messaging and caching was already supported on all other .NET applications.
Also included in this release (for apps both on and off of the phone) are incremental enhancements in XAML renaming obfuscation. If you are obfuscating your XAML, Dotfuscator will now provide automatic support (meaning no manual configuration or exclusions) for the renaming of attached properties, dependency properties, routed events, and attached events. This feature applies to Silverlight (WP7 and .NET) and WPF applications.
How do you get the new version? Registered Dotfuscator users with active maintenance (all WP7 developers are automatically included) can simply open their installed version of Dotfuscator and select “Check for Updates Now” under the Help menu. The link provided will step you through a simple upgrade path.
How do you take advantage of the performance improvements? Simply run your app through Dotfuscator again; there are no configuration changes required.
How do you take advantage of the extended XAML renaming capabilities? If you have already excluded instances of these specific properties/events in an existing configuration file, then you will need to “uncheck” those exclusions. New applications will be able to take advantage of the improved XAML protection capabilities from the start. Please note: as is always the case, if there are dependencies on these events/properties that cannot be detected through static analysis, then they will always need to be excluded.
When obfuscating XAML, always check the “warnings” panel for potentially “ambiguous” XAML during the initial configuration phase (and always test your apps post-obfuscation).
- 10X performance improvement for Runtime Intelligence messaging on Silverlight and XNA apps (on and off of the phone)
- Expanded XAML obfuscation further improves IP protection
If you think your app is at all sensitive to our (or anyone else’s) analytics traffic, I would encourage you to download the new version and retest. If you haven’t downloaded Dotfuscator and Runtime Intelligence for Windows Phone yet, you can get it right now at http://www.preemptive.com/windowsphone7.html
This performance enhancement applies to any Silverlight app - not just WP7 apps. Please note: multi-threaded messaging and caching was already supported on all other .NET applications.
Also included in this release (for apps both on and off of the phone) are incremental enhancements in XAML renaming obfuscation. If you are obfuscating your XAML, Dotfuscator will now provide automatic support (meaning no manual configuration or exclusions) for the renaming of attached properties, dependency properties, routed events, and attached events. This feature applies to Silverlight (WP7 and .NET) and WPF applications.
How do you get the new version? Registered Dotfuscator users with active maintenance (all WP7 developers are automatically included) can simply open their installed version of Dotfuscator and select “Check for Updates Now” under the Help menu. The link provided will step you through a simple upgrade path.
How do you take advantage of the performance improvements? Simply run your app through Dotfuscator again; there are no configuration changes required.
How do you take advantage of the extended XAML renaming capabilities? If you have already excluded instances of these specific properties/events in an existing configuration file, then you will need to “uncheck” those exclusions. New applications will be able to take advantage of the improved XAML protection capabilities from the start. Please note: as is always the case, if there are dependencies on these events/properties that cannot be detected through static analysis, then they will always need to be excluded.
When obfuscating XAML, always check the “warnings” panel for potentially “ambiguous” XAML during the initial configuration phase (and always test your apps post-obfuscation).
