dotnet CLI指定StartupObject与修改CSPROJ行为差异问题咨询

这是MSBuild增量构建机制下的预期行为，不属于功能bug。

MSBuild默认启用增量构建来提升编译速度，判断是否需要重新编译的核心逻辑是：对比磁盘上持久化存储的所有构建输入项（源码、项目文件、引用资源等）的最后修改时间和输出程序集的最后修改时间，如果所有输入都比输出旧，就直接复用已有编译产物，不重复编译。

两种StartupObject配置的生效差异，核心在于配置是否会被增量构建的依赖检查捕获：

• 直接在CSPROJ文件中配置StartupObject时，CSPROJ本身是MSBuild的核心输入文件，只要修改保存，文件的修改时间就会更新，MSBuild能立刻检测到输入变化，自动触发重编译，所以不需要手动清理就能加载新的入口点配置。
• 通过dotnet run -p:StartupObject=XXX命令行传参时，这个属性是命令执行时临时传入的全局属性，不会修改磁盘上的任何项目文件，也不会被记录到构建依赖的校验清单里。第一次传StartupObject=First编译完成后，输出目录已经生成了入口为First的程序集；第二次改传StartupObject=Second时，MSBuild扫描所有磁盘上的输入文件，发现没有任何文件发生过修改，就会判定不需要重编译，直接拿上次生成的旧程序集运行，自然输出的还是First的结果。

执行dotnet clean会把所有历史编译生成的中间文件、最终输出程序集全部删除，后续再运行时，MSBuild找不到可复用的编译产物，就会触发全量编译，使用本次命令传入的StartupObject参数生成对应入口点的程序集，所以能得到预期的Second输出。

如果需要频繁通过命令行切换入口点，没必要每次手动执行clean，只要在命令中加上--no-incremental参数，就能强制跳过增量构建逻辑，每次都全量编译运行，示例命令：

dotnet run --project=test_multiple_entry -p:StartupObject=Second --no-incremental

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