プリコンパイルされた.NETアセンブリDLLをMonoで使用していますか？

現在、Monoをテストして、.NET DLLがLinux上のお客様に適しているかどうかを確認しています。私たちのDLLは、Windowsフォームのコンポーネントを提供します。 DebugディレクトリにDLLを配置し、参照を追加し、Windowsフォームから派生したクラスを作成しました。クラスは細かいスタンドアロンで実行していたが、私は、DLLの参照を追加した後、私たちのコンポーネントの1を作成した（インテリセンスがうまく働いていた）、それはコンパイルが、実行されません。プリコンパイルされた.NETアセンブリDLLをMonoで使用していますか？

 
** (/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：ニューヨーク近代美術館によると

は、状況には何の関係を持っていないいくつかの[MonoTodo] S以外のファイル、DLLの3人に1つの問題がある。しかし

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

、私は開かれましたVS2008で作成されたサンプルプロジェクトの1つは、DLLへの参照を適切な場所で指し示し、うまくいきました。しかし、私は新しいプロジェクトで作業するための参照を取得することができませんでした。私は何か間違っているのですか？

EDIT 2：わかりやすくするため、既存のWindowsアプリケーションを再作成することは望ましくありません.DLLを使用して新しいアプリケーションを作成する顧客をシミュレートしています。私はそれがdllの問題であるかどうかを確認するためにテストしていました。 VS製アプリケーションがdllを見つけて正常に実行できたので、dllの問題ではないようです。新しいアプリケーションは、VSで作成されたアプリケーションでは呼び出さないものを呼び出すことはありません。

出典

2009-07-21 NickAldwin

は、私はそれがサポートされていないAPIを使用していますかどうかを確認するためにMOMA (Mono Migration Analyzer)でDLLをテストしたいです。

出典

2009-07-21 18:03:01

上記のMoMAの詳細を追加しました。しかし、サンプルアプリケーションでうまく動作します。 MonoDevelopで作られた新しく作成されたアプリではない。 – NickAldwin

MonoDevelopでアプリケーションを再作成する必要はありません。 MonoはVisual StudioでコンパイルされたDLLを実行できるはずです。それは、pは/コールを呼び出す作って、それはモノではサポートされないことを意味します - 私はそのComboBoxControl.SetWindowsThemeの呼び出しで見てね。あなたはそれを削除することができますか、またはそのコントロールを使用できませんか？ –

私たちはそれを再作成したくありません - 私たちはDLLを使って新しいアプリケーションを作成する顧客をシミュレートしています。私はそれがdllの問題であるかどうかを確認するためにテストしていました。 VS製アプリケーションがdllを見つけて正常に実行できたので、dllの問題ではないようです。新しいアプリケーションは、VSで作成されたアプリケーションでは呼び出さないものを呼び出すことはありません。 – NickAldwin

あなたは、一般的に実行することで、.dllファイル読み込みエラーの詳細を取得することができます：

MONO_LOG_LEVEL =「デバッグ」MONO_LOG_MASK =「DLL」モノのmyapp.exe

出典

2009-07-21 20:11:15 jpobst

答えに感謝しますが、それらの環境変数を設定した後、モノはまだ私にそれ以上の情報を与えませんでした。 – NickAldwin

ジョナサンが正しいとは何、あなたがする必要があります図のようにコマンドを実行すると、大量の情報が生成されます。

アセンブリには厳密な名前が付けられているため、GACにインストールされている依存関係はWindowsのようです。 "OUR.ASSEMBLY" があることになっている場合は、次のコマンドを実行します

ます。gacutil -i OUR.ASSEMBLY.dll

それをインストールするには。 OUR.ASSEMBLY.dllにはJPobstのコマンドが表示する必要がある他の依存関係が存在するかもしれません。

出典

2009-07-22 05:41:27

ただし、GACは使用しません。 – NickAldwin

確かに、あなたはそのアセンブリに強く名前を付けました.GoAはそれをGACで調べます。あなたは（それは関係なく、その厳密な名前の、DIRに組立用ルックアップするためにモノを命令する）診断目的のために、「輸出MONO_PATH = DIR」でこれをオーバーライドすることができます。 –

可能性の高い問題は、アセンブリは、プログラムとして、あるいは、それがコピーされたとき、アセンブリファイル名の大文字と小文字の区別が保存されていないことと同じディレクトリに置かれていないということです。たとえば、OUR.ASSEMLY参照があるかもしれませんが、ファイル名はOurAssembly.DlLまたは他の無効な大文字と小文字の組み合わせです。

出典

2009-07-22 07:25:16 lupus

私はそれが同じdirと同じケースに入っていることを確認しましたが、それでもエラーが発生しました。 – NickAldwin

出力ログを出力しないようにするには、straceの下でmonoを実行してください。 strace -f -e mono yourtest.exe を開き、それがどのファイルを参照しているかを確認してください負荷と場所。 – lupus

uxtheme.dllは、私が間違っていないとWindowsのテーマエンジンです。 Windows以外の環境ではそれがないのは自然なことですので、P /エクスポートされた関数を呼び出すことは直接できません。

あなたはここに2つのオプションがあります。

はOnHandleCreated方法とはモノがPは/それを呼び出すことができますので、この1つのだけの機能が含まれているダミーlibuxtheme.soを作成ポータブル何かまたは
とSetWindowThemeコールを交換することを開き。

私がサポートしているプラットフォームごとにダミーlibuxtheme.soを作成する必要があるので、可能であれば最初のアプローチをお勧めします。つまり、あなたは、x86 Linux用libuxtheme.so、x86_64のLinux用libuxtheme.so、FreeBSD用と同じ、libuxtheme.dylib Mac OS X用というように作る必要があるだろう。

UIデザイナーなどがOnHandleCreatedを生成した場合は、通話を取り除くためにいくつかのウィジェットテーマを削除する必要があります。

出典

2012-12-22 20:28:13 onitake

プリコンパイルされた.NETアセンブリDLLをMonoで使用していますか？

答えて

関連する問題