Мы можем скомпилировать библиотеку C как .NET dll (содержащий, и вводный доступ ко всему C освобождает функции), просто компилируя cpp проект, содержащий код как
extern "C" {
#include <library.h>
}
с /clr:pure
спор с VS? (VS10)
Или мы должны сделать что-то больше trickey?
Я обнаружил, что для этого лучше всего использовать старый стиль Managed C ++.
CLR: PURE
просто не подойдет.
Пример:
extern "C" int _foo(int bar)
{
return bar;
}
namespace Bar
{
public __gc class Foo
{
public:
Foo() {}
static int foo(int bar)
{
return _foo(bar);
}
};
};
Компилировать с помощью: / clr: oldSyntax
Теперь вы можете ссылаться на сборку и вызывать Bar.Foo.foo ()
из .NET.
Это действительно зависит от вашего кода на Си.
P/Invoke часто является самым простым для начала, и IMO вполне работоспособным для небольшого количества функций. Производительность не всегда высока, и я бы не стал строить из него целую программу - но для повторного использования некоторых функций он вполне пригоден.
Переход от C к /clr:pure требует от вас:
Текущее состояние вашего кода (и его библиотек) будет диктовать, насколько болезненным будет этот процесс.
Обычно не факт, что вы сможете скомпилировать код на Си в C++ без внесения некоторых изменений. Если вы можете заставить ваш код на C компилироваться как C++, то вы можете попытаться заставить его компилироваться как C++/CLI (именно это делает опция clr:pure).
В этот момент вы можете создать некий класс, который раскрывает все экспортируемые функции как статические методы публичного (управляемого) класса.
Некоторые виды такого рода вещей можно сделать с помощью трюков препроцессора C++ (макросы и т.д.), иногда приходится писать обертки вручную.
Таким образом, основная информация о том, что вы можете компилировать C++ в сборки .NET с помощью опций /clr:xxx, верна, но это не значит, что это единственное, что вам нужно сделать, чтобы получить полезную сборку .NET.