Regression in 6.11 when referencing System.Windows.Input.ICommand
puffin
Posts: 4
I have a .Net 4.0.3 assembly that references PresentationCore to use System.Windows.Input.ICommand (it is part of a WPF application).
When obfuscating with SmartAssembly 6.8.0.121. the obfuscation succeeds.
When obfuscating with SmartAssembly 6.11.1.365 the obfuscation fails with the following error:
Note that it thinks the Type resides in System.dll when it really resides in PresentationCore. Presumably this is happening because ICommand was moved to System.dll in Framework 4.5 and SmartAssembly has failed to handle the differences between frameworks correctly.
For now, we've rolled back to 6.8, but it would be great to get this fixed so that we can use future versions of the product.
Edit: I found an old copy of 6.10.0.218 and this issue appears to occur in that version, too. It's probable that the bug was introduced in 6.9 along with 4.5.1 and 4.5.2 support.
When obfuscating with SmartAssembly 6.8.0.121. the obfuscation succeeds.
When obfuscating with SmartAssembly 6.11.1.365 the obfuscation fails with the following error:
SmartAssembly has encountered an invalid symbol:
[System]System.Windows.Input.ICommand
The most likely cause is that SmartAssembly has used a different version of a dependency from the version used by <my assembly>
If the details below are wrong, please use the MandatoryPath attribute in the .saproj file to ensure that the correct version of the dependency is found.
Assembly that should contain the missing symbol: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0.3\System.dll
Note that it thinks the Type resides in System.dll when it really resides in PresentationCore. Presumably this is happening because ICommand was moved to System.dll in Framework 4.5 and SmartAssembly has failed to handle the differences between frameworks correctly.
For now, we've rolled back to 6.8, but it would be great to get this fixed so that we can use future versions of the product.
Edit: I found an old copy of 6.10.0.218 and this issue appears to occur in that version, too. It's probable that the bug was introduced in 6.9 along with 4.5.1 and 4.5.2 support.
Comments
In the meantime is using the mandatoryPath workaround sufficient?