Red Gate forums :: View topic - Stack across multiple assemblies
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SmartAssembly 6
SmartAssembly 6 forum

Stack across multiple assemblies

Search in SmartAssembly 6 forum
Post new topic   Reply to topic
Jump to:  
Author Message
rs



Joined: 12 May 2010
Posts: 11

PostPosted: Mon Jul 22, 2013 9:56 am    Post subject: Stack across multiple assemblies Reply with quote

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.
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 184

PostPosted: Tue Jul 23, 2013 9:48 pm    Post subject: Reply with quote

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/Content/SmartAssembly/help/6.7/SA_Errors_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
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
rs



Joined: 12 May 2010
Posts: 11

PostPosted: Thu Jul 25, 2013 8:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
DanielRose



Joined: 30 Oct 2009
Posts: 14
Location: Aachen, Germany

PostPosted: Fri Jul 26, 2013 8:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
jessica.ramos



Joined: 23 Apr 2012
Posts: 184

PostPosted: Tue Jul 30, 2013 10:38 pm    Post subject: Reply with quote

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
Technical Support
Red Gate Software Ltd.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group