We were hunting down a weird bug at work today, and came across this interesting problem with Enterprise Services. If you send a non-empty decimal array into a ServicedComponent you get a “The parameter is incorrect.” argument exception.

Just create a method that takes a single argument, the decimal array, in your server activated ServicedComponent and give it a trial run. You’ll need to use an interface to get the COM magic going though.

           [assembly: ApplicationActivation(ActivationOption.Server)]
public interface ITest { void Test(decimal[] test); } public class TestComponent :
ServicedComponent, ITest { public void Test(decimal[] test) {} } class Client { static
void Main() { TestComponent cl = new TestComponent(); cl.Test(new decimal[] {1m, 2m});
} } 
        

Have fun ;)

I keep getting questions about the use of custom exceptions with serviced components, and why they sometimes lose their type “on the wire”. As I never really finished this topic in my previous blogentries, I thought it was about time I provided a small conclusion.

From my somewhat limited understanding of the subject there is an optimization taking place in the underlying infrastructure. If your method signature only contains isomorphic types like integers, strings and doubles it is more efficient to use COM Interop to communicate with serviced components because then you don’t have to utilize the .Net serialization engine. However if your method signature contains more complex types, non-isomorphic types like datasets, the .Net serialization engine will be used together with .Net remoting over a custom DCOM channel. In the latter case your custom exceptions will work as expected. Unfortunately, in the first case you will be limited by COM Interop that uses the COM infrastructure, HRESULT values and IErrorInfo, to support exception handling. The result is that exceptions with a registered HRESULT value like most system exceptions will be recreated and returned as expected while custom exceptions most likely will reappear as a COMException type if you provide your own HRESULT or as an ApplicationException type if your exception simply derives from that base class.

As far as I know there is no known fix for this problem short of forcing a more complex method signature, which isn’t exactly something I would recommend.

Tomas agrees with me that the exception irregularities found when using Enterprise Services are indeed interesting, and asks for clues. I have yet to find any, but I would be very surprised if it wasn’t related to the marshalling services.

After doing a series of tests I’ve found that all basic types (integer, string, decimal …) that probably have some optimized marshalling code introduce the exception problem, but as soon as you add a custom type to the method signature, either it is a value or reference type, the expected behavior takes place.

If I find the time I’ll try to delve more thoroughly into the problem area. This situation is really annoying and I have yet to see any documentation or discussion about the problem. Makes you wonder…

Andreas Eide and I have been playing around with serviced components and custom exceptions, and so far we have discovered some interesting results.

I have a test-setup running Windows XP SP1 and the .Net Framework v1.0 SP2. I have created a serviced component and configured it to run in a server activated application. The component implements the test interface below and uses no configuration attributes. I have a client application that invokes all of the interface methods and each of the method implementations in the component simply throw the same custom ApplicationException derived exception.

The interesting thing is that three of the methods return the application exception while the last two return the custom exception to the client.

           public interface ITest { int Test1();
// ApplicationException object Test2(); // CustomException void Test3(); // ApplicationException
void Test4(object o); // CustomException Guid Test5(DateTime dt); // ApplicationException
} 
        

I guess what is left now is to figure out why this happens, and I guess there are quite a few things to consider. Does it have anything to do with reference objects vs. value objects being passed; does it have anything to do with the shared memory buffer sometimes used by LRPC? What is obvious though is that there is a difference in the way exceptions are marshaled across processes.

What is obvious though is that there is a difference in the way exceptions are marshaled across processes. It seems that in some cases IErrorInfo and Marshal.ThrowExceptionForHR does its magic and in other cases the entire exception object is marshaled transferred.

Once again Clemens has been down in his secret underground lab working on some new and exiting enterprise services enhancements. This time he has cooked up a way to write AOP style serviced component extensions in the same brilliant manner we have grown accustomed to. From the looks of it his framework is designed to provide AOP through interception techniques. Giving developers the ability to write these kinds of extensions is indeed a huge and very important improvement to the existing serviced component architecture.

The ability to effectively separate crosscutting concerns is extremely important in modern software designs. Security, adaptability and runtime tuning, monitoring, validation and physical tier independence are some of the areas where one might want to apply these techniques.

This sort of functionality has been on my wish list for some time now, and I can’t wait for the bits to come out.