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
Hi again Hugh![:]](/hc/user_images/01JKB9C2MQMY296643T8JZQD87.png ":]")
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