Management Studio "connector circles" remain green after certain errors.

These types of errors are usually because the exception that indicates the error is not serializable, and therefore the error notification cannot be sent across the WCF boundary to Management Studio. This occurs even if inner exceptions are not serializable.

• Fix this error.
• Future versions of Identity Broker should not rely on serialization of classes that may be external to the original design, which can easily happen in a plug-in architecture.

Rod, can you think of any other things I could be looking at for potential causes?

As listed in my work log, the exception is completely serialized with no inner exceptions or additional properties, but under no circumstances does it trigger red circles correctly.

It can also be missed as the exception isn't deserializable on the Management Studio side. This would not be a problem with something like the chris21 connector as the exceptions passed tend to be system exceptions.

A way to test this is to put the library containing the exception in the Management Studio executable directory, and the exception will actually show as red, instead of a continuing green circle.

If this is the case, then future versions of the Framework need to ensure that only exceptions known to the client are passed, and to republish unknown exceptions with enough detail for the client.

I'll give that a try tomorrow, but it sounds quite likely as replacing my custom exception with an empty Exception made it work.

Strangely enough, my implementation of the custom exception is just the same as the others, inheriting from UnifyException and having the deserialization constructor.

Shane is correct, that the exception is not known to the client.

Chris21 does not use a custom "Chris21Exception : UnifyException", and instead uses known System exceptions with the chris21 exception details.

Either, the client needs a reference to the file containing the custom AurionException, or use known System exceptions ("known" refers to any serialized exception already referenced by the client).

Thanks, makes total sense now that I think about it, and I'd have noticed it sooner if not for the fact that I'm certain a number of our other connectors (maybe just mine, but still) do this and I've never heard it reported... a tad worrying.

I'll have a look at chris21 to see what the most appropriate SystemExceptions are and replace the custom Aurion ones immediately.

Confirmed working in 3.0.4