Event methods accesibility

According to the CLS specification, the accessibility of the methods for adding, removing, and raising an event must be identical. There appear to be a few problems with this:

1) According to the Managed C++ specifications, if one declares a public event without any attempt to provide one's own event access methods, clearly the most common case, the compiler generates public add_ and remove_ methods for the event and a protected raise_ method for the event. This appears to
contradict CLS guideleines for the event and make events declared in MC++ non-compliant with the CLS specification.

2) If I provide my own event member methods signature for the event, I might want to allow any code to add or remove event handlers for the event, the
common case, while restricting the ability to raise the event to classes in my own assembly. I can do this by specifying that the accessibility for the event add_ and remove_ remove methods be made public while the accessibility for the raise_ method is made public private. If I do this, once again I am not complying to the CLS specification.

Clearly not complying to the CLS specification will not allow my class to be used by other .NET languages, which is something which I don't want. However being able to control which classes are allowed to raise a particular class's event seems to be a common idiom in computer programming. I know that .NET makes a big deal about only the class which contains the event being able to raise the event, but it is clear that designs may call for
other classes being able to raise the event also. This may not have been a big deal for C++ programmers if the 'friend' functionality were allowed in the MC++ specification, but it is not. Luckily the concept of assembly classes having access priveleges which classes outside the assembly do not have, was added to MC++ specification. However, the CLS guidelines for event
methods having equal accessibility makes it impossible to vary the
accessibility of event methods. Hopefully someone understands this issue and knows of a way out of this conundrum.

You are so true.

However, I've yet to devise a method where I can raise an event from outside of the main class without having to have an intermediary.

That said, the fact that hooks into the event can be made (certainly in C++) from anywhere is a very nice touch.

The only way I've found to do this is to have a seperate event and class to handle this situation (i.e. a class which is inherited from the class from which you wish to raise the event, which raises another event which can be hooked into from anywhere).

Whereas design wise this is not very nice, it does seem to work quite well.

I do believe this to be a shortfall of the .NET framework SDK. However, as with all good frameworks there are ways around the problem.

10thPower.