TargetFramework、OutputType、LangVersion、Nullable、ImplicitUsings等Property决定实际编译行为；Compile/None/Content等ItemGroup控制文件是否参与编译或复制；dotnet build与msbuild.exe因运行时和属性覆盖逻辑差异可能导致不一致；调试须用-bl生成二进制日志分析真实执行流。
直接用 dotnet build 或 msbuild.exe 跑一个 C# 项目，不报错 ≠ 构建逻辑正确。很多看似“能编译通过”的项目，在 CI 环境、跨机器构建或升级 SDK 后突然失败，根源往往在 csproj 文件里那些被默认值掩盖的隐式行为。
csproj 文件里哪些 Property 决定实际编译行为
SDK 样式项目（Sdk="Microsoft.NET.Sdk"）表面简洁，但大量行为由隐式导入的 Microsoft.NET.Sdk.targets 和 Microsoft.Common.targets 控制。真正影响构建结果的是显式或隐式设置的 Property：
-
TargetFramework（如net6.0）决定引用的框架程序集、语言版本、可用 API —— 它不是“建议”，而是编译器和 SDK 的硬性输入 -
OutputType（Exe/Library）控制是否生成入口点、是否链接System.Runtime等基础库 -
LangVersion若未显式指定，会随TargetFramework自动推导（例如net6.0→10.0），但 CI 中若 SDK 版本不一致，可能意外降级 -
Nullable和ImplicitUsings不只是编译警告开关，它们会注入额外的编译器指令和全局 using 语句，改变实际生成的 IL
为什么 dotnet build 和 msbuild.exe 行为有时不一致
两者调用的是不同运行时上的 MSBuild 引擎：
-
dotnet build调用的是 .NET SDK 自带的dotnet msbuild（基于 .NET Core/.NET 5+ 运行），只支持 SDK 样式项目（Microsoft.NET.Sdk） -
msbuild.exe（来自 Visual Studio 安装目录）是完整版 MSBuild，基于 .NET Framework，能处理传统项目格式（如net472+packages.config），也兼容 SDK 样式，但某些属性（如RuntimeIdentifier）解析逻辑略有差异 - 关键陷阱：
dotnet build -p:Configuration=Release中的-p设置的是全局属性，会覆盖 csproj 中<PropertyGroup>的同名定义；而msbuild.exe在某些旧版本中对属性覆盖顺序更敏感，尤其涉及Condition判断时
<ItemGroup> 中的 Compile、None、Content 到底影响什么
这些不是“文件分类标签”，而是构建流程中任务的明确输入源：
-
<Compile Include="Program.cs" />→ 被Csc任务读取，参与编译；若漏掉某个.cs文件，它根本不会出现在最终 DLL 中 -
<None Include="appsettings.json" />→ 默认不参与编译，但会被CopyToOutputDirectory任务识别（若设置了该属性），否则不会复制到输出目录 -
<Content Include="web.config" CopyToOutputDirectory="PreserveNewest" />→ 显式触发复制逻辑；但若写成<None ...>却没设CopyToOutputDirectory，该文件在bin/下完全不会出现 - 通配符风险：
<Compile Include="**/*.cs" />看似方便，但若项目引入了 NuGet 包含源码（如SourceGenerators），可能意外重复编译或冲突
调试构建失败时，先看 msbuild -bl 生成的二进制日志
仅靠命令行文本输出，90% 的构建问题无法定位。真实构建失败常发生在隐式目标中（比如 CoreCompile 之前被 GenerateAssemblyInfo 拦截）：
- 运行
msbuild -bl:build.binlog或dotnet build -bl:build.binlog - 用 MSBuild Structured Log Viewer 打开，展开左侧树形结构，重点看
Target节点执行顺序、每个Task的输入参数和返回值 - 常见盲区：错误显示
CSC : error CS0006: Metadata file 'xxx.dll' could not be found，但实际是上游ResolveAssemblyReferences目标没找到引用项 —— 日志里能直接看到它尝试搜索的路径列表 - 不要依赖 IDE 的“重建”按钮：它可能跳过增量检查或缓存状态，而
msbuild -bl是最接近真实 CI 环境的复现方式
最易被忽略的复杂点：所有 Property 和 Item 都有作用域和评估时机。一个在 <Target Name="BeforeBuild"> 里修改的 Property，对 <Target Name="CoreCompile"> 是否生效，取决于该属性是否在 CoreCompile 开始前已被“冻结”。这没有文档直接说明，只能靠 -bl 日志观察实际值流。
