Пишу либу на C++/CLI. Есть класс 

где 

В MyObject есть функции которые должен унаследовать MyClass и клиент который подключает либу и пишет на C# должен использовать их. Все компилится, но вот только не получается у клиента получить доступ к функциям из MyObject. Как сделать так что-бы их было видно в Object Browser и программист на C# мог их использовать?
Заранее благодарен за ответ.

Это сообщение отредактировал(а) Therion - 29.5.2008, 15:45

Therion, а нужные методы, как я понимаю public? Потому как по описанию похоже, как если бы использовался internal. Но я в C++/CLI не разбираюсь, так что может ещё какие тонкости есть.

Методы все public. В шаблоне Object есть два метода 

Их должны использовать все классы которые наследуются от Object<>. В середине либы они видны, но клиент который подключает ее к своему проекту тх не видит.

Это сообщение отредактировал(а) Therion - 30.5.2008, 10:59

Therion, а если посмотреть либу через Reflector и дизассемблировать в C#?

Вот что, например, значит array<Byte>^%?
Сомнительно конечно, но может в С++/CLI можно написать что-то такое, чего C# потом не понимает.

Код типа array<Byte>^% я использую довольно часто и с ним проблем никаких небыло (для програмиста на C# оно выглядит как ref byte[]), если использовать его не в классе предке. Поэтому проверено что такую запись  C# понимает. А вот почему не видно наследуемых функций - пока загадка :(

Therion, любопытно.

А есть возможность выкинуть всё лишнее, оставив только эти два метода для примера и выложить тут dll-ку?
Я бы посмотрел, потому как действительно любопытно.

Это сообщение отредактировал(а) Дрон - 30.5.2008, 13:50

В архиве два проекта - один TestObject на C++/CLI (пример либы), другой на C# TestObjectSharp (приложения, которое ее использует). Надеюсь это поможет решить проблему.

Присоединённый файл ( Кол-во скачиваний: 2 )
 TestObject.zip 28,92 Kb

Хм... Если скомпилировать так, как есть, то Reflector вообще не видит методов GetUserData/SetUserData, значит их нет в .dll-ке.
Но, если в метод SomeFunction из TestObject добавить вызов GetUserData, то она появляется в dll-ке.

Мой опыт по С++ говорит о том, что там шаблоны -- это лишь объявление типа (поэтому они целиком помещаются в .h файл), а компилируются они по мере необходимости, причём отдельно для каждой спецификации типа.

Видимо C++/CLI делает точно так же и и не компилирует ненужные методы, поскольку они нигде не вызываются.
Если в SomeFunction из TestObject добавить вызов GetUserData, то компилятор добавит её в сборку.

Весьма необычно для .NET, похоже C++/CLI ближе к настоящему C++, чем я думал.
Хотя может где-то должна быть опция в настройках проекта.

Добавлено @ 14:42
О! Нашёл кое-что. Оказывается в СLI/C++ есть два вида шаблонов: template и generic.
В то время как первые больше похожи на оригинальный С++, то вторые -- на шаблоны, привычные по .NET

http://www.codeproject.com/KB/mcpp/cppcligenerics.aspx

Если у тебя заменить template<typename ObjectType> на generic<typename ObjectType> то методы нормально появляются и будут всегда видны.
Единственная проблема, что UnmanagedClass туда уже так просто не захотел подставляться, но я в этих тонкостях всё равно не разбираюсь.

Это сообщение отредактировал(а) Дрон - 30.5.2008, 14:53

Therion, если я правильно всё понял, то всё дело в том, что базовый класс - шаблонный :



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

marcusmae, угу, именно к этому я и пришёл. До этого не знал про такую особенность CLI++ (да я вообще про него ничего не знал  ).

Так как это обертка для C++ кода то generic<typename ObjectType> не получится использовать. У меня возникла идея в каждом классе который наследуется от этого шаблона просто создать две функции, который будут вызывать шаблонные! Попробую может заработает, но это не элегантное решение.

Придётся оборачивать NativeClass в managed.

Шаблоны и наследование managed-классов от шаблонных функций - это исключительно внутренняя С++/CLI-возможность. Если Вы пишите .NET-фасад для каких-то древних функций, то шаблоны лучше упрятать как-можно глубже, поскольку, например, в стандарте C# шаблонов нет, и это станет непреодолимым препятствием.

Понятно. Буду оборачивать. Спасибо за помощь.