SmartAssembly stack trace is invalid when Method Parent Obfuscation is enabled

Date: 1/30/2012
Product: SmartAssembly

This article only applies if you built your product with SmartAssembly 6.6.0 and Method Parent Obfuscation was enabled. The problem should be fixed in SmartAssembly 6.6.1.

If you built your assembly with SmartAssembly 6.6.0 and Method Parent Obfuscation was enabled, the SmartAssembly map file may be be corrupt. If you are affected, when you view error reports submitted from your application, the type names shown in the stack trace are incorrect.

We have released a patch to solve this problem, which you should run on all builds created with SmartAssembly 6.6.0.

Before you start

Before you start, you will need to know where your SmartAssembly map files are saved.

Map files are located by default in the following location:

On Windows Vista and later: %ProgramData%\Red Gate\SmartAssembly\Maps\
On earlier versions of Windows: %ProgramFiles%\Red Gate\SmartAssembly 6\Maps\

If you have changed the default map files location, or if you are using SmartAssembly with a shared SQL server database, open SmartAssembly and click Options. The map file path is shown in the Reports Database Options section.

Fixing the map file

To correct the map file:

Download the patch from http://downloads.red-gate.com/EAP/Smartassembly/SmartAssembly_6.6.0.144_FixMpoMapFile.exe.
At a command prompt, type:
SmartAssembly_6.6.0.144_FixMpoMapFile "path\to\outputassembly.exe" "\\path\to\mapfiles"
- Replace "path\to\outputassembly.exe" with the obfuscated assembly that was built by SmartAssembly.
- Replace "\\path\to\mapfiles" with the path where the map files are saved.
Repeat for each assembly that was built with SmartAssembly 6.6.0.
If your map files are stored in a shared network location, you only need to run the command once per build from one computer. You do not need to run the patch on every computer which has SmartAssembly installed.

The map file is rewritten correctly, and a backup copy of the corrupt version is created in case of further problems.

The type names shown in the stack traces in newly-received error reports are now correct. It is not possible to recover the type names from error reports that were received while the map file was corrupt.

Was this article helpful?

Search support