How can we help you today? How can we help you today?
Morantex
Activity overview Badges (0) Posts (4) Comments (2)

Comments

Sort by recent activity
UPDATE: Disabling the dynamic proxy option on two of the more relevant assemblies here saw the 73 uS/msg fall to 65 uS/msg. (That is an obfuscated release build) but this is still performing worse than a straightforward debug build. Hugh / comments
  1. Community
  2. SmartAssembly
  3. The runtime cost of obfuscation
UPDATE: Disabling the dynamic proxy option on two of the more relevant assemblies here saw the 73 uS/msg fall to 65 uS/msg. (That is an obfuscated release build) but this is still performing worse ...
0 votes
jessica.ramos wrote: Hi Hugh, I'm working with you again through email, but I didn't want your forum post to feel neglected [image] As I've mentioned, the issue with how SmartAssembly handles versioned dependencies is a known bug (SA-31). This bug exists because SmartAssembly unfortunately has no way of knowing what paths were used by the original VS project (as they're not stored in the resulting assembly) and as a result, SA might end up using a different assembly that has a similar name even if it has a different version or is from a different location than the original (in some way though, this is actually a good thing as it would help when users are retargeting assemblies against later .Net versions). Again, I'm very sorry about this and the risk of runtime issues it might cause but at the moment, the only workaround is the MandatoryPath attribute. However, I have just recalled a bit of a hacky workaround--if SmartAssembly cannot find youre dependencies when it first loads your project, it will prompt you to browse and point to the needed DLL. If you can hide your dependencies (i.e. move them outside of the main assembly's folder), you can then point SmartAssembly to the right DLLs. Regarding the ability to specify MandatoryPaths from the UI, I'd also created a feature request (with SA-1591), although I do not know any timeline for this at the moment. Hi Jessica - OK thanks for taking the time to explain this, much appreciated. My main issue has been resolved now - you may recall we found a simple workaround. However I am still waiting to hear back from you guys about the versioning problem. In a nutshell I consider it inexcusable for SA to process a user's assembly and then identify dependencies that have different versions to those referenced by the original un-obfuscated assembly. Doing so will very rarely - if ever - result in anything other than serious and bewildering problems. If I have an assembly A that depends on X v1.1.1.1, Y v2.2.2.2 and Z v 3.3.3.3 then after obfuscation of A I do not expect the obfuscated assembly to refer to other versions of X, Y and Z - yet SA can and does do this without warning. I understand that SA can't know the locations of the original assemblies dependencies and that it must use some heuristic, but it should INSIST only on assemblies which have the SAME version numbers as those referenced by the original input assembly - if it can't find any then it should INFORM the user and let them choose whether to use this wrong version or browse for an alternative - not silently settle for any old assembly that hapens to have the same name with no regard to its version. In my view this is a serious bug because we could obfuscate an assembly and ship it and find that at runtime all hell breaks loose because the wrong versions of other assemblies are being picked up. Please can someone let me know if this is or is not deemed to be a bug because we entrust a great deal to SA. Thanks / comments
  1. Community
  2. SmartAssembly
  3. Referenced Assemblies
jessica.ramos wrote: Hi Hugh, I'm working with you again through email, but I didn't want your forum post to feel neglected As I've mentioned, the issue with how SmartAssembly handles versioned...
0 votes
Total activity
8
Last activity
Member since
Following
0 users
Followed by
0 users
Votes
0
Subscriptions
2