Gibt es eine Möglichkeit, Code zwischen UWP-Apps und WPF-Apps zu teilen?

8

Um klar zu sein, folge ich dem MVVM-Muster, und ich möchte mein Projekt so strukturieren, dass ich meinen Modellcode zwischen einer UWP-App und einer Standard-WPF-App teilen kann. Der Code, den ich teilen möchte, hat keine Benutzeroberfläche. Ich mag es nicht, neue Tools zu finden, die diejenigen ersetzen, die ich seit Jahren verwende und die sich um bestimmte Aufgaben wie Protokollierung, Verbindung zu einer dokumentenorientierten Datenbank usw. kümmern.

Ich habe versucht, einen UWP-Wrapper um einen Code zu schreiben, den ich bereits habe, und referenziere das Modellprojekt direkt. Visual Studio hat dies nicht zugelassen und zeigte mir eine Fehlermeldung mit dem Hinweis "Es konnte keine Referenz zum Projekt 'ACK.Model' hinzugefügt werden." Dasselbe passierte, als ich versuchte, das Modell in eine universelle Bibliothek zu stellen und es aus einer WPF-App zu referenzieren. Ich versuche nicht, WPF-Code zu teilen. Nur die Modellschicht, die keinen Bezug zu UI-Bibliotheken hat.

Das ist ein beängstigendes Angebot, weil es bedeutet, dass ich, wenn ich etwas Substantielles machen will, entweder 100% zu UWP springen oder 100% WPF bleiben soll. NewtonSoft.JSON könnte eine universelle Distribution (ASP.NET MVC) haben, aber was ist mit ElasticSearch.NET und anderen Tools, die benötigt werden, um wichtige Apps zu erstellen?

Ich habe festgestellt, wo sich der Projekttyp "Portable Class Library" versteckt hat. Mit PCLs kann ich meinen Code über WPF- und Universal-Apps teilen, da dies eine der Optionen war. Dies löst den einfachen Fall des Model-Teils meines Codes, aber ich kann (noch) nicht einige der Bibliotheken verwenden, die ich möchte. Es gibt immer noch eine große Anzahl von Bibliotheken, die ich benötige, für die kein PCL verfügbar ist.

    
Berin Loritsch 21.01.2016, 00:48
quelle

1 Antwort

13

Etwa ein Jahr später, mit Visual Studio 2017, gibt es eine vollständigere Lösung. Wenn Sie Ihre Bibliotheken auf den .Net-Standard ausrichten, ist die Bibliothek sowohl mit den .Net Core -Apps als auch mit der monolithischen .Net -Anwendung kompatibel. Die Unterstützung für Standardbibliotheken und APIs von .Net ist ziemlich vollständig, ebenso wie die Unterstützung für moderne C # -Sprachenfunktionen.

Der allgemeine Rat lautet jetzt:

  • Ziel .Net-Standard für alle Bibliotheken
  • Richten Sie die geeignete Plattform für Ihre eigentliche Anwendung aus. (UWP oder WPF).

HINWEIS: Wenn Ihre Bibliothek mit C-Bibliotheken oder Anwendungen interagieren soll, müssen Sie besonders darauf achten, dass Sie die richtige Version laden.

Es scheint, dass es eine Lösung gibt, die aber von der gesamten Werkzeugkette übernommen werden muss, die Sie verwenden möchten. Als Microsoft Windows Store-Apps in Windows 8 einführte, wurde auch eine Portable Class Library (PCL) eingeführt. Der Zweck der PCL ist es, Code zwischen verschiedenen Teilen Ihrer Anwendung zu teilen.

Wenn Sie in Visual Studio 2015 eine PCL erstellen, können Sie die Arten von APIs angeben, auf die Sie zugreifen möchten:

  • Universelle Apps
  • Mono
  • .Net Core 5
  • .Net 4.6

Dies begrenzt natürlich die verfügbaren APIs, aber die meisten, die Sie verwenden möchten, sind in Ordnung, solange es nicht mit der Benutzeroberfläche zusammenhängt. Es gibt noch andere Einschränkungen:

  • Ihr Projekt kann nur in Visual Studio 2015 oder höher
  • bearbeitet werden
  • Sie haben keinen Zugriff auf spezielle Verzeichnisse über die Umgebungsvariable (d. h. Benutzerdokumentverzeichnis usw.)
  • Sie können keine Verknüpfung zu einer Bibliothek herstellen, die nur für eine Ihrer Zielplattformen entworfen wurde (z. B. libgit2sharp usw.)
  • Es gibt keine Möglichkeit, die API für diese Teilmenge zu durchsuchen - MSDN muss auf den Stick gelangen. MSDN hat einen Großteil der API-Dokumentation aktualisiert, aber es ist immer noch schwierig herauszufinden, was auf Sie zutrifft PCL

Sie können jedoch jede Bibliothek, die für eine einzelne Zielplattform entwickelt wurde, mit Ihrem PCL verknüpfen. Es ist nicht ideal, aber es ist besser als nichts.

Der ASP.NET MVC-Stack wurde für die Verwendung von PCLs portiert, sodass Sie NewtonSoft.JSON sowohl direkt als auch mit anderen Bibliotheken, die von dieser Anwendung verwendet werden, verwenden können. Es gibt jedoch mehrere Bibliotheken, die nicht portiert wurden.

Diese Anordnung zwingt Sie, darüber nachzudenken, wie Sie sich besser integrieren wollen. Der .Net Core 5 scheint stabil zu sein, aber Support ist in den Kinderschuhen. Die aktuelle Generation der Universal Apps ab VS 2015 Update 1 verwendet .Net Core 5 direkt.

Es gibt einige Funktionen von Nuget, die derzeit nicht unterstützt werden, obwohl gerade gearbeitet wird:

  • MS Build-Erweiterungen (wesentliche Änderungen an MSBuild und der project.json-Struktur)
  • Installiere / deinstalliere Skripte (im Zusammenhang mit der Entfernung des Installationskonzepts)
  • Inhalt (im Zusammenhang mit der Installation / Deinstallation, es wird jedoch daran gearbeitet)
  • Content-Transformationen (bezogen auf fehlende Installation / Deinstallation)

Ich wünschte, ich hätte eine vollständigere Antwort. Aber das ist soweit, als ich die PCL entdeckt habe und wie sie sich für die aktuelle Infrastruktur entwickelt hat.

Ich bin gerade dabei, ein Toolkit für die Erstellung von Spielen zu erstellen, das die Versionskontrolle auf Anhieb einbezieht. Ich möchte ein Spiel als Windows 10-App oder als Standard-WPF-App bereitstellen können, aber aufgrund der Bibliotheken, die ich zur Integration der Versionskontrolle verwende, muss ich den Editor als Standard-WPF-App erstellen. Ich musste beim Erstellen des gemeinsamen Codes und beim Importieren der richtigen Bibliotheken etwas kreativ sein.

Zuerst meine Projekthierarchie:

  • Project.Model (Portable Klassenbibliothek)
  • Project.Model.Versioning (Standard-C # -Bibliothek)
  • Mvvm.Toolkit (Portable Klassenbibliothek)
  • Editor (Standard-WPF-Anwendung)

Ich möchte, dass die Kern-PCL ein Projekt laden und die JSON-codierten Objekte deserialisieren kann. Die PCL hatte Zugriff auf System.IO , aber es ist überraschenderweise nicht dasselbe wie das in der Standard-C # -Bibliothek definierte. Hier ist, wie ich Dinge reparieren musste:

  • Nachdem ich den Paketverweis zu NewtonSoft.JSON hinzugefügt hatte, musste ich das Zielframework in der Datei packages.config ändern:

    <package id="Newtonsoft.Json" version="8.0.2" targetFramework="portable-net452+win81" />

  • Alle Projekte, die von meiner Project.Model-Klasse abhängig waren, mussten das 'system.io.filesystem' -Paket von nuget installieren, damit die Objekte von System.IO.FileInfo usw. identisch waren.

Das ist zwar kein Allheilmittel, aber auch keine Sackgasse. Ich bin mir sicher, dass es noch mehr Probleme gibt, aber das wird zumindest bei einigen Problemen helfen.

    
Berin Loritsch 21.01.2016, 13:55
quelle

Tags und Links