[Xman]

Provet vsem, kto nibud' delal takoe ?
skajem ya imeyu DLL sdelanni v dot.net i mne nado sdelat' druguyo dll napisanni na C++ (jelatelno v Borland C++) kotori budet v sebe imet' funkciyu kotoraya v svoyu ochered' doljen vizivat' funkciayu v DLL zdelanni na dot.net (C#).

[AvDav]

а какая разница чем сделан длл, он и в Африке длл
1. LoadLibrary()/GetModuleHandle()
2. GetProcAddress()

[TigrOm]

http://www.codeproject.com/csharp/ManagedCOM.asp

вне COM не пробовал.
Может быть не все гладко с трвиальным LoadLibrary, что связано с иной логикой загрузки .NET приложений.

[Junior]

Indz tvum a ughigh kanchel hnaravor chi (LoadLibrary()/GetModuleHandle()). Porci .NET dll-i vra COM Wrapper sarqel, u dra mijocov C++-ic kanchel.
Isk [email protected] kargi [email protected] Microsoft-i forumnerum taln a.
http://forums.microsoft.com/msdn/default.aspx?siteid=1

[Agregat]

Да, надо писать КОМ враппер.

[AvDav]

TigrOm джан, а разве .нет или любые другие вин-приложения не загружаются по одному и тому же принципу, согласно PE формату? Единственная проблема что я вижу с LoadLibrary()/GetProcAddress(), это что сигнатура С# функции котороую надо вызвать из C++, должна иметь исключительно POD-types в качестве формальных параметров и возвращаемого значения, и не иметь чисто C#-ские классы, потому как неизвестно какой C++ класс ему должен соответствовать, да и в принципе может ли?
Не понимаю одного, зачем все смешивать, пусть либо будет только C# длл-ки, либо C++-шные.

[Agregat]

Originally Posted by AvDav

TigrOm джан, а разве .нет или любые другие вин-приложения не загружаются по одному и тому же принципу, согласно PE формату? Единственная проблема что я вижу с LoadLibrary()/GetProcAddress(), это что сигнатура С# функции котороую надо вызвать из C++, должна иметь исключительно POD-types в качестве формальных параметров и возвращаемого значения, и не иметь чисто C#-ские классы, потому как неизвестно какой C++ класс ему должен соответствовать, да и в принципе может ли?
Не понимаю одного, зачем все смешивать, пусть либо будет только C# длл-ки, либо C++-шные.

Нет. Там в ПЕ хидере идет ссылка на .нет загрузчик. Который уже подгружает метадату и работает другим способом

[AvDav]

Оппыньки

[TigrOm]

Originally Posted by AvDav

TigrOm джан, а разве .нет или любые другие вин-приложения не загружаются по одному и тому же принципу, согласно PE формату? Единственная проблема что я вижу с LoadLibrary()/GetProcAddress(), это что сигнатура С# функции котороую надо вызвать из C++, должна иметь исключительно POD-types в качестве формальных параметров и возвращаемого значения, и не иметь чисто C#-ские классы, потому как неизвестно какой C++ класс ему должен соответствовать, да и в принципе может ли?
Не понимаю одного, зачем все смешивать, пусть либо будет только C# длл-ки, либо C++-шные.

Поясню что я имел ввиду:

При загрузке любых модулей с PE, система распознает что именно должно происходить с exe/dll модулем, а именно при загрузке управляемой сборки в неуправляемый поток приложения система иницализирует CLR, при этом создавая домен приложаения для управляемой сборки и доменно-нейтральные "сборки" для неуправляемого кода. Взаимодействие же через границы сборок может происходить только путем маршалинга. Вызывающий неуправляемый код ничего не знает о способах сериалкизации/маршалинга типов/вызовов управляемого кода. Отсюда и потребность в COM wrapper-e.


А загрузка с PE ессно происходит одинаково с точки зрения системы, о чем речь? Но вот что потом?

П.С. Кроме того элементарного экспортирования функций из модулей управляемого кода в формате "dllexport" я не обнаружил. Вызов функций управляемого кода происходит видимо по аналогии с COM вызовами, через "фабрику классов".

[TigrOm]

Originally Posted by Agregat

Нет. Там в ПЕ хидере идет ссылка на .нет загрузчик. Который уже подгружает метадату и работает другим способом

Ну да, но все это происходит автоматически.
Т.е. видимо вызывая LoadLibrary, все должно сработать.

[Wedge]

Use the Assembly Registration tool (Regasm.exe)

The Assembly Registration tool reads the metadata within an assembly and adds the necessary entries to the registry, which allows COM clients to create .NET Framework classes transparently.

[AvDav]

Ok, спасибо за пояснение.

[Wedge]

Originally Posted by AvDav

а какая разница чем сделан длл, он и в Африке длл
1. LoadLibrary()/GetModuleHandle()
2. GetProcAddress()

Не согласен.
Dot Net-овский dll это нечто совсем иное, чем обычный.

[AvDav]

ну я от дот-нета очень далек, поэтому это первое что пришло в голову

[TigrOm]

Originally Posted by AvDav

ну я от дот-нета очень далек, поэтому это первое что пришло в голову

вообще, технологии стараются делать такими чтоб можно было без значительных усилий пользоваться некими общими принципами/правилами. Так что вектор мыслей в принципе тебя бы привел к решению проблемы