This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Custom Exception Types from a Managed COM+ (ES) Server Application
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
If you have done any ES development as I have, you have probably driven yourself crazy when you tried to define a custom exception in an ES server component, as you have been told to do by Microsoft, and then tried to catch it in a catch-block on the client. The exceptions were just not there! We first found this in using NUnit tests for our ES components. It turns out that the Microsoft base exceptions turn up just fine and actually the base exception type that you derive from is the one that shows up. Google searches confirmed this problem. Now, after reading Bob DeRemer's new article, Throwing Custom Exception Types from a Managed COM+ Server Application in the March 2003 issue of MSDN magazine, I understand why.
There is no issue when passing exception data across AppDomain boundaries as long as the Exception is coded correctly and marked with the Serializable attribute. The issue rears it's head when error info is passed from managed code into unmanaged and back the other way. As Bob shows, the internals of ES, the COM+ surrogate process (DLLHOST.EXE) and the services it provides are still implemented in unmanaged code and implicit transitions across the boundary may occur at times without your knowledge.
What happens then? Well, good ole' COM Interop again! More specifically, as Bob shows, if your CustomException is routed into unmanaged code, the transition from managed to unmanaged peserves the HRESULT and the error message, but does not preserve the type of the exception. Thus CustomAppException gets munged into hr=0x80121600 in unmanaged COM and then the CLR back on the other side of the transition has to figure out what the heck to do with that. It looks it up in a list of HRESULTs that it knows how to transform. So, in Bob's example, CustomAppException derives from ApplicationException and thats what the type is after the transition back into managed code.If it doesn't know what the heck it it is, you get that dreaded COMException that we have all come to know and love.
The real genius of Bob's article though is diving into the ServicedComponent architectire and showing what's under the covers. The very interesting thing is that with a COM+ server application and COM+ proxy installer is that the interprocess communication is done using .NET Remoting on the client and server with a DCOM communications channel in the middle! He talks about the “complex architecture where there are numerous places where the managed code interacts with unmanaged code - some documented, others undocumented.” Then he proceeds to show where CustomAppException gets changed into a base exception type (ApplicationException, COMException, etc.) lies in optimizations that ES makes.
These optimizations, made while accessing serviced components running in a COM+ server application, “utilize COM where possible in order to avoid the additional overhead incurred by the remoting serialization logic. This optimization, however, is the reason the custom exception is transformed into a more generic exception type.”
Bob then goes to show two workarounds. The first is designing your interface methods in such a way that COM+ will NOT attempt to optimize your call through DCOM. In other words, use a type like Object that cannot be serialized by the Interop marshaler. This will force the the method invocation to use Remoting serialization and then you're fine. He has example code. The other approach he then shows is to expose the functionality using a formal .NET interface that is implemented in a thin managed wrapper class which delegates all calls to the primary .NET class, which is also the class made accessible to managed clients. Of course, you use [ClassInterface[ClassInterfaceType.None)] on your class implementation.
Thanks Bob! Myself and our development team were stuck on this and had all but given up since extensive Google searches had produced many people who reported the issue but no one with a solution. This is is a must-read article!
Previous Topic
