從ASP.NET Core項目引用.NET 3.5 DLL項目

我有一個在.NET 3.5下編譯的代表POCO數據模型的DLL。客戶端應用程序僅限於.NET 3.5，並且DLL必須由客戶端和服務器共享，因此不能重新編譯該DLL。從ASP.NET Core項目引用.NET 3.5 DLL項目

我試圖將服務器REST API重寫爲ASP.NET Core MVC項目（使用VS2015下的1.0版本和預覽版本2工具）。我試圖更新與所謂的「bin語法」的project.json如下圖所示，但包恢復日誌顯示了一堆錯誤，如：

error: Package Microsoft.NETCore.App 1.0.0 is not compatible with net35 (.NETFramework,Version=v3.5). Package Microsoft.NETCore.App 1.0.0 supports: netcoreapp1.0 (.NETCoreApp,Version=v1.0)

"frameworks": { 
"netcoreapp1.0": { 
    "imports": [ "dotnet5.6", "portable-net45+win8" ] 
}, 
"net35": { 
    "bin": { "assembly": "c:\\source\\externaldllsdebug\\datadef.dll" } 
}

我也嘗試設立的NuGet打包在DLL文件夾中，然後使該文件夾成爲新的nuget源。它打開包很好，但試圖導入DLL時失敗。

來源

2016-07-15 McGuireV10

我會嘗試瞄準net451 +，並保持我的手指交叉:) – Pawel

我不認爲你目前正在嘗試做什麼。

另一種解決辦法是重構產生共享的DLL產生，這將是既.NET 3.5和netcoreapp1.0兼容的庫項目：

"frameworks": { 
    "net35": { }, 
    "netstandard1.1": { 
     "dependencies": { 
      "NETStandard.Library": "1.6.0" 
     } 
    } 
}

這樣，你就可以產生一個DLL，仍然在你的.NET 3.5項目中工作，也可以安裝在你的ASP.NET Core項目中，沒有任何問題或黑客。

來源

2016-07-15 23:30:12

正如你可能知道的，這會產生兩個DLL。正如你注意到的那樣，雖然比維護兩個項目更容易，但這並不是我想要的，但我很欣賞這個建議。我想如果我想追求NuGet包裝角度，這是正確的方法。 – McGuireV10

@ McGuireV10是的，它確實產生了兩個DLL。但是如果你通過NuGet打包，只有一個將被安裝在項目中。 –

我會給你答案的答案。經過額外的調查發現，這個DLL並不像我以前所認爲的那樣簡單，所以如果沒有一些其他的依賴聲明（與3.5版的mscorlib相比），它不會與Core兼容，所以NuGet體操是不可避免的。 – McGuireV10

從ASP.NET Core項目引用.NET 3.5 DLL項目

回答

相關問題