• ASP.NET Core 6 基礎入門系列(5) 項目結構詳解之項目文件管理
• ASP.NET Core 6 基礎入門系列(4) 項目結構簡介
• ASP.NET Core 6 基礎入門系列(3) 新建 ASP.NET Core MVC 6.0 項目 
• ASP.NET Core 6 基礎入門系列(2) 開發環境準備
• ASP.NET Core 6 基礎入門系列(1) ASP.NET Core 6 簡介

 

在 DotNetFx461.Web.Study 項目中引用的DLL管理方式如下圖所示

（1）項目基礎DLL（Sytem.xxx等）、引用項目、引用第三方的DLL全部集中在一起管理。

（2）通過NuGet控制臺引用的第三方DLL，統一在 packages.config 文件中管理。記錄了DLL名稱、版本號及依賴的.NET Framework版本號。

（3）通過NuGet控制臺引用的第三方DLL被下載到項目的根目錄下的packages目錄中。

這種管理方式會存在以下問題：

• 第三方DLL類庫被包含在項目中，導致項目的內容比較多。如果拷貝、移植到其他電腦時，需要較多的時間。
• 一般情況下不會被上傳到源代碼管理服務器上（通過配置排除項實現）。
• 每當新建一個項目后，需要引用第三方DLL，都要重新下載一次并存在于項目中。其實是重復存儲，浪費本地磁盤存儲空間。
• 引用路徑。引用的DLL路徑被記錄在項目文件.csproj文件中，如下圖所示

 <HintPath>節點中引用的DLL是相對路徑。

鑒于以上問題，在.NET Core/.NET6+ 平臺下創建的項目對DLL的管理進行了全新的設計與實現，DotNet6_Web_Study 項目中的DLL管理如下

依賴項組織了項目開發與運行時所需的DLL，分布在不同的類別下：包、程序集、分析器、框架、項目。管理更加清晰明了。

1、框架

.NET Core/.NET6+平臺創建的Web項目中默認包含 Microsoft.NETCore.App 與 Microsoft.AspNetCore.App 兩個軟件包

.NET Core 和 .NET5 及更高版本創建的項目由于能夠跨平臺部署運行，微軟在.NET底層做了大量的適應性改造。

（1）Microsoft.NETCore.App 它是所有項目的基礎框架。它是.NET Core/.NET5+的部分庫，它依賴于更加基礎的 NETStandard.Library。存在在以下目錄中 C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.5\ref\net6.0

通過DLL名稱可以看出都是系統級別的基礎類庫，與 .NET Framework 時代的項目中引用的基礎類庫相似。在部署項目時，其中的程序集無論是否被引用都不會出現在部署包中，這樣會讓部署程序包更加精簡。

（2）Microsoft.AspNetCore.App 框架在 Microsoft.NETCore.App 框架基礎上封裝了大量的Web應用類庫，是一個非常大而全的軟件包，如：MVC、Razor、EF等程序集。

在以下目錄中 C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\6.0.5\ref\net6.0

2、分析器

.NET Compiler Platform (Roslyn) 分析器會檢查 C# 或 Visual Basic 代碼的代碼質量和樣式問題，如安全性、性能、設計及其他問題。 從 .NET5 開始，這些分析器包含在 .NET SDK 中，無需單獨安裝。 如果項目面向 .NET5 或更高版本，則默認啟用代碼分析。 如果項目面向不同的 .NET 實現（例如 .NET Core、.NET Standard 或 .NET Framework），則必須通過將 EnableNETAnalyzers 屬性設置為 true 以手動啟用代碼分析。

展開分析組件，列出了診斷結果。

每一項診斷說明信息如下

關于ASP.NET Core 應用中的代碼分析，請參考微軟官方文檔：https://docs.microsoft.com/zh-cn/aspnet/core/diagnostics/code-analysis?source=recommendations&view=aspnetcore-6.0

Microsoft.CodeAnalysis.CSharp.NetAnalyzers.dll 與 Microsoft.CodeAnalysis.NetAnalyzers.dll 中包含了更豐富的代碼質量分析規則。

如果分析器發現規則沖突，則這些沖突會被報告為建議、警告或錯誤，具體取決于每個規則的配置方式。 代碼分析沖突以前綴“CA”或“IDE”顯示，以便將它們與編譯器錯誤區分開來。

這里沒有全部截圖展示出來。所有規則，請請參考微軟官方博客《代碼質量規則》：https://docs.microsoft.com/zh-CN/dotnet/fundamentals/code-analysis/quality-rules/

（1）編譯項目，查看檢查結果

在底部窗口中給出了4條【消息】類型的建議

第一個問題是：私有變量_logger沒有被其他方法使用，可以刪除。

第二個問題是：定義的方法為被調用，可刪除。

                        方法內定義的變量b未被實際使用，不需要賦值。

以上檢測結果只是建議的提示，不做修改也不會影響項目編譯與使用。如果需要精確控制，則可以調整每一條檢查規則的嚴重性。

（2）設置嚴重性

下表顯示了可為所有分析器規則（包括代碼質量和代碼樣式規則）配置的各種規則嚴重性

更多信息，請參考微軟官方文檔《代碼分析的配置選項》： https://docs.microsoft.com/zh-cn/dotnet/fundamentals/code-analysis/configuration-options

 

如果不想移動到 .NET 5+ SDK、具有非 SDK 樣式的 .NET Framework 項目或更傾向于使用基于 NuGet 包的模型，則也可以在 Microsoft.CodeAnalysis.NetAnalyzers NuGet 包中使用該分析器。 對于按需版本更新，可能更傾向于使用基于包的模型。例如DotNetFx461.Web.Study 項目中可以手動添加代碼分析組件以實現編譯過程中的代碼質量分析

添加引用后，出現分析器組，默認添加了 Microsoft.CodeAnalysis.CSharp.NetAnalyzers.dll 與 Microsoft.CodeAnalysis.NetAnalyzers.dll 兩個分析組件

展開查看如下，默認加載了所有的檢測規則，可以手動調整配置或者刪除分析組件以適應項目代碼質量審查需求

還有很多項，此處沒有全部截圖展示出來。

3、包

（1）該類別管理了項目中通過NuGet方式引用的第三方DLL。

（2）項目中不再使用 packages.config 文件管理。

（3）引用的DLL不是下載到項目根目錄中，而是下載到開發者電腦的 C:\Users\Savion\.nuget\packages 目錄中（藍色字體是開發者電腦的名稱，各不相同），供本地所有項目共同引用。解決了重復下載重復存儲的問題。

右鍵點擊DLL->屬性，可以查看DLL的存儲路徑

（4）引用路徑。引用的DLL路徑被記錄在項目文件.csproj文件中，如下圖所示

通過節點名稱 PackageReference 可以看出，與傳統.NET Framework 平臺下創建的項目中引用的DLL方式完全不同了。這里沒有記錄引用路徑，項目編譯后自動將用到的DLL復制到編譯輸出目錄中。

這種全局統一管理，脫離具體項目的存儲的方式更加友好，當項目拷貝、轉移到其他開發者電腦后，即使電腦中沒有DLL，也會自動下載并編譯成功。

（5）級聯依賴項

• Microsoft.EntityFrameworkCore.SqlServer.dll 自身又依賴于 Microsoft.Data.SqlClient.dll 與 Microsoft.EntityFrameworkCore.Relational.dll 兩個DLL組件。

• 展開Microsoft.Data.SqlClient.dll 與 Microsoft.EntityFrameworkCore.Relational.dll  節點，它們各自又依賴于其他的DLL組件

此處可以一直展開，直到DLL沒有依賴項時就只加載自身節點，比如 Newtonsoft.Json.dll 就沒有依賴任何其他DLL

• 編譯項目，打開編譯后的輸出目錄可以看到手動引用的第三方DLL及其依賴DLL

4、項目

該分類管理了本項目引用整個解決方案中的其他項目

引用記錄在項目文件.csproj中通過<ProjectReference>節點被記錄，Include 屬性值記錄的是相對路徑。

如果引用本解決方案下的其他項目，強烈建議直接引用項目，而不是引用其他項目編譯輸出目錄中的DLL。

5、程序集

該分組管理了本項目引用本地開發者電腦中的第三方DLL。這里分3種情況討論

（1）引用本解決方案中其他項目編譯輸出目錄中的DLL，引用路徑為相對路徑

與直接引用項目相比有明顯的差別：項目引用是用<ProjectReference />，DLL引用是用<Reference />實現。

強烈建議直接引用項目，而不是引用其他項目編譯輸出目錄中的DLL。

（2）引用的DLL與本項目在同一個磁盤內，引用路徑為相對路徑

（3）引用的DLL與本項目不在同一個磁盤內，引用路徑為絕對路徑

總結：在.NET Framework 時代，當項目中需要引用很多第三方程序集的時候，首先下載第三方的DLL放到本地的某個專門目錄中，然后不同的項目直接引用該目錄中的DLL。企業級項目開發都是團隊協作的方式進行，多人共同維護一個項目，由于每個開發者從服務器下載項目源碼到本地存放的路徑不同，當A程序員提交項目（包含.csproj文件），B程序員更新項目后，服務器上的新版.csproj文件被下載到本地后會覆蓋本地的.csproj文件，這其中就會導致原本正確引用的DLL路徑會被A程序員的配置路徑信息覆蓋，此時再編譯項目，一定會失敗。此時B程序員又需要手動去調整DLL引用的路徑問題，這是很麻煩且費時的工作，甚至會導致程序員情緒煩躁等問題。這種現象在大部分的軟件公司及項目組都存在，為了解決該問題，建議采用以下方式

1、首先推薦通過NuGet方式引用第三方DLL。

2、如果開發環境不能接入互聯網，建議搭建內網私有化的NuGet服務器，在【NuGet包管理】中配置私有化服務器信息，開發者通過此方式下載內網的第三方DLL。

3、如果引用解決方案內的項目，則直接引用項目，不要引用編譯后的DLL。

4、禁止直接引用本地磁盤目錄中的DLL。