Armenian Knowledge Base

Armenian Knowledge Base (https://forum.armkb.com/)
-   Languages, Compilers, Interpreters (https://forum.armkb.com/languages-compilers-interpreters/)
-   -   call function in managed DLL (C#) from unmanaged C++ ... ? (https://forum.armkb.com/languages-compilers-interpreters/25995-call-function-managed-dll-c-unmanaged-c.html)

Xman 05.12.2006 20:11

call function in managed DLL (C#) from unmanaged C++ ... ?
 
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 05.12.2006 20:45

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

TigrOm 05.12.2006 21:47

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

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

Junior 06.12.2006 07:45

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 06.12.2006 07:49

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

AvDav 06.12.2006 07:52

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

Agregat 06.12.2006 07:54

Quote:

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

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

AvDav 06.12.2006 08:08

Оппыньки :)

TigrOm 06.12.2006 08:19

Quote:

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

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

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


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

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

TigrOm 06.12.2006 08:20

Quote:

Originally Posted by Agregat (Post 533472)
Нет. Там в ПЕ хидере идет ссылка на .нет загрузчик. Который уже подгружает метадату и работает другим способом

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

Wedge 06.12.2006 08:22

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 06.12.2006 08:25

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

Wedge 06.12.2006 08:27

Quote:

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

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

AvDav 06.12.2006 08:29

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

TigrOm 06.12.2006 08:32

Quote:

Originally Posted by AvDav (Post 533484)
ну я от дот-нета очень далек, поэтому это первое что пришло в голову

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


All times are GMT. The time now is 22:38.

Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.