ASP.NET Core 6 基础入门系列(6) 项目结构详解之依赖项
- 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

绝大部分的DLL都是以 Microsoft 开头命名而来,可以看出更像是产品级的命名。
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。
成在管理,败在经验;嬴在选择,输在不学! 贵在坚持!
个人作品
BIMFace.SDK.NET
开源地址:https://gitee.com/NAlps/BIMFace.SDK
系列博客:https://www.cnblogs.com/SavionZhang/p/11424431.html
系列视频:https://www.cnblogs.com/SavionZhang/p/14258393.html
技术栈
1、AI、DeepSeek、MiniMax、通义千问
2、Visual Studio、.NET Core/.NET、MVC、Web API、RESTful API、gRPC、SignalR、Java、Python
3、jQuery、Vue.js、Bootstrap、ElementUI
4、数据库:分库分表、读写分离、SQLServer、MySQL、PostgreSQL、Redis、MongoDB、ElasticSearch、达梦DM、GaussDB、OpenGauss
5、架构:DDD、ABP、SpringBoot、jFinal
6、环境:跨平台、Windows、Linux
7、移动App:Android、IOS、HarmonyOS、微信小程序、钉钉、uni-app、MAUI
8、分布式、高并发、云原生、微服务、Docker、CI/CD、DevOps、K8S;Dapr、RabbitMQ、Kafka、RPC、Elasticsearch
欢迎关注作者头条号 张传宁IT讲堂,获取更多IT文章、视频等优质内容。
出处:www.cnblogs.com/SavionZhang
作者:张传宁 技术顾问、培训讲师、微软MCP、系统架构设计师、系统集成项目管理工程师、科技部创新工程师。
专注于企业级通用开发平台、工作流引擎、自动化项目(代码)生成器、SOA 、DDD、 云原生(Docker、微服务、DevOps、CI/CD);PDF、CAD、BIM 审图等研究与应用。
多次参与电子政务、图书教育、生产制造等企业级大型项目研发与管理工作。
熟悉中小企业软件开发过程:可行调研、需求分析、架构设计、编码测试、实施部署、项目管理。通过技术与管理帮助中小企业实现互联网转型升级全流程解决方案。
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
如有问题,可以通过邮件905442693@qq.com联系。共同交流、互相学习。
如果您觉得文章对您有帮助,请点击文章右下角【推荐】。您的鼓励是作者持续创作的最大动力!