2016-01-21 75 views
8

爲了清楚起見,我遵循MVVM模式,並且我想要構建我的項目,以便我可以在UWP應用程序和標準WPF應用程序之間共享我的模型代碼。我想分享的代碼沒有UI。我不喜歡想找到新工具來替換我多年來一直使用的工具,這些工具可以處理日誌,連接到面向文檔的數據庫等特定任務。有什麼方法可以在UWP應用程序和WPF應用程序之間共享代碼?

我試圖開始寫作圍繞我已經擁有的一些代碼的UWP包裝,並直接引用模型項目。 Visual Studio拒絕讓這種情況發生,向我顯示一條錯誤消息,指出「無法添加對項目'ACK.Model'的引用」。當我試圖將模型放入通用庫並從WPF應用程序中引用模型時,也發生了同樣的情況。我沒有試圖分享WPF代碼。只是沒有引用UI庫的模型層。

這是一個可怕的命題,因爲這意味着如果我想做任何實質性的事情,我必須選擇100%跳到UWP或保持100%的WPF。 NewtonSoft.JSON可能具有通用的分佈(ASP.NET MVC),但是ElasticSearch.NET和其他用於製作重要應用程序所需的工具又如何呢?


我發現「便攜式類庫」項目類型隱藏的地方。 PCLs允許我在WPF和Universal應用程序中共享我的代碼,因爲這是其中一個選項。這解決了我的代碼模型部分的簡單情況,但是我仍然無法使用我想要的一些庫。我仍然需要大量的庫,沒有PCL可用。

+1

歡迎來到我們的困境,我的朋友,至於現在,我認爲不。在UWP向我們開放之後,我們試圖尋找這一點。目前我們仍然依賴於WebAPI。共享代碼並將它們重用爲可重用代碼作爲一種解決方案或甚至參考現在都無濟於事。由於UWP仍然專注於Windows系列應用程序,而不是ASP的Web應用程序。如果你找到了一種方式,2個結構是輕而易舉的實現這一點,請在你的問題中重新發布。 – Aizen

+0

您必須抽象代碼,該代碼使用第三方庫並將其替換爲適用於WPF/UWP的代碼。即不是直接使用NewtonSoft.JSON,而是使用'IJsonProvider'接口。在UWP上,你使用微軟的Json棧和WPF的JsonSoft例如 – Tseng

+0

誰投票結束這個問題,你能否詳細說明爲什麼你覺得這不是主題。這不是關於計算的一般問題。這是一個關於不同C#平臺之間代碼共享的問題。 –

回答

13

大約一年後,隨着Visual Studio 2017的問世,有了一個更完整的解決方案。如果您將庫定位到.Net標準那麼該庫與兼容.Net Core應用程序和單片.Net目標應用程序兼容。對標準.Net庫和API的支持相當完整,對現代C#語言功能的支持也是如此。

現在一般的建議是:

  • 目標的.Net標準所有圖書館
  • 目標爲您的實際應用選擇合適的平臺。 (UWP或WPF)。

注意:如果您的庫必須與C庫或應用程序進行交互,則必須格外小心,以確保加載正確的版本。


似乎有一個解決方案,但它必須被您想要使用的整個工具鏈採用。當微軟在Windows 8中推出Windows Store應用程序時,他們還推出了一個便攜式類庫(PCL)。 PCL的目的是在應用程序的不同部分之間共享代碼。

當你在Visual Studio 2015年創建PCL,你可以指定你希望它是訪問從類型的API:

  • 通用應用
  • 。核心網5
  • 的.Net 4.6

這當然限制了可用的API給你,但你最想用的人都行,只要它沒有用戶界面有關。還有其他的限制,以及:

    2015年或更高
  • 您不必從環境變量獲得特殊目錄(即用戶文檔目錄等)
  • 你的項目只能在Visual Studio中進行編輯
  • 您無法鏈接到設計僅用於你的目標平臺之一的庫(即libgit2sharp等)
  • 有沒有辦法瀏覽API爲這個子集 - MSDN需要得到的棒。 MSDN已經更新了很多的API文檔,但它仍然很難找出適用於您的PCL

但是,您可以鏈接設計爲一個單一的目標平臺,您的PCL任何庫。這並不理想,但總比沒有好。

ASP.NET MVC堆棧已被移植到使用PCL,因此您可以直接使用NewtonSoft.JSON以及該應用程序使用的任何其他庫。但是,有幾個庫尚未被移植。

這種安排迫使您考慮如何更好地整合。 .Net Core 5似乎很穩定,但支持尚處於起步階段。截至VS 2015更新1的最新一代Universal Apps直接使用.Net Core 5。

有距離的NuGet多種功能,目前不支持,即使工作正在進行之中:

  • MS建立擴展(以MSBuild的重大變化和project.json結構)
  • 安裝/卸載腳本(與刪除安裝的概念)
  • 內容(安裝/卸載相關的,但工作是在這一進展)
  • 內容轉換(與缺乏的安裝/卸載)

我希望我有一個更完整的答案。但就我發現PCL以及它是如何演變爲當前的基礎設施而言,這是我所瞭解的。


我正在創建一個遊戲創建工具包,它包含了版本控制權。我希望能夠將遊戲部署爲Windows 10應用程序或標準WPF應用程序,但由於我用來集成版本控制的庫,我需要將該編輯器創建爲標準的WPF應用程序。我必須在構建共享代碼和導入正確的庫方面有點創意。

首先,我的項目層次:

  • Project.Model(便攜式類庫)
  • Project.Model.Versioning(標準C#庫)
  • MVVM。工具包(可移植類庫)
  • 編輯器(標準WPF應用程序)

我想核心PCL是能夠加載的項目及反序列化JSON的編碼對象。 PCL確實可以訪問System.IO,但令人驚訝的是,它與標準C#庫中定義的不一樣。以下是我不得不解決的事情:

  • 增加NewtonSoft.JSON卷裝基準後,我不得不改變目標框架中packages.config文件:

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

  • 相關的所有項目在我的Project.Model類不得不從nuget安裝`system.io.filesystem'包,以便System.IO.FileInfo等對象是相同的。

儘管這絕對不是萬能藥,但它也不是死衚衕。我相信還有更多的問題,但這至少會幫助解決一些問題。

相關問題