Контролы .NET не реализуют всех необходимых интерфейсов для работы в качестве ActiveX - за ненадобностью. Для использования в унаследованных (aka устаревших) системах нужно делать свои контролы на основе UserControl. UserControl реализует интерфейсы, требуемые для использования в контейнере MFC. Т.е., скажем, для использования в контейнере VB нужны отдельные танцы с бубном.

But if I write a Windows Forms control, doesn't that mean that only .NET applications can use it? There aren't many of them out there, at least not yet, so shouldn't I wait for a critical mass before I invest my development dollars? To help you answer "No" to these questions, the UserControl base class contains all the functionality that it needs to be accessible to ActiveX control hosts such as Visual Basic 6.0. This will allow a developer of a .NET control to take advantage of the enormous installed base and make a lot of money.
     You have to write one relatively small piece of code to make your .NET control accessible to ActiveX hosts. ActiveX controls make several registry entries that standard COM servers don't, so you have to add this functionality to your .NET control. The CLR contains prefabricated functions that will make and remove these entries. These go by the names Control.ActiveXRegister and Control.ActiveXUnregister. You need to provide two external functions in your control class marked with attributes that tell the .NET COM registration utility to call them during the registration process. These functions need to delegate to ActiveXRegister and ActiveXUnregister (see Figure 14). That's the only extra piece of code that you have to write today, and I wouldn't be surprised if it moved into the base class in some future version.

Вопрос: а нельзя ли это дело автоматизировать?
Например, сделать спец.контрол на Нет, который может включать любой другой контрол Нет, с прозрачной передачей всех событий, свойств и методов ?

Блин, рано обрадовался
События-то ловятся, но вот параметры событий нифига не передаются.