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

AS>>С++ dll --> C++/CLI dll --> C# dll

MD>Плюсую за этот вариант, несколько раз пользовался. Преимущества перед классическим pinvoke:

Я, при здравом размышлении, решил пока ограничиться набором статических сишных оберток. Этот заказчик, что хочет вызывать мои API из C#, сам по себе какой-то мутный, и не факт, что в обозримое время появится еще кто-то на C#. С C++/CLI я до сих пор дела не имел — пришлось бы в нем разбираться, а если что-то не так заработает в связке, то разбираться придется еще и в том, насколько правильно я экспортирую классы/методы. Заказчик мне в этом вряд ли поможет — насколько я понимаю, они используют C# на уровне "написали, как в документации — заработало, как ожидали". А при экспорте простых оберток я, по крайней мере, могу оценить правильность экспорта и по .map, и по PE, и быстро протестировать DLL своими силами.

Здравствуйте, Евгений Музыченко, Вы писали:

Тут необходимо ответить на ряд вопросов прежде чем выбирать решение.

Насколько нужна будет в будущем кроссплатформенность.
COM у нас только в Windows.
Если это не проблема, то самый удобный вариант.
Описываются интерфейсы в IDL далее создаём TLB из которой создаётся DLL .NET assembly и получаем подсказки и автодополнения.
Единственный недостаток это то, что если опыта в этом нет, придётся немного повозиться.
Зато любые будущие изменения делаются легко и непринуждённо.
Ну и как указали выше это даёт возможность вызывать код из других языков как VBScript если маршалить через oleautomation.

Насколько нужен ли .NET Core и какой версии.
До недавнего времени там не было поддержки C++/CLI.

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

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

bnk>

bnk>// C#
bnk>[DllImport("my.dll")]
bnk>public static extern void Foo();

bnk>void Main() {
bnk>  Foo();
bnk>}
bnk>

В C# все действительно настолько просто в плане интерфейса со статическими функциями в стиле C? Тогда очень странно, что мои заказчики за прошедшие полтора месяца так и не осилили вызов части функций-переходников, которые я им сделал, и просят сделать поверх них еще и агрегаторы с параметрами по умолчанию.

bnk>Функции WinAPI из C# вызываются без проблем.

То есть, при появлении в WinAPI новых функций, достаточно описать их прототипы в C#, и сразу вызывать? Ждать, пока обновятся интерфейсные библиотеки для .NET или C#, не нужно?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, bnk, Вы писали:

bnk>>

bnk>>// C#
bnk>>[DllImport("my.dll")]
bnk>>public static extern void Foo();

bnk>>void Main() {
bnk>>  Foo();
bnk>>}
bnk>>

ЕМ>В C# все действительно настолько просто в плане интерфейса со статическими функциями в стиле C? Тогда очень странно, что мои заказчики за прошедшие полтора месяца так и не осилили вызов части функций-переходников, которые я им сделал, и просят сделать поверх них еще и агрегаторы с параметрами по умолчанию.

Ну да, все именно настолько просто
Тут скорее вопрос к чему привык. Такой "интерфейс" кажется простым если было суровое детство и деревянные игрушки

bnk>>Функции WinAPI из C# вызываются без проблем.

ЕМ>То есть, при появлении в WinAPI новых функций, достаточно описать их прототипы в C#, и сразу вызывать? Ждать, пока обновятся интерфейсные библиотеки для .NET или C#, не нужно?

Ну да, так и есть.

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

bnk>Тут скорее вопрос к чему привык. Такой "интерфейс" кажется простым если было суровое детство и деревянные игрушки

Прост он прежде всего в смысле адекватности используемому API, а не концепции C#.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Я, при здравом размышлении, решил пока ограничиться набором статических сишных оберток. Этот заказчик, что хочет вызывать мои API из C#, сам по себе какой-то мутный, и не факт, что в обозримое время появится еще кто-то на C#. С C++/CLI я до сих пор дела не имел — пришлось бы в нем разбираться, а если что-то не так заработает в связке, то разбираться придется еще и в том, насколько правильно я экспортирую классы/методы. Заказчик мне в этом вряд ли поможет — насколько я понимаю, они используют C# на уровне "написали, как в документации — заработало, как ожидали". А при экспорте простых оберток я, по крайней мере, могу оценить правильность экспорта и по .map, и по PE, и быстро протестировать DLL своими силами.

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

Здравствуйте, Евгений Музыченко, Вы писали:

.Net Core Вызов виртуальных методов нативных объектов

http://rsdn.org/forum/dotnet/6614203.1

Автор: pilgrim_
Дата: 18.11.16

http://rsdn.org/forum/dotnet/6614469.1

Автор: pilgrim_
Дата: 18.11.16

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня в одном из проектов на MS VC++ есть интерфейсная DLL с парой классов и несколькими глобальными функциями. Всего функций около пары десятков. Все крайне примитивно, используется только WinAPI и простейшие функции CRT, исключения не бросаются и не обрабатываются.

ЕМ>Заказчик хочет вызывать функции этой DLL из C#, но совершенно не разбирается в том, как дружить C# с C++, а я, соответственно, ничего не знаю про внутреннюю организацию C#, и некогда в нее глубоко лезть. Пока сошлись на том, что я добавлю в DLL обертки в стиле WinAPI, а они у себя сделают обертки для них.

ЕМ>Будет ли оптимальным способом разворачивать классы в наборы глобальных функций типа Class1_Func1, Class1_Func2 и т.д., добавляя первым параметром указатель на объект, или есть более изящный способ оформить в C# классы такой же структуры, и вызывать функции по-человечески? Например, добавить к классам абстрактные интерфейсы, сделав все функции виртуальными, оформить эти классы в стиле COM, или еще как.

Лучший вариант для малого количества Pinvoke

c++ часть
extern "C" __declspec(dllexport) bool Function(SomeClass * ptr,const wchar* descr,uint16_t & param)
{

}

c#

public static class Communication
{
#if _DEBUG
private const string targetlib= "debugdll";
#else
private const string targetlib= "releasedll";
#endif
[DllImport(targetlib, EntryPoint = "Function", CharSet = CharSet.Unicode, CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs(UnmanagedType.U1)]
public static extern bool UnmanagedFunction(IntPtr ptr, string descr, ref ushort param);

}

Плюсы- можно сделать загрузку библиотек разной разрядности если надо x86, переносимо между платформами.
Минусы- описание функциий в двух местах, бустолковая работа с указателями даже на примитивные типы

Другие варианты:
COM-лучше развидеть и забыть, windows-only и коряв. Если близко не знаком, то и не стоит связываться.
C++/CLR- вырвиглазный синтаксис от которого у здорового человека умеющего в С++ и C# начинаеться нервный тик, странные глюки при инициализации с шаманством, .NET 5 вроде поддерживаеться, но не факт что нормально работает. Пригодиться скорее наоборот, для вызова .NET из нативной программы.

Здравствуйте, Евгений Музыченко, Вы писали:

Кстати .Net 5 и C#9
https://dev.to/jeikabu/native-code-in-net-5-0-and-c-9-0-39h7

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Заказчик хочет вызывать функции этой DLL из C#, но совершенно не разбирается в том, как дружить C# с C++, а я, соответственно, ничего не знаю про внутреннюю организацию C#, и некогда в нее глубоко лезть. Пока сошлись на том, что я добавлю в DLL обертки в стиле WinAPI, а они у себя сделают обертки для них.
В С# для этого есть встроенная возможность с unmanаged code и стадо примеров в MSDN и инете.
Когда лет 15 назад мне понадобилась и за день разобрался и сделал(C# не знал, не знаю и знать не хочу).