View Full Version : 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#).
а какая разница чем сделан длл, он и в Африке длл
1. LoadLibrary()/GetModuleHandle()
2. GetProcAddress()
http://www.codeproject.com/csharp/ManagedCOM.asp
вне COM не пробовал.
Может быть не все гладко с трвиальным LoadLibrary, что связано с иной логикой загрузки .NET приложений.
Indz tvum a ughigh kanchel hnaravor chi (LoadLibrary()/GetModuleHandle()). Porci .NET dll-i vra COM Wrapper sarqel, u dra mijocov C++-ic kanchel.
Isk amenachisht@-es kargi harcer@ Microsoft-i forumnerum taln a.
http://forums.microsoft.com/msdn/default.aspx?siteid=1
Agregat
Dec 6, 2006, 07:49
Да, надо писать КОМ враппер.
TigrOm джан, а разве .нет или любые другие вин-приложения не загружаются по одному и тому же принципу, согласно PE формату? Единственная проблема что я вижу с LoadLibrary()/GetProcAddress(), это что сигнатура С# функции котороую надо вызвать из C++, должна иметь исключительно POD-types в качестве формальных параметров и возвращаемого значения, и не иметь чисто C#-ские классы, потому как неизвестно какой C++ класс ему должен соответствовать, да и в принципе может ли?
Не понимаю одного, зачем все смешивать, пусть либо будет только C# длл-ки, либо C++-шные.
Agregat
Dec 6, 2006, 07:54
TigrOm джан, а разве .нет или любые другие вин-приложения не загружаются по одному и тому же принципу, согласно PE формату? Единственная проблема что я вижу с LoadLibrary()/GetProcAddress(), это что сигнатура С# функции котороую надо вызвать из C++, должна иметь исключительно POD-types в качестве формальных параметров и возвращаемого значения, и не иметь чисто C#-ские классы, потому как неизвестно какой C++ класс ему должен соответствовать, да и в принципе может ли?
Не понимаю одного, зачем все смешивать, пусть либо будет только C# длл-ки, либо C++-шные.
Нет. Там в ПЕ хидере идет ссылка на .нет загрузчик. Который уже подгружает метадату и работает другим способом
TigrOm джан, а разве .нет или любые другие вин-приложения не загружаются по одному и тому же принципу, согласно PE формату? Единственная проблема что я вижу с LoadLibrary()/GetProcAddress(), это что сигнатура С# функции котороую надо вызвать из C++, должна иметь исключительно POD-types в качестве формальных параметров и возвращаемого значения, и не иметь чисто C#-ские классы, потому как неизвестно какой C++ класс ему должен соответствовать, да и в принципе может ли?
Не понимаю одного, зачем все смешивать, пусть либо будет только C# длл-ки, либо C++-шные.
Поясню что я имел ввиду:
При загрузке любых модулей с PE, система распознает что именно должно происходить с exe/dll модулем, а именно при загрузке управляемой сборки в неуправляемый поток приложения система иницализирует CLR, при этом создавая домен приложаения для управляемой сборки и доменно-нейтральные "сборки" для неуправляемого кода. Взаимодействие же через границы сборок может происходить только путем маршалинга. Вызывающий неуправляемый код ничего не знает о способах сериалкизации/маршалинга типов/вызовов управляемого кода. Отсюда и потребность в COM wrapper-e.
А загрузка с PE ессно происходит одинаково с точки зрения системы, о чем речь? Но вот что потом?:)
П.С. Кроме того элементарного экспортирования функций из модулей управляемого кода в формате "dllexport" я не обнаружил. Вызов функций управляемого кода происходит видимо по аналогии с COM вызовами, через "фабрику классов".
Нет. Там в ПЕ хидере идет ссылка на .нет загрузчик. Который уже подгружает метадату и работает другим способом
Ну да, но все это происходит автоматически.
Т.е. видимо вызывая LoadLibrary, все должно сработать.
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.
Ok, спасибо за пояснение.
а какая разница чем сделан длл, он и в Африке длл
1. LoadLibrary()/GetModuleHandle()
2. GetProcAddress()
Не согласен.
Dot Net-овский dll это нечто совсем иное, чем обычный.
ну я от дот-нета очень далек, поэтому это первое что пришло в голову
ну я от дот-нета очень далек, поэтому это первое что пришло в голову
вообще, технологии стараются делать такими чтоб можно было без значительных усилий пользоваться некими общими принципами/правилами. Так что вектор мыслей в принципе тебя бы привел к решению проблемы:)
Wedge> About COM , i see the only easy way is this one.
To chto sami karotki , i lyogki put' eto sozdanie COM eto odnaznachno.
Vsem spasibo.
Shyas umenya drugaya zodachka ,...
Kak polzovatsa COM kompanentom v c++ ? (skajem v vs c++ 6 ili jelatelno v Borland C++ )
Wedge> About COM , i see the only easy way is this one.
To chto sami karotki , i lyogki put' eto sozdanie COM eto odnaznachno.
Vsem spasibo.
Shyas umenya drugaya zodachka ,...
Kak polzovatsa COM kompanentom v c++ ? (skajem v vs c++ 6 ili jelatelno v Borland C++ )
Ну ты бы посмотрел таки ссылку которую я тебе кинул.
...vinovat ,...ispravlyus' ! : )
vBulletin® v3.6.8, Copyright ©2000-2008, Jelsoft Enterprises Ltd.