Stack across multiple assemblies

rsrs Posts: 13 Bronze 2
edited July 30, 2013 5:38PM in SmartAssembly
We have been users of SmartAssembly for several years now, but are currently stuck with v5 because of an issue with cross-assembly stacks. I wanted to ask about this again as we have recently encountered an issue with v5 that is likely to force us to upgrade in the near term, so I'm more keen that ever to figure out a solution for the cross-assembly stack issue.

The scenario is this - our app consists of around 50 assemblies which are mostly loaded dynamically by the main .exe. All of the assemblies are obfuscated with smartassembly, with the main .exe having the exception reporting functionality too. Any exceptions in our app, regardless of where they originate, are captured by the exception reporting in the main .exe

We include an assembly attribute "AddAssemblyToExceptionReportsAttribute" that we were told about by SmartAssembly support in each of our assemblies. If this attribute is applied to an assembly, then any stack frames from that assembly in the exception report will include line number and local variable information - which is absolutely vital as the majority of our applications functionality lives in our secondary assemblies and not the main .exe.

The problem is that support for that attribute was removed in SmartAssembly v6 - if your exception contains stack frames from other assemblies, they will no longer include any line number or variable information. That is why we are currently stuck on v5.

So my question is this - is there any way to achieve this functionality with SmartAssembly - i.e. be able to get full stack traces, across all of our SmartAssembly built assemblies. What we cannot do is include custom exception traps in each of our assemblies, embed all the assemblies (components are loaded dynamically at runtime) or enable the exception handling functionality in each (this causes huge bloat to each assembly size). The exception handling works fine as it - it is just getting full stack trace information for our secondary assemblies that is the problem.

Seems to me this is a very common scenario these days - building apps as a set of components, dynamically loaded from configuration at runtime - so I'm thinking many others would benefit from this too.

Comments

  • Jessica RJessica R Posts: 1,319 Rose Gold 4
    Hi there and many thanks for your post!

    The attribute you mention ("AddAssemblyToExceptionReportsAttribute") was something of an undocumented "hack" back in version 5 to get error details from secondary assemblies, but there are now two different options to get this functionality with SmartAssembly version 6. In order to do this though, SmartAssembly would need to instrument each of your secondary assemblies, which I'm very sorry to say means the two options may not be optimal in this case..

    To get error information across multiple assemblies, you'll either need to

    1. Merge the assemblies into your main assembly

    or

    2. Process each individual assembly with its own SA Project and enable error reporting on each one (as described here: http://www.red-gate.com/supportcenter/C ... rrors_DLLs )

    I realize that merging is not an option since your assemblies are loaded at runtime, so I'm afraid that enabling error reporting on the individual assemblies would be the only other way around this in version 6. :/

    Jessica Ramos | Product Support Engineer | Redgate Software

    Have you visited our Help Center?


  • rsrs Posts: 13 Bronze 2
    We are already instrumenting every assembly with SmartAssembly (that was still necessary with the AddAssemblyToExceptionReportsAttribute attribute), so option 2. sounds like the option to explore further.

    The immediately obvious problem with that (apart from having to fill in all the error handler template information etc.) is that it seems to inflate the size of the obfuscated assemblies substantially, even though it's only the .exe that does the actual error reporting, right? I'm guessing that SmartAssembly is including a copy of the error handler template (forms, classes etc. for the actual reporting) in every assembly we instrument, .exe or otherwise.

    Seems like what we could really use is a third error reporting option for the non-exe assemblies - "Instrument this assembly, but don't include all the handler baggage as the assembly will be used with an EXE that has the full error handler stuff". With the intention that this will include the necessary instrumentation to give us the cross-assembly stack details.

    Does that make sense? I'm really, really hoping that there is a solution on the way for this situation (we first flagged it up as an issue a couple of years back) as I don't even want to start looking at alternatives - SmartAssembly has been so invaluable to our support efforts, but when we start compiling on our tfs server for .NET 4.5 we will have run out of time and won't be able to carry on using SmartAssembly v5.5 any longer.
  • I did a bit of disassembly. When error reporting is added to an assembly, SA does two things:
    • The code of all methods, constructors and properties is wrapped in a try-catch, which allows getting the local values of variables.
    • The error handling template code is added.
    The error template code is only used in two cases: If the assembly is an application, and if the assembly manually passes an exception to SmartAssembly, using SmartAssembly.ReportException.ExceptionReporting.Report(). So if you have a DLL, and it doesn't manually pass an exception to SA, the code is AFAICT unnecessary.

    This (useless) code may or may not result in much bloat of your assembly, since it is fixed in size. On the other hand, since every bit of code you have is wrapped in a try-catch, this will definitely bloat the code, especially if you have many small methods and simple properties.
  • Jessica RJessica R Posts: 1,319 Rose Gold 4
    Daniel Rose - Many thanks for the research you did on this!

    RS - Ah, I've found the feature request that was created a while back (SA-1170 - "Add option to not add unhandled exception handler, just instrument the methods")

    I've made a note that you've followed up on the request. I'm afraid though that we still don't have a timeline to implement it yet as the request has been quite rare. Processing the assemblies individually will likely be the only option for the near future at least :/

    My apologies for this inconvenience!

    Jessica Ramos | Product Support Engineer | Redgate Software

    Have you visited our Help Center?


Sign In or Register to comment.