IKVM を使用して、作業中の Mono プロジェクトで SVNKit を取得しています。SVNKit からのインターフェイスを実装するクラスがあり、コンパイルできません。
Windows と .NET では、Mono でこれを取得するだけで、すべてが正常にコンパイルされます。
/home/nubela/Workspace/subsync/subsync/Core/Subversion/PropGetHandler.cs(22,22): エラー CS0535:
Subsync.Core.Subversion.PropGetHandler' does not implement interface memberorg.tmatesoft.svn.core.wc.ISVNPropertyHandler.__<clinit>()` (CS0535) (サブシンク)
メソッドをググっ__<clinit>()たところ、IKVM からコンパイルされた Java ライブラリの基本クラスの初期化メソッドのようです。
どうすればいいのかわかりません。アイデアはありますか？:)
私は多くの反対票でリスクを負い、別の解決策を提案します。つまり、私の意見では、はるかに優れています... .NET アプリケーションで Java ライブラリを使用している理由がわかりません。 .NET には多くの代替手段があり、優れた代替手段です。
Svn.NETのように、.NET にネイティブな svn ライブラリを使用しないのはなぜですか? それははるかに速いでしょう。SVNKit を使用する既存のコードがある場合は、それを Svn.NET に変換するか、そのためのラッパーをいくつか作成することができます。
魚は水の外では生きられませんよね？自然環境である水の中でしか生きられません。したがって、SVNKit は、.NET ではなく Java のいずれかの自然環境に存在する必要があります。.NET の SVNKit は火星の人間のようなもので、それで問題ありませんが、私は地球の人間の方が好きです。
Svn.NET は、次のプラットフォームをサポートしています。
.NET/Mono 3.5 は 2.0 の単なる拡張であるため、3.5 でも動作することに注意してください。
なぜ巻き込まれるのですか？はるかに簡単になります。
クラスはMicrosoftのコンパイラでビルドできるため、これはMonoコンパイラまたはランタイムのバグである必要があります。
どのプラットフォームでも、Monoを使用してMicrosoftのコンパイラで構築されたアセンブリを使用できます。
2つの回避策を提案できます。
a） Windowsでヘルパーアセンブリsvnkitutil.dllをビルドします。ISVNPropertyHandlerこれには、およびその他の問題のあるインターフェイスのデフォルトの実装が含まれます。次に、デフォルトの実装をサブクラス化してインターフェイスを実装します。
これでも同じ問題で失敗する可能性があります。
b） Javaソースを変更して、インターフェース（ISVNPropertyHandler.NULL）の静的フィールドを削除します。
これがSVNKit全体で一般的なパターンである場合、これは多くの作業になる可能性があります。
ここで明白な質問をするつもりですが、コードは moma http://www.mono-project.com/MoMAで実行しましたか? また、微妙な非互換性 (コア メソッドが実装されていないなど) によって引き起こされた、非常に奇妙なコンパイラ エラーもいくつか発生しました。
Java ライブラリのコードにアクセスできる場合は、メソッド __() を正しく実装できます。
メソッド void __() {} - 正常にコンパイルされます。それでも問題が解決しない場合は、エラーを再現するコード サンプルを提供していただけますか?