Jenkins Pipeline构建.NET Framework与.NET Core应用技术问询

1. 构建.NET Framework应使用dotnet命令还是msbuild命令？有文章指出msbuild更适配，dotnet兼容性不足，当前情况是否仍如此？ #

目前来看，msbuild仍是.NET Framework构建的首选。虽然dotnet build也能处理部分.NET Framework项目，但它对旧版.NET Framework（比如4.5及更早）、复杂的MSBuild自定义脚本、以及依赖传统.NET工具链的项目支持不够完善。而msbuild是.NET Framework原生的构建工具，能完全兼容所有.NET Framework项目的构建逻辑，包括各种自定义目标和扩展。如果你的项目是.NET Framework 4.6.1及以上，dotnet build可能能跑，但遇到复杂场景还是容易出问题，稳妥起见用msbuild更靠谱。

2. 构建.NET Framework时，是否无需同时执行build和publish命令，仅执行publish即可（默认会触发build）？ #

对的，直接执行msbuild /t:Publish或者dotnet publish（如果适用）就够了。publish目标在执行时会自动先触发build目标，所以没必要单独跑build。不过如果你的Pipeline需要在build后做一些中间检查（比如单元测试、代码扫描），那可以分开执行：先build，完成检查后再publish，这样能提前发现问题，避免白跑publish流程。

3. 有资料提到发布需针对项目文件而非解决方案文件，多项目应用中针对主项目csproj文件发布是否足够？ #

要看项目结构。如果你的主项目已经通过项目引用包含了所有依赖的子项目，直接发布主项目的csproj是足够的——msbuild/dotnet publish会自动处理所有依赖项目的构建和打包。但如果解决方案里有多个独立的发布目标（比如多个Web项目），那你需要分别针对每个要发布的项目执行publish。另外，如果依赖项目是NuGet包而不是项目引用，那不管针对项目还是解决方案发布都没问题，但针对主项目更高效，因为不会处理无关项目。

4. 在CI/CD Pipeline中构建、发布及部署时，何时需要使用发布配置文件？ #

发布配置文件（.pubxml）用来固化发布的各种参数，比如目标框架、输出目录、是否包含调试符号、部署模式（比如自包含/框架依赖）、Web项目的发布选项（比如是否删除目标目录旧文件）等。以下场景建议用：

• 发布参数复杂，不想在Pipeline命令行里写一大串参数，用配置文件更简洁易维护；
• 不同环境（开发/测试/生产）有不同的发布规则，比如生产环境不包含调试符号，测试环境保留，用不同的pubxml文件切换更方便；
• 项目有特殊的发布需求，比如WebDeploy发布到IIS、打包成特定格式，pubxml能保存这些自定义配置，避免每次手动输入。
  如果只是简单的发布（比如本地调试、基础打包），直接用命令行参数也可以，但在CI/CD里用配置文件能让Pipeline更稳定，减少参数写错的概率。

内容的提问来源于stack exchange，提问作者JonathanSK