Извините за вопрос чайника. Ответ в инете не нашел, в доках тоже.

Есть ли определенный порядок вызова делегатов события?

Тесты показывают что порядок вызова делегатов соответствует порядку регистрации делегатов.

Но точно ли это так, гарантированно ли это, будет ли это так же в других версиях дотнета?

Вот кусочек из Events (C# Programming Guide)

When an event has multiple subscribers, the event handlers are invoked synchronously when an event is raised

Ни чего не говорится о порядке выполнения делегатов. Так же не нашел где сказано что порядок выполнения не гарантирован.

Сон Веры Павловны Как бы намек


Спасибо, в примере увидел GetInvocationList(), в документации к которому сказано:
Returns the invocation list of this multicast delegate, in invocation order
И:
Invoking these delegates sequentially, in the order they appear in the array, produces the same results as invoking the current instance.

Т.е., какой-то порядок есть, но какой он, не сказано.

Сон Веры ПавловныИ да, при использовании явной реализации событий (add/remove) разработчик внутри класса может организовать хранение цепочки делегатов в любом виде (см. у Рихтера главу "Explicitly Implementing an Event" и выше про класс EventSet), и порядок вызова здесь может быть абсолютно произвольным. И завязывать архитектуру, опираясь на предположения о каком-то порядке вызова делегатов события - признак того, что с архитектурой что-то не так.

Про оба этих ваших предложения. У нас нет возможности повлиять на архитектуру. Мне надо наследоваться от контрола из закрытой библиотеки (без исходных текстов). Этот контрол выполняет важное действие "Обработка1" по событию "Событие1" в другом, вложенном в него контроле. Мне в наследнике тоже надо подписаться на тот вложенный контрол (он public). И мне важно, чтобы действие "Обработка1" происходило обязательно до того как сработает мой метод в наследнике, тоже срабатывающий по тому же событию "Событие1".

И да, с помощью рефлекшена получилось: перед подпиской в моем наследнике отписать все остальные делегаты с помощью EventInfo.RemoveMethod, сохранив их; подписать наследника на свой метод, который будет вызывать сначала все остальные делегаты, гарантировав выполнение нужного метода "Обработка1", а потом выполнять уже свое действие.
Не думаю что базовая архитектура механизма событий изменится в будущем, и что изменятся/пропадут: метод EventHandler.GetInvocationList и поля EventInfo.AddMethod и EventInfo.RemoveMethod.

Тест уже показал что все получается

Спасибо большое за подсказку!