Использование сборной библиотеки .NET для сборки в Mono?

В настоящее время мы тестируем Mono, чтобы узнать, будут ли наши .NET DLL работать для клиентов в Linux. Наши библиотеки DLL предоставляют компоненты для Windows Forms. Я поместил DLL в каталог Debug, добавил ссылки и создал класс, полученный из Windows Form. Класс работал нормально, но после того, как я добавил ссылки на DLL и создал один из наших компонентов (intellisense работал нормально), он компилируется, но не запускается:

** (/home/aldwin/testMonoWF/testMonoWF/bin/Debug/testMonoWF.exe:26905): WARNING **: Could not load file or assembly 'OUR.ASSEMBLY, Version=1.0.0.1, Culture=neutral, PublicKeyToken=ATOKEN' or one of its dependencies.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'OUR.ASSEMBLY, Version=1.0.0.1, Culture=neutral, PublicKeyToken=ATOKEN' or one of its dependencies.
File name: 'OUR.ASSEMBLY, Version=1.0.0.1, Culture=neutral, PublicKeyToken=ATOKEN'

Я просмотрел свойства сборки, и именно эта версия с этим открытым ключом.

Есть ли способ использовать эти DLL? Что я делаю неправильно?

EDIT:

Согласно MoMA, кроме некоторых [MonoTodo], которые не имеют отношения к ситуации, в трех из DLL есть одна проблема:

Calling Method | P/Invoke Method | P/Invoke Library
void OnHandleCreated (EventArgs) | int GoText/ComboBoxControl.SetWindowTheme (IntPtr, string, string) | uxtheme.dll

Однако я открыл один из наших образцов проектов, созданных с помощью VS2008, указал ссылку на DLL в нужном месте, и он отлично работал. Но я не мог получить ссылку на работу в новом проекте. Я что-то делаю неправильно?

ИЗМЕНИТЬ 2: Чтобы уточнить, мы не хотим воссоздать существующее приложение Windows - мы имитируем клиента, создающего новое приложение с нашей dll. Я просто тестировал это, чтобы увидеть, была ли проблема с dll. Поскольку VS-приложение было в состоянии найти dll и успешно работать, похоже, это не проблема с dll. Новое приложение не вызывает ничего, что создано VS-созданным приложением.

Ответ 1

Я бы протестировал DLL с помощью MOMA (Mono Migration Analyzer), чтобы узнать, использует ли он неподдерживаемые API.

Ответ 2

Что Джонатан сказал правильно, вам нужно запустить команду, как показано, и она выдаст много информации.

У сборника есть сильное имя, поэтому это звучит так, как в Windows у вас есть зависимость, установленная на GAC. Если предполагается, что существует "OUR.ASSEMBLY", запустите:

gacutil -i OUR.ASSEMBLY.dll

Чтобы установить его. Могут существовать другие зависимости, которые требуется OUR.ASSEMBLY.dll, что будет показано командой JPobst.

Ответ 3

Обычно вы можете получить более подробную информацию о ошибках загрузки DLL, выполнив следующие действия:

MONO_LOG_LEVEL = "debug" MONO_LOG_MASK = "dll" mono myapp.exe

Ответ 4

Вероятными проблемами являются то, что сборка не помещается в тот же каталог, что и программа, или что чувствительность к регистру имени файла сборки не сохраняется при копировании. Например, у вас может быть ссылка OUR.ASSEMLY, но имя файла - OurAssembly.DlL или любая другая недопустимая комбинация случаев, которую могут придумать люди.

Ответ 5

uxtheme.dll - это движок темы Windows, если я не ошибаюсь. Вполне естественно, что у вас нет этого в среде, отличной от Windows, поэтому P/Invoking ее экспортированные функции не являются напрямую возможными.

У вас есть два варианта:

Откройте этот метод OnHandleCreated и замените вызов SetWindowTheme на что-нибудь портативное или
Создайте фиктивный libuxtheme.so, который содержит только одну функцию, поэтому mono может P/Invoke it.

Я рекомендую первый подход, если это возможно, так как вам нужно создать этот манекен libuxtheme.so для каждой поддерживаемой платформы. I.e., вам нужно сделать libuxtheme.so для x86 Linux, libuxtheme.so для x86_64 Linux, то же самое для FreeBSD, libuxtheme.dylib для Mac OS X и т.д.

Если OnHandleCreated был сгенерирован некоторым дизайнером пользовательского интерфейса или ему подобным, вам, вероятно, придется удалить некоторые темы виджета, чтобы избавиться от вызова.