我的整個解決方案是否必須是 .NET Framework 而不是 .NET Core，因為我使用需要 .NET Framework 的 NuGet 包？

Question

我有一個 .NET Core 解決方案，包括 3 個部分：

1. ASP.NET Core 網站
2. 業務邏輯 .NET Core DLL
3. 數據訪問 .NET Core DLL

我現在需要使用我的業務邏輯 DLL 中的 .NET Framework NuGet 包（不在我的控制范圍內）。

按照此答案中的建議，我將業務邏輯項目更改為面向 .NET 4.6.1 (net461)。

然而，這迫使我對數據訪問項目（從業務邏輯項目中引用）做同樣的事情，並且（雖然我還沒有到那里）我想我也必須這樣做網站項目。

我認為 .NET Core 在很大程度上是 .NET Framework 的一個子集，除了僅僅需要“更大”的框架之外，不會有任何功能變化，這沒什么。 但是，重新定位我的數據訪問項目后，我現在發現缺少一些東西。 例如，它現在使用 C#7 值元組反對我。

盡管我可以通過 NuGet 包重新添加值元組，但我還需要進行其他更改（DataAnnotations 似乎已經消失/移動了），而且似乎我正在回歸以 .NET Framework 方式完成的所有工作.

有沒有辦法解決？ 我覺得我在拉一根繩子，最終我會一直回到 ASP.NET MVC ......

Answer 1

可以同時針對兩個框架。 我在一個項目上工作，我想以 .Net core 2.0 為目標，但需要使用 .NET Framework 包。

為此，請打開您的 .csproj 文件並將 TargetFramework 標記替換為新的 TargetFrameworks 標記

<TargetFrameworks>net461;netcoreapp2.0</TargetFrameworks>

不幸的是，無法通過 Visual Studio 中的 UI 執行此操作。 進行此更改並重新加載 Visual Studio 后，您的目標框架將是空白的。

Answer 2

在與@Svek 的聊天中說服自己我必須放棄我的整個 web 項目並重新開始一個舊式的 ASP.NET MVC web 項目（或割裂我的手腕），我現在發現這不是案子。

以下是我認為的要點：

1. 如果您使用的是使用 .NET 4.6 的 NuGet 包，則不能在面向 .NET Core 的 DLL 中使用它。

2. 您可以（根據@Matt H 的回答）擁有一個同時面向 .NET Core 和 .NET 4.6 的 DLL - 但這並沒有真正的幫助，因為所做的只是創建了兩個版本的 DLL，並且只有 .NET 4.6 版本可以使用 NuGet 包。 因此，您的 DLL 需要面向 .NET 4.6。

3. 通過擴展，您的解決方案中直接引用該 DLL 的每個項目也需要面向 .NET 4.6。 所以是的，傳染病確實傳播了。 :-(

4. 就我而言，這意味着我的 ASP.NET Core Web 應用程序也需要面向 .NET 4.6 - 我起初認為這意味着完全放棄 ASP.NET Core，並丟棄我已經完成的大量工作我的網絡項目。 然而事實並非如此。

5. 它可以對.NET 4.6的ASP.NET核心的Web應用程序運行（盡管這看起來有點不合邏輯）。 事實上，在 Visual Studio 中創建新的 ASP.NET Core Web 應用程序時，您可以選擇以 .NET 4.6 為目標。 這會生成一個不同的項目文件，具有額外的 NuGet 依賴項等。請參閱此問題。

所以，我最終的解決方案是：

1. 將我所有的 DLL 更改為目標“net461”（通過編輯項目文件）。

2. “填充”了一些因此而丟失的東西（例如，通過添加 NuGet 包來獲得 ValueTuple 支持，並通過添加顯式包引用來獲得 System.Component.DataAnnotations）。

3. 圍繞 ASP.NET Core Web 項目進行了黑客攻擊，還針對“net461”，這意味着更新各種引用並添加更多 NuGet 包以使 ASP.NET Core 組件正常工作。 （我創建了一個新 Web 項目的兩個版本 - 一個針對 .NET Core，一個針對 .NET 4.6 - 以查看差異是什么，因此我必須做出哪些更改）。

完成所有這些后，我的項目可以正確編譯並運行。 這是一個巨大的解脫。

Answer 3

另一種可能的解決方案（盡管可能不是您想要的）是將您的項目分成較小的項目，然后可以將業務和數據邏輯轉換為服務（SOA - https://en.wikipedia.org/wiki/Service-oriented_architecture )

這似乎是“漫長的道路”，但它確實具有最終的優勢，因為分離的邏輯服務和主項目在技術和大多數其他要求方面相互獨立。

同樣，我意識到這可能不是你想要的，但我覺得這是一個有效的選擇，在這里分享可能很有用。