2016-04-01 17 views
0

.Net Core以外のものに依存する古いオープンソース.NET Frameworkライブラリを使用しています。 Monoを使って残りの.Net Frameworkを埋め込むことはできますか?Monoを使用してUniversal Windows Platform(.netコア)を完成させる

具体的には、System。*からMonoSupport.System。*に名前空間を変更するMono(System名前空間の一部を除く)のすべてを含むUniversal Windowsクラスライブラリを作成することを考えています。

もちろん、ライブラリのコードを書き直したり、別のライブラリを使用したり、Monoから物事を取り出す際に、より選択的な方法をとってください。私は一時的な対策としてこれをやりたいと考えていました。

(私はiTextSharpLGPLを使用したいが、それはXmlTextReaderクラスを使用して、(.Closeでストリーム)、System.Security.Cryptography、その他ライブラリdoes not support UWP eitherの有料版。)

編集:私が与えましたApitronを使用するように私のアプリを書き直しました。それは私が展開しようとするまで素晴らしい仕事をし、彼らは.NETネイティブをサポートしていないことがわかった。私は現在、UWPでのPDF生成をサポートするライブラリを待っています。

+0

私は知っていますが、我々はそれに取り組んでいます。 –

+2

今後のiText 7 for .NETは、UWPとの互換性が期待されています。 –

答えて

1

私はそうは思わない。次のような直接の理由

  • Monoは.NET Frameworkのクローンであり、したがってmscorlibのアイデアに基づいており、UWPはSystem.Runtimeに基づいています。かなりの余分な努力が必要です。
  • UWPアプリは、リリースされると、.NETネイティブランタイムに基づいています。このランタイムは、ライブラリの実装にいくつかのパターンを適用します(リフレクションなし、C++の型の実装なしなど)。モノはAOTでも強いですが、ドラゴンがいると思います。
  • モノは悪い選択です。 githubに公開されている.NET Framework用のマイクロソフトのリファレンスソースが優れています。あなたの計画に投資する

時間は直接corefxでそれを固定し、それははるかに良い投資され、高いので、重要であるとあなたの修正を含むようにUWPの次のリリースを待つことになります。

あなたの問題については、iTextSharpLGPLのアップストリームの提出として、新しいメソッドを浮上させて閉じるか、MITライセンスのXmlTtextReaderをコピーするだけで問題を解決することをお勧めします。しかし、私は強くお勧めします、暗号で回り込まないでください;)

関連する問題