EF Core 源码构建完全指南从环境准备、本地 SDK 安装到本地 NuGet 包打包【免费下载链接】efcoreEF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.项目地址: https://gitcode.com/GitHub_Trending/ef/efcore本文基于 EF Core 仓库中的 getting-and-building-the-code.md 编写系统讲解如何从零开始拉取、构建并测试 EF Core 源码涵盖 SQL Server 与 Cosmos 测试前置环境、仓库自带的build/restore/test脚本族、global.json驱动的本地 .NET SDK 安装机制、build -pack本地 NuGet 包构建以及 Visual Studio 集成与常见构建错误的排查方法。读完后你可以独立完成 EF Core main 分支的编译、测试和本地包分发验证。适用范围仅面向 main 分支文档开宗明义以下所有步骤仅适用于当前main 分支。EF Core 的构建体系会随版本迭代变化例如 .NET SDK 版本、Arcade 工具链版本如果你的工作基于某个 release 分支请以该分支中的同名文档为准。环境前置条件EF Core 本身编译不需要额外安装任何前置组件构建脚本会自行下载所需的 .NET SDK。但运行测试时需要本地具备特定数据库SQL Server 测试LocalDb 或独立 SQL ServerSQL Server 相关的功能测试要求本机有一个可用的 SQL Server 实例可选方案SQL Server LocalDb通常随安装 Visual Studio选择 ASP.NET and web development 工作负载一并获得开箱即用SQL Server Express 或 Developer Edition可运行在 Windows 或 Linux 上。注意当不使用 LocalDb 时必须设置环境变量Test__SqlServer__DefaultConnection其值为测试应使用的连接字符串否则测试无法定位数据库。Cosmos 测试Azure Cosmos 模拟器可选需要安装Azure Cosmos 模拟器并使用默认安装选项每次重启机器后都要手动启动模拟器。该部分是可选的如果模拟器不可用Cosmos 测试会自动跳过。如果你不打算修改 Cosmos 相关代码完全可以不装模拟器交给 CI 系统去跑。实用技巧在模拟器中关闭 Rate Limiting限流可以让 Cosmos 测试跑得更快——模拟限流会显著拖慢测试节奏具体开关位置见上面的截图。.NET SDK非必需但强烈建议虽然构建脚本在需要时会自行下载 SDK但文档仍建议本机安装最新公共预览版 .NET SDK。这与仓库 global.json 的内容一致{ sdk: { version: 11.0.100-rc.1.26420.103, allowPrerelease: true, rollForward: latestMajor, paths: [.dotnet, $host$], errorMessage: The required .NET SDK wasnt found. Please run ./restore.sh or .\\restore.cmd to install it. }, test: { runner: Microsoft.Testing.Platform }, msbuild-sdks: { Microsoft.DotNet.Arcade.Sdk: 11.0.0-beta.26456.102 } }从这份配置可以看出几个关键机制paths: [.dotnet, $host$]表示优先查找仓库根目录下的.dotnet文件夹即构建脚本安装的本地 SDK找不到再回落到系统全局安装的 SDKerrorMessage字段明确提示找不到 SDK 时请运行./restore.sh或restore.cmd安装——这正是build作为重要一步的原因msbuild-sdks锁定了 Arcade 工具链Microsoft.DotNet.Arcade.Sdk版本保证 MSBuild 行为与 dotnet 官方仓库一致test.runner声明测试通过Microsoft.Testing.Platform运行。Fork 与 Clone如果你的目的是向 EF Core 贡献代码先在 GitHub 上创建 fork再用你习惯的 git 客户端克隆仓库。克隆主仓库git clone https://github.com/dotnet/efcore.git若已在个人账号下 fork 出名为efcore的仓库则克隆自己的 forkgit clone https://github.com/myusername/efcore.git构建build 脚本为什么是重要一步构建代码只需在仓库根目录执行build文档特别强调这是重要步骤important step因为它会在 EF Core 仓库旁边安装一份预览版 .NET SDK确保 EF Core 始终使用预期的 SDK 与 MSBuild 版本进行编译。执行build同时完成还原包restore和构建全部项目但不运行测试。根目录脚本的真实调用链文档给出的参数表中提到的根目录build、restore.cmd、test.cmd等文件都是薄封装。从源码看它们的实现极其简洁restore.cmd 的全部内容就是调用eng\common\build.ps1 -nodeReuse:$false -restorerestore.sh、test.sh 同理分别调用 eng/common/build.sh 并附带--restore、--test参数同时传--nodeReuse false以避免复用 MSBuild 节点。也就是说所有入口最终都汇聚到eng/common/build.ps1与eng/common/build.sh这对核心脚本它们把命令行开关翻译成 MSBuild 属性/p:Restore…、/p:Build…、/p:Test…、/p:Pack…等再驱动构建。常用构建参数完整参数列表可通过build -h查看。文档列出的常用动作与对应脚本如下Build argumentActionScript file-restoreRestore packages还原 NuGet 包restore.cmd-buildBuild all projects构建所有项目build.cmd-testRun all tests, requires build运行全部测试需先构建test.cmd-packBuild and produce NuGet packages构建并产出 NuGet 包None无对应根目录脚本进一步阅读 eng/common/build.sh 中的usage()帮助文本可以看到更多本地开发会用得到的参数参数作用--rebuild重新构建rebuild--clean清理artifacts目录--integrationTest/--performanceTest运行集成测试 / 性能测试--sourceBuild/--productBuild源构建 / 模拟 .NET 完整产品VMR构建方式会连带触发 restore、build、pack--configuration value构建配置Debug本地默认或Release--verbosity valueMSBuild 详细度quiet / minimal / normal / detailed / diagnostic--binaryLog生成 MSBuild 二进制日志方便用 MSBuild 日志查看器分析--projects value指定要构建的项目或解决方案文件而不是全仓库未在上面列出的命令行参数会直接透传给 MSBuild脚本源码中有properties($1)的兜底分支例如后文的/p:OfficialBuildId…。构建本地 NuGet 包OfficialBuildId 与本地包源build -pack会把所有 EF Core NuGet 包构建到artifacts\packages目录。但这里有一个坑无论构建多少次包的版本号都不变这会与 NuGet 的包缓存机制打架——缓存可能让你拿到的还是旧包。因此文档要求每次打包时指定新的内部构建号build /p:OfficialBuildId20231212.6 -pack构建号遵循 .NET 内部约定yyyyMMdd.x日期 递增序号每构建一批就把 x 加一。要消费这些本地包需要在你的解决方案或项目目录放置NuGet.config把本地包目录加入包源。文档给出的完整示例?xml version1.0 encodingutf-8? configuration packageSources add keynuget.org valuehttps://api.nuget.org/v3/index.json protocolVersion3 / add keyLocal valueC:\local\code\efcore\artifacts\packages\Debug\Shipping / /packageSources /configuration注意Local源指向的是artifacts\packages\Debug\Shipping——即Debug配置下的 Shipping正式发行包目录若你用 Release 配置打包路径相应调整。顺带一提EF Core 仓库自身的 NuGet.config 也值得看一眼它通过clear /清空继承源后显式添加了dotnet-eng、dotnet-tools、dotnet8至dotnet12等一系列 Azure DevOps 公共 feed。这也正是后文排查构建错误时检查包源 URL 是否可达的对象——本地网络若访问不了这些 feedrestore 阶段就会失败。在 Visual Studio 中使用源码务必先执行一次命令行build再打开解决方案。原因是构建脚本安装的是仓库本地的预览 SDK而 IDE 默认走系统 SDK两者版本不一致会引发奇怪的构建失败。startvs.cmd 做了什么文档推荐的入口命令startvs.cmd EFCore.sln从 startvs.cmd 的源码可以确认它完成三件事设置DOTNET_ROOT指向仓库根目录下的.dotnet\若定义了DOTNET_GLOBAL_INSTALL_DIR则优先使用保证 .NET 使用仓库本地安装的dotnet.exe把该目录插到 PATH 最前面让 Visual Studio 找到正确的 SDK若本地dotnet.exe尚不存在先自动调用restore.cmd补装最后用start打开你传入的解决方案。文档还提醒了两点startvs实际打开的是系统默认关联.sln的程序。如果你装了多个 IDE 或多个版本的 Visual Studio请确认默认关联正确或直接编辑脚本写死目标程序如果你安装了最新的公共预览版 .NET SDK理论上可以跳过startvs直接打开解决方案。但 EF Core 可能依赖比最新预览版更新的内部变更直接打开出现意外错误时请回到startvs方案并确保 Visual Studio 也是最新预览版。Linux/macOS 下可以查看 activate.sh 做类似配置它export DOTNET_ROOT$DIR/.dotnet、把本地 dotnet 加入 PATH 头部并定义deactivate函数用于还原环境。运行测试EF Core 的测试使用xUnit.net编写绝大多数测试运行器都能跑。命令行方式需要先完成 buildtesttest脚本test.cmd/ test.sh本质是带--test参数调用eng/common/build.ps1/eng/common/build.sh。结合前文前置条件请留意SQL Server 测试依赖 LocalDb 或已配置Test__SqlServer__DefaultConnection的独立实例Cosmos 测试在模拟器不可用时会被跳过。常见构建错误的排查步骤文档给出的三步排查法建议按顺序执行检查包源可达性确认根目录 NuGet.config 中列出的包源 URL如dotnet-eng、dotnet11等 feed都能访问清理源码目录git clean -xid可清除 EF 源码目录中的未跟踪文件清理 NuGet 缓存nuget.exe locals all -clear会清空所有 NuGet 缓存nuget.exe也可用dotnet nuget替代操作。这三步分别对应网络/源问题、脏工作区问题、缓存污染问题三类最常见的构建失败根因。小结关键文件速查环节关键文件本文主体docs/getting-and-building-the-code.mdSDK/工具链锁定global.json包源配置NuGet.config根入口脚本build.cmd、restore.cmd、test.cmd 及对应.sh核心构建实现eng/common/build.sh、eng/common/build.ps1IDE 环境注入startvs.cmd、activate.shCosmos 限流开关截图docs/rate_limiting.png掌握前置条件 →build装本地 SDK restore build→test/build -pack→startvs打开 IDE这条主线再配合global.json、NuGet.config和eng/common下的脚本源码你就能在本地完整复现 EF Core 的构建与测试流程。【免费下载链接】efcoreEF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.项目地址: https://gitcode.com/GitHub_Trending/ef/efcore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
EF Core 源码构建完全指南从环境准备、本地 SDK 安装到本地 NuGet 包打包【免费下载链接】efcoreEF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.项目地址: https://gitcode.com/GitHub_Trending/ef/efcore本文基于 EF Core 仓库中的 getting-and-building-the-code.md 编写系统讲解如何从零开始拉取、构建并测试 EF Core 源码涵盖 SQL Server 与 Cosmos 测试前置环境、仓库自带的build/restore/test脚本族、global.json驱动的本地 .NET SDK 安装机制、build -pack本地 NuGet 包构建以及 Visual Studio 集成与常见构建错误的排查方法。读完后你可以独立完成 EF Core main 分支的编译、测试和本地包分发验证。适用范围仅面向 main 分支文档开宗明义以下所有步骤仅适用于当前main 分支。EF Core 的构建体系会随版本迭代变化例如 .NET SDK 版本、Arcade 工具链版本如果你的工作基于某个 release 分支请以该分支中的同名文档为准。环境前置条件EF Core 本身编译不需要额外安装任何前置组件构建脚本会自行下载所需的 .NET SDK。但运行测试时需要本地具备特定数据库SQL Server 测试LocalDb 或独立 SQL ServerSQL Server 相关的功能测试要求本机有一个可用的 SQL Server 实例可选方案SQL Server LocalDb通常随安装 Visual Studio选择 ASP.NET and web development 工作负载一并获得开箱即用SQL Server Express 或 Developer Edition可运行在 Windows 或 Linux 上。注意当不使用 LocalDb 时必须设置环境变量Test__SqlServer__DefaultConnection其值为测试应使用的连接字符串否则测试无法定位数据库。Cosmos 测试Azure Cosmos 模拟器可选需要安装Azure Cosmos 模拟器并使用默认安装选项每次重启机器后都要手动启动模拟器。该部分是可选的如果模拟器不可用Cosmos 测试会自动跳过。如果你不打算修改 Cosmos 相关代码完全可以不装模拟器交给 CI 系统去跑。实用技巧在模拟器中关闭 Rate Limiting限流可以让 Cosmos 测试跑得更快——模拟限流会显著拖慢测试节奏具体开关位置见上面的截图。.NET SDK非必需但强烈建议虽然构建脚本在需要时会自行下载 SDK但文档仍建议本机安装最新公共预览版 .NET SDK。这与仓库 global.json 的内容一致{ sdk: { version: 11.0.100-rc.1.26420.103, allowPrerelease: true, rollForward: latestMajor, paths: [.dotnet, $host$], errorMessage: The required .NET SDK wasnt found. Please run ./restore.sh or .\\restore.cmd to install it. }, test: { runner: Microsoft.Testing.Platform }, msbuild-sdks: { Microsoft.DotNet.Arcade.Sdk: 11.0.0-beta.26456.102 } }从这份配置可以看出几个关键机制paths: [.dotnet, $host$]表示优先查找仓库根目录下的.dotnet文件夹即构建脚本安装的本地 SDK找不到再回落到系统全局安装的 SDKerrorMessage字段明确提示找不到 SDK 时请运行./restore.sh或restore.cmd安装——这正是build作为重要一步的原因msbuild-sdks锁定了 Arcade 工具链Microsoft.DotNet.Arcade.Sdk版本保证 MSBuild 行为与 dotnet 官方仓库一致test.runner声明测试通过Microsoft.Testing.Platform运行。Fork 与 Clone如果你的目的是向 EF Core 贡献代码先在 GitHub 上创建 fork再用你习惯的 git 客户端克隆仓库。克隆主仓库git clone https://github.com/dotnet/efcore.git若已在个人账号下 fork 出名为efcore的仓库则克隆自己的 forkgit clone https://github.com/myusername/efcore.git构建build 脚本为什么是重要一步构建代码只需在仓库根目录执行build文档特别强调这是重要步骤important step因为它会在 EF Core 仓库旁边安装一份预览版 .NET SDK确保 EF Core 始终使用预期的 SDK 与 MSBuild 版本进行编译。执行build同时完成还原包restore和构建全部项目但不运行测试。根目录脚本的真实调用链文档给出的参数表中提到的根目录build、restore.cmd、test.cmd等文件都是薄封装。从源码看它们的实现极其简洁restore.cmd 的全部内容就是调用eng\common\build.ps1 -nodeReuse:$false -restorerestore.sh、test.sh 同理分别调用 eng/common/build.sh 并附带--restore、--test参数同时传--nodeReuse false以避免复用 MSBuild 节点。也就是说所有入口最终都汇聚到eng/common/build.ps1与eng/common/build.sh这对核心脚本它们把命令行开关翻译成 MSBuild 属性/p:Restore…、/p:Build…、/p:Test…、/p:Pack…等再驱动构建。常用构建参数完整参数列表可通过build -h查看。文档列出的常用动作与对应脚本如下Build argumentActionScript file-restoreRestore packages还原 NuGet 包restore.cmd-buildBuild all projects构建所有项目build.cmd-testRun all tests, requires build运行全部测试需先构建test.cmd-packBuild and produce NuGet packages构建并产出 NuGet 包None无对应根目录脚本进一步阅读 eng/common/build.sh 中的usage()帮助文本可以看到更多本地开发会用得到的参数参数作用--rebuild重新构建rebuild--clean清理artifacts目录--integrationTest/--performanceTest运行集成测试 / 性能测试--sourceBuild/--productBuild源构建 / 模拟 .NET 完整产品VMR构建方式会连带触发 restore、build、pack--configuration value构建配置Debug本地默认或Release--verbosity valueMSBuild 详细度quiet / minimal / normal / detailed / diagnostic--binaryLog生成 MSBuild 二进制日志方便用 MSBuild 日志查看器分析--projects value指定要构建的项目或解决方案文件而不是全仓库未在上面列出的命令行参数会直接透传给 MSBuild脚本源码中有properties($1)的兜底分支例如后文的/p:OfficialBuildId…。构建本地 NuGet 包OfficialBuildId 与本地包源build -pack会把所有 EF Core NuGet 包构建到artifacts\packages目录。但这里有一个坑无论构建多少次包的版本号都不变这会与 NuGet 的包缓存机制打架——缓存可能让你拿到的还是旧包。因此文档要求每次打包时指定新的内部构建号build /p:OfficialBuildId20231212.6 -pack构建号遵循 .NET 内部约定yyyyMMdd.x日期 递增序号每构建一批就把 x 加一。要消费这些本地包需要在你的解决方案或项目目录放置NuGet.config把本地包目录加入包源。文档给出的完整示例?xml version1.0 encodingutf-8? configuration packageSources add keynuget.org valuehttps://api.nuget.org/v3/index.json protocolVersion3 / add keyLocal valueC:\local\code\efcore\artifacts\packages\Debug\Shipping / /packageSources /configuration注意Local源指向的是artifacts\packages\Debug\Shipping——即Debug配置下的 Shipping正式发行包目录若你用 Release 配置打包路径相应调整。顺带一提EF Core 仓库自身的 NuGet.config 也值得看一眼它通过clear /清空继承源后显式添加了dotnet-eng、dotnet-tools、dotnet8至dotnet12等一系列 Azure DevOps 公共 feed。这也正是后文排查构建错误时检查包源 URL 是否可达的对象——本地网络若访问不了这些 feedrestore 阶段就会失败。在 Visual Studio 中使用源码务必先执行一次命令行build再打开解决方案。原因是构建脚本安装的是仓库本地的预览 SDK而 IDE 默认走系统 SDK两者版本不一致会引发奇怪的构建失败。startvs.cmd 做了什么文档推荐的入口命令startvs.cmd EFCore.sln从 startvs.cmd 的源码可以确认它完成三件事设置DOTNET_ROOT指向仓库根目录下的.dotnet\若定义了DOTNET_GLOBAL_INSTALL_DIR则优先使用保证 .NET 使用仓库本地安装的dotnet.exe把该目录插到 PATH 最前面让 Visual Studio 找到正确的 SDK若本地dotnet.exe尚不存在先自动调用restore.cmd补装最后用start打开你传入的解决方案。文档还提醒了两点startvs实际打开的是系统默认关联.sln的程序。如果你装了多个 IDE 或多个版本的 Visual Studio请确认默认关联正确或直接编辑脚本写死目标程序如果你安装了最新的公共预览版 .NET SDK理论上可以跳过startvs直接打开解决方案。但 EF Core 可能依赖比最新预览版更新的内部变更直接打开出现意外错误时请回到startvs方案并确保 Visual Studio 也是最新预览版。Linux/macOS 下可以查看 activate.sh 做类似配置它export DOTNET_ROOT$DIR/.dotnet、把本地 dotnet 加入 PATH 头部并定义deactivate函数用于还原环境。运行测试EF Core 的测试使用xUnit.net编写绝大多数测试运行器都能跑。命令行方式需要先完成 buildtesttest脚本test.cmd/ test.sh本质是带--test参数调用eng/common/build.ps1/eng/common/build.sh。结合前文前置条件请留意SQL Server 测试依赖 LocalDb 或已配置Test__SqlServer__DefaultConnection的独立实例Cosmos 测试在模拟器不可用时会被跳过。常见构建错误的排查步骤文档给出的三步排查法建议按顺序执行检查包源可达性确认根目录 NuGet.config 中列出的包源 URL如dotnet-eng、dotnet11等 feed都能访问清理源码目录git clean -xid可清除 EF 源码目录中的未跟踪文件清理 NuGet 缓存nuget.exe locals all -clear会清空所有 NuGet 缓存nuget.exe也可用dotnet nuget替代操作。这三步分别对应网络/源问题、脏工作区问题、缓存污染问题三类最常见的构建失败根因。小结关键文件速查环节关键文件本文主体docs/getting-and-building-the-code.mdSDK/工具链锁定global.json包源配置NuGet.config根入口脚本build.cmd、restore.cmd、test.cmd 及对应.sh核心构建实现eng/common/build.sh、eng/common/build.ps1IDE 环境注入startvs.cmd、activate.shCosmos 限流开关截图docs/rate_limiting.png掌握前置条件 →build装本地 SDK restore build→test/build -pack→startvs打开 IDE这条主线再配合global.json、NuGet.config和eng/common下的脚本源码你就能在本地完整复现 EF Core 的构建与测试流程。【免费下载链接】efcoreEF Core is a modern object-database mapper for .NET. It supports LINQ queries, change tracking, updates, and schema migrations.项目地址: https://gitcode.com/GitHub_Trending/ef/efcore创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
