2016-04-01 7 views
0

Wir verwenden einige alte Open-Source-.NET Framework-Bibliotheken, die von Dingen abhängen, die nicht in .Net Core enthalten sind. Kann Mono verwendet werden, um den Rest von .Net Framework auszufüllen?Verwenden von Mono zum Vervollständigen der universellen Windows-Plattform (.net-Kern)

Ich denke speziell an das Erstellen einer universellen Windows-Klassenbibliothek, die alles in Mono enthält (mit Ausnahme einiger System-Namespaces), die die Namespaces von System. * Zu MonoSupport.System. * Ändert.

Natürlich wäre es besser, den Code der Bibliothek neu zu schreiben, eine andere Bibliothek zu verwenden oder selektiver zu sein, wenn man Dinge von Mono übernimmt. Ich hatte gehofft, dies als eine vorübergehende Maßnahme zu tun.

(Ich will iTextSharpLGPL verwenden, aber es nutzt XmlTextReader, Bäche mit .Close(), System.Security.Cryptography, etc .. Die Pay-Version der Bibliothek does not support UWP either.)

bearbeiten: Ich habe auf diese und schrieb meine App um Apitron zu verwenden. Das hat gut funktioniert, bis ich versucht habe zu implementieren und herausgefunden habe, dass sie .NET Native nicht unterstützen. Ich warte jetzt auf eine Bibliothek, um die PDF-Erzeugung auf UWP zu unterstützen.

+0

Ich weiß, aber wir arbeiten daran. –

+2

Der kommende iText 7 für .NET wird voraussichtlich mit UWP kompatibel sein. –

Antwort

1

Ich glaube nicht. Die folgenden unmittelbaren Gründe

  • Mono ist ein Klon des .NET-Frameworks und basiert daher auf Mscorlib-Ideen, während UWP auf System.Runtime basiert. Würde einen erheblichen zusätzlichen Aufwand erfordern.
  • UWP-Apps basieren - wenn sie veröffentlicht werden - auf der nativen .NET-Laufzeitumgebung. Diese Laufzeitumgebung erzwingt einige Muster in den Bibliotheksimplementierungen (z. B. keine Reflektion, keine C++ - Implementierung von Typen usw.). Mono ist auch stark in AOT, aber ich denke, es gibt Drachen.
  • Mono ist eine schlechte Wahl. Besser ist die Microsoft-Referenzquelle für .NET Framework, die auf GitHub veröffentlicht wurde.
  • Die Zeit, die Sie in Ihren Plan investieren wird so hoch sein, es ist viel besser investiert, es in Corefx direkt zu beheben und warten auf die nächste Version von UWP enthalten Ihre Fixes.

    Für Ihr Problem würde ich Ihnen dringend empfehlen, das Problem als Vorlage upstream bei iTextSharpLGPL durch Auftauchen neuer Methoden und Entfernen von schließen oder vielleicht nur durch Kopieren der MIT lizensierten XmlTtextReader zu beheben. Aber ich empfehle Ihnen dringend, nicht mit Krypto herumzualbern;)