Привет всем.

Тема такая. Есть IDL с описанием типов и enum'ов. midl, tlbimp — получаем сборку.
Добавляем эту сборку в References все замечательно, НО

// Code

using System;
using SOMETLB;

namespace Test
{
[Guid("7C87E4EC-6F2B-4487-8CD8-46A693E15A0A")]
[ClassInterface(ClassInterfaceType.None)]
public class Some : SOMETLB.ISome
{
// передаем параметр типа SomeEnum, описанный в SOMETLB как
// typedef [
// uuid(1E07C8C4-9E53-4f85-A654-3D5E2C77CD86),
// version(1.0)
// ]
// enum SomeEnum { One = 1, Two = 2 } SomeEnum;

public Test.Some1 Test(SOMETLB.SomeEnum p)
{
return new Test.Some1();
}

// надо имплементировать метод ISome1 ISome.Test(SomeEnum p)
// здесь и есть загвоздка, если в качестве параметра не enum,
// а любой другой тип (из SOMETLB или Test — неважно), то все нормально
// а так — нет (читай после кода)

SOMETLB.ISome1 SOMETLB.ISome.Test(SOMETLB.SomeEnum p)
{
return (ISome1)this.Test();
}

}
public class Some1 : SOMETLB.Some1
{
public Some1() {}
}
}

// END OF CODE

все коплилиться замечательно, но при попытке регестрировать сборку для COM Interop, а именно tlbexp Test.dll возникает ошибка типа

TlbExp error: Type library exporter encountered an error while processing 'Test'. Error: Type library exporter can not load type Test.Some (Error: System.TypeLoadException: Could not load type Test.Some from assembly Test, Version=0.1.946.28589, Culture=neutral, PublicKeyToken=4e6e
628f811813c because the format is invalid.).

есть мысли?

НУ ХОТЯ-БЫ КАКИЕ-ТО?

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

SS>НУ ХОТЯ-БЫ КАКИЕ-ТО?

Написать целиком managed декларацию для данного интерфейса, не ссылаясь на библиотеку типов. + см. ComImportAttribute

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

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

SS>>НУ ХОТЯ-БЫ КАКИЕ-ТО?

TK>Написать целиком managed декларацию для данного интерфейса, не ссылаясь на библиотеку типов. + см. ComImportAttribute

это было первое, что я сделал, но это не катит, по другим причинам (фатальным)

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

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

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

SS>>>НУ ХОТЯ-БЫ КАКИЕ-ТО? :(

TK>>Написать целиком managed декларацию для данного интерфейса, не ссылаясь на библиотеку типов. + см. ComImportAttribute

SS>это было первое, что я сделал, но это не катит, по другим причинам (фатальным)

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

Здравствуйте 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 экспортнуть, а что нельзя я не нашел, хотя и не особо рылся не успел еще

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

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

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

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

Незнаю, незнаю, вызов методов, изменяющих внутренние значения, изменяют их только в том обьекте, у которого я метод вызывал, а у "другого" ничего не меняеться...

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