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

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

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

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

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

SS>public class Test
SS>{
SS> private SomeComponent myComponent;

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

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

SS>вот этого я не понял напрочь
Все правильно. В managed приложении Вы получили две ссылки на два разных TransparentProxy которые указывают на один объект.

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