Использование смешанных DLL-файлов из/clr: pure projects

Question

Я строю проект вместе с Dll.

Dll должен поддерживать собственный код, поэтому я объявил его как/clr. Мой проект был начальным и проектом/clr, и все было в порядке. Однако я хотел бы включить некоторое тестирование NUnit, поэтому мне пришлось переключить основной проект из/clr в/clr: pure.

Все еще компилируется, но любой вызов Dll создает ошибку времени выполнения. Когда я вернуться к/обнуления все нормально

В моей Dll, экспортируемые функции объявлены следующим образом:

#define DllExport __declspec(dllexport) 
DllExport bool DisplayScan(bool bShow, bool bAllPasses) { } 

Я также сделал DEF-файл, содержащий реальные имена всех экспортируемых функций

LIBRARY "Controller" 
EXPORTS 
DisplayScan 

Из моего основного проекта моего импорт объявлен следующим образом:

#define _DllImport [DllImport("Controller.dll", CallingConvention = CallingConvention::Cdecl)] static 
_DllImport bool DisplayScan(bool bShow, bool bAllPasses) 

Кто-нибудь сталкивался с такой проблемой?

Answer 1

Хорошо, что все работает в настоящее время

На самом деле, она работает с самого начала.

Мораль: не пытайтесь бросить символ * в станд :: строка

Странная вещь: его нормально в/обнуления, пока вы не вернетесь из функции. Он сбой сразу в/clr: чистый

Answer 2

В основном вы делаете то, что не поддерживается;/clr: чистый и родной экспорт DLL. Как указано из this MSDN article «чистые сборки не могут экспортировать функции, вызываемые из собственных функций, поскольку точки входа в чистой сборке используют соглашение о вызове __clrcall».

Я не уверен в лучшем обходном пути. Однако, немного экспериментируя, вы, вероятно, можете использовать соглашение о вызове __clrcall с параметром/clr. Here's a link, которые могут быть полезны. Из того, что я могу собрать, вы должны иметь возможность экспортировать эти управляемые классы и потреблять их из управляемой сборки, такой как ваш управляемый проект NUnit, но сохраните свой неуправляемый экспорт там с помощью разных сигнатур методов. Имейте в виду, что как только вы выставляете какой-либо класс .net через экспорт, ему необходимо будет использовать соглашение о вызове __clrcall.

Answer 3

ваша проблема вызова conventionCallingConvention = CallingConvention :: Cdecl ... определить свою функцию, как это или использовать STDCALL или clrcall, clecl для чистого C

или проблема здесь: определить, что функция EXTERN не статическую

Answer 4

Преимущества/обнуления: чистые

Лучше Производительность: Поскольку чистые сборки содержат только MSIL, нет нативных функций, и, следовательно, не управляемые/неуправляемых переходы необходимы. (Вызовы функций, выполненные с помощью P/Invoke, являются исключением из этого правила.)

AppDomain Awareness: Управляемые функции и типы данных CLR существуют внутри областей приложений, что влияет на их видимость и доступность.Чистые сборки поддерживаются в домене (для каждого типа подразумевается __declspec (appdomain)), поэтому доступ к их типам и функциям из других компонентов .NET проще и безопаснее. В результате чистые сборки более легко взаимодействуют с другими компонентами .NET, чем смешанные сборки.

Недисковая загрузка: чистые сборки могут быть загружены в память и даже потоковые. Это важно для использования сборников .NET в качестве хранимых процедур. Это отличается от смешанных сборок, которые из-за зависимости от механизмов загрузки Windows должны существовать на диске для выполнения.

Отражение: невозможно воспроизвести смешанные исполняемые файлы, тогда как чистые сборки обеспечивают полную поддержку отражения. Дополнительные сведения см. В разделе Отражение (C++/CLI).

Контролируемость хоста: поскольку чистые сборки содержат только MSIL, они ведут себя более предсказуемо и гибко, чем смешанные сборки, когда они используются в приложениях, которые размещают CLR и изменяют свое поведение по умолчанию.

Ограничение/CLR: чисто

Этот раздел охватывает функции в настоящее время не поддерживается/CLR: чисто.

Чистые сборки не могут быть вызваны неуправляемыми функциями. Поэтому чистые сборки не могут реализовывать COM-интерфейсы или вызывать собственные обратные вызовы. Чистые сборки не могут экспортировать функции через файлы __declspec (dllexport) или .DEF. Кроме того, функции, объявленные с помощью соглашения __clrcall, не могут быть импортированы через __declspec (dllimport). Функции в собственном модуле можно вызывать из чистой сборки, но чистые сборки не могут выставлять функции, вызываемые вызываемым пользователем, поэтому раскрытие функциональности в чистой сборке должно выполняться с помощью управляемых функций в смешанной сборке. См. Практическое руководство. Для получения дополнительной информации перейдите в/clr: pure (C++/CLI).

Библиотеки ATL и MFC не поддерживаются компиляцией чистого режима в Visual C++.

Чистые .netмодули не принимаются в качестве входных данных для компоновщика Visual C++. Однако чистые .obj-файлы принимаются компоновщиком, а файлы .obj содержат надмножество информации, содержащейся в netmodules. Для получения дополнительной информации см. Файлы .netmodule в качестве вложения компоновщика.

Поддержка COM-компилятора (#import) не поддерживается, так как это приведет к неуправляемым инструкциям в чистую сборку.

Варианты с плавающей точкой для выравнивания и обработки исключений не настраиваются для чистых сборок. В результате нельзя использовать __declspec (align). Это отображает некоторые файлы заголовков, такие как fpieee.h, несовместимые с/clr: pure.

Функция GetLastError в PSDK может давать неопределенное поведение при компиляции с/clr: pure.