Здравствуйте TK, Вы писали:

TK>Если нельзя менять декларацию базового интерфейса, то тогда можно написать свою утилиту экспорта.
TK>PS А что за фатальные причины?

Дело в следующем, надо иметь возможность подключать плагины, да и просто использовать движок где угодно.
Если делать стандартно — то есть все на .NET — получаеться полная чушь. Даже не знаю как покороче обьяснить, но
попробую:

1. Написана некоторая Application под COM+ (не знаю как это в .NET называеться, в общем расширяем класс ServicedComponent)
2. Это приложение регестрирует несколько COM интерфейсов, которыми и общаеться с клиентами
3. Если поднимать его из scripting, например, то все хорошо, но как только я делаю reference на эту сборку, то код следующего вида работает неверно:

public class Test
{
private SomeComponent myComponent;

public ISomeComponent Component
{
get {
if (this.myComponent == null)
this.myComponent = new SomeComponent();
return this.myComponent;
}
}
}

что я получаю, в scripting, вызвав 2 раза подряд property Component — я получаю указатель на один и тот же обьект (hash code равны), а в managed приложении (ASP.NET Application), я вызываю 2 раза подряд Component — я получаю 2 РАЗНЫХ объекта (hash code разные), хотя конструктор SomeComponent() выполнялся 1 раз (это логируеться)

вот этого я не понял напрочь

есть еще один способ юзать приложение, описывать интерфейсы самому — тоже глючит, при изменении интерфейсов, бывает вызываются не те методы, которые вызываешь, где-то он кеширует смещения и не реагирует на изменения

способ, который дал возможность работать всему правильно — написать нормальную IDL с интерфейсами, и реализовывать их в движке, а использовать любым клиентом (среда общения — COM) но тут проявился этот глюк экспортера в тлб, который мне тоже непонятен, как это блин то, что накомпилил компилятор have bad format — я не пойму, да и описания на эту тему, что можно в TLB экспортнуть, а что нельзя я не нашел, хотя и не особо рылся не успел еще