2017-02-25 33 views
4

TL; DR版本

我建立一個.NET的核心LIB在project.json目標框架netstandard1.6 + dnxcore50。我的二進制文件內置到具有匹配名稱的文件夾中。 MSDN's Nuget naming conventiondnxcore50是一個「不推薦使用」的框架 - 所以我應該重命名我的文件夾到netcore50或者我應該完全針對另一個框架?向Nuget發佈.NET Core項目 - 要使用哪個框架版本?

我正在使用VS 2015社區和DotNetCore.1.0.1 SDK。

龍版

我保持一個FTP庫調用FluentFTP。我已經使用VS 2015社區成功編譯了.NET核心版本。我project.json看起來是這樣的:

{ 
    "dependencies": { 
    "NETStandard.Library": "1.6.0", 
    "System.IO": "4.3.0.0", 
    "System.Net.NameResolution": "4.3.0.0", 
    "System.Net.Sockets": "4.3.0.0", 
    "System.Net.Security": "4.3.0.0" 
    }, 
    "frameworks": { 
    "netstandard1.6": { 
     "imports": "dnxcore50" 
    }, 
    "dnxcore50": { 
    } 
    } 
} 

我複製了另一個項目的frameworks節,因爲我不知道該用什麼樣的格式。正如你所看到的,我的目標是.NET Core 5.0(顯然)和.NET Standard 1.6。我可以成功構建,所以我假設我已經構建了.NET Standard 1.6和.NET Core 5.0版本(對不對?)。當我建,我得到這樣的目錄結構:

  • dnxcore50
  • netstandard1.6
  • net20
  • net40

爲了發佈一個多框架的lib到的NuGet ,MSDN說你需要遵循一定的naming convention

不幸的是,dnxcore50naming convention文章中被標記爲「已棄用的框架」。這是否意味着:

  1. 我正在爲錯誤/過時類型的框架?

  2. 我只需要將文件夾dnxcore50重命名爲netcore50併發布它呢?

回答

0

只是叫dnxcore50文件夾發佈。雖然它的命名規則稍微老一點,但lib仍然可以在VS 2015中創建的.NET Core項目中安裝。我已經測試過它,它可以工作。獨立覈實,請嘗試通過「管理的NuGet包該項目」對話框中的VS 2015

在.NET的核心工程安裝 FluentFTP

編輯:對於VS 2017年看到solution in this answer

+0

它是否也與VS2017,它採用了新的項目系統對於.NET的核心工作? – svick

+0

@svick - 請參閱:http://stackoverflow.com/questions/42856619/the-reference-assemblies-for-framework-dnxcore-version-v5-0-were-not-found/42856620#42856620 –

0

一個恐怕這不過是我的意見(哲學實際上的問題),雖然我覺得可以考慮相關問題的答案:

一般來說,你應該要求你實際使用的並沒有更多。這意味着框架的最舊版本和您使用其功能的語言。提供與新版本完全兼容(理想情況下,在這種情況下,您應該定期在所有更新的框架版本上測試您的代碼)。如果它不是,但你仍然想支持它(因爲你和/或其他人落入你的目標受衆中,或許仍然在遺留代碼支持中使用它),你應該考慮爲不同的平臺構建單獨的版本,有時甚至可能意味着維護代碼某些部分的並行版本。

我並不是說你應該有意地限制自己使用的功能只是爲了支持舊的框架和/或語言(這是一個單獨的,很主觀的和與上下文相關的問題)。我只是說,就像在Windows XP計算機上用C#3.0編寫整個項目時一樣,然後他的公司向他購買帶有Windows 10和Visual Studio 2017的全新閃亮筆記本電腦,並開始單獨針對.NET Framework 4.6.2進行構建只是因爲他可以,儘管他甚至不知道在此框架中添加的單個新功能。

我會考慮一個合理的例外,從上述理念是預發佈(alpha,beta,ctp,rc等)版本的框架 - 恰好你的情況,據我瞭解。一旦發佈版本,開發人員應儘快切換到該版本(但不能早於©)。然而,無論何種原因和靈活性與試圖達到實用(或稍高一點)的邏輯形式主義程度(爲了更高效的決策制定)相結合,例外情況都會出現例外,在這種情況下,這些例外是:

  1. 在放棄對廣泛使用的任何東西的支持之前要三思。在現實世界中,當較舊版本/預發行版本比新版本/發行版本更廣泛地採用時,情況發生了變化,客觀上阻礙了升級過程的版本之間可能發生重大變化。 這也可能是你的情況,我真的不知道有多嚴重(需要多少工作來升級現有代碼)這種情況下的變化是,有多少人正在使用舊版本的框架,您在庫新版本中引入的修改有多重要(例如,如果它包含嚴重的錯誤修復或實際使用非常好的新功能和/或使遷移到新框架更容易)。

  2. 如果這不需要大量的時間,精力和自由(例如使用新的框架/語言特性)以及其他資源,並且持續支持即使是過時的東西,只要至少有一些人們選擇繼續使用它。如果你覺得你開始無法享受配套的是,它可以是一種發送剩餘的用戶終端的支持的通知信函和/或在您的博客發佈,微博等