Surely this is a bug
Morantex
Posts: 10
I am in touch with RedGate just now over an issue that stems from SA being unsure about where to find a referenced assembly and errors that arise when it finds the wrong/unintended version.
However during my experiemnts to resolve this I discovered that SA can obfuscate an assembly without reporting errors yet silently modify the referenced assemblies list.
If SA finds the "wrong" version of a referenced assembly as it obfuscates but doing so causes no errors, then the generated assembly can end up with a ref (dependency) upon a different assembly version to that used before obfuscation.
In my view this simply has to be a bug or design flaw, because unless we manually check every generated assembly to verify that refs are the same after as they were before, we will not be sure.
If we then ship obfuscated code to customers we may experience failures that are due to this. Yes we retest after obfuscating but that is not garuanteed to pick up a subtle error like a changed assembly version reference and may pass many tests yet eventually fail in the field, and probably fail in a very bewildering way.
I'd like to see if other's have experienced this - because as I say altering the assembly internals (obfuscating it) is one thing but alteirng the list of assemblies and versions that it depends upon is unacceptable surely?
At the very least SA should report a Warning like "Warning SA was unable to locate v 1.2.3.4 of assembly X but did locate v 3.4.5.6 instead and the obfuscated output assembly now references this version".
It strikes me as a very good idea to simply accept that if the specific version of a referenced assembly cannot be located then this should itself be immediately reported as an error and no further attempt made to proceed by using some other arbitrary version of the assembly that SA is able to find.
Thanks
Hugh
However during my experiemnts to resolve this I discovered that SA can obfuscate an assembly without reporting errors yet silently modify the referenced assemblies list.
If SA finds the "wrong" version of a referenced assembly as it obfuscates but doing so causes no errors, then the generated assembly can end up with a ref (dependency) upon a different assembly version to that used before obfuscation.
In my view this simply has to be a bug or design flaw, because unless we manually check every generated assembly to verify that refs are the same after as they were before, we will not be sure.
If we then ship obfuscated code to customers we may experience failures that are due to this. Yes we retest after obfuscating but that is not garuanteed to pick up a subtle error like a changed assembly version reference and may pass many tests yet eventually fail in the field, and probably fail in a very bewildering way.
I'd like to see if other's have experienced this - because as I say altering the assembly internals (obfuscating it) is one thing but alteirng the list of assemblies and versions that it depends upon is unacceptable surely?
At the very least SA should report a Warning like "Warning SA was unable to locate v 1.2.3.4 of assembly X but did locate v 3.4.5.6 instead and the obfuscated output assembly now references this version".
It strikes me as a very good idea to simply accept that if the specific version of a referenced assembly cannot be located then this should itself be immediately reported as an error and no further attempt made to proceed by using some other arbitrary version of the assembly that SA is able to find.
Thanks
Hugh
Comments
As I mentioned in your ticket, SmartAssembly choosing the wrong dependencies is indeed a bug. It is unfortunate, but as I understand it, this behavior is kept as it's important for applications running on different frameworks.
When this behavior causes issues, the workaround is to use the MandatoryPath. However, you're right that it would be a good idea to warn users that a different dependency was used, regardless of whether or not it causes any obvious errors. I've created a feature request for this (with reference SA-1593). Thank you for the suggestion and again, sorry that you're experiencing this issue
Jessica Ramos | Product Support Engineer | Redgate Software
Have you visited our Help Center?