如何修复Azure Pipeline中的NETSDK1152错误及发布阶段重复文件名导致的构建失败问题

我之前也碰到过一模一样的问题，刚好能帮到你！这个NETSDK1152错误其实是.NET SDK 5.0及以后版本新增的严格检查机制——之前的版本允许输出目录里存在同名但不同路径的文件，但为了防止发布时文件被意外覆盖，新版本直接把这个当成错误拦截了，这也解释了为啥之前Pipeline能正常跑，现在突然失败。下面是几个靠谱的修复方案，按推荐程度排序：

1. 重命名重复文件（最推荐的根治方案） #

• 直接给项目里重复的文件名加上区分性的标识，比如把两个Helper.cs分别改成OrderHelper.cs和UserAuthHelper.cs。这样从根源上解决文件名冲突，还能让代码结构更清晰，后续维护的时候也不会搞混不同文件的作用。

2. 通过项目文件配置规避检查 #

如果暂时没法重命名文件（比如涉及大量代码改动），可以在对应的.csproj文件里加配置来处理：

方式A：排除重复文件的发布输出 #

把其中一个重复文件从发布内容里移除，改成仅作为项目内的代码文件：

<ItemGroup>
  <!-- 替换成你自己的重复文件路径 -->
  <Content Remove="Services/Helper.cs" />
  <None Include="Services/Helper.cs" />
</ItemGroup>

方式B：临时禁用重复文件检查（不推荐长期用） #

如果只是临时要让Pipeline跑通，可以添加属性关闭这个错误检查，但要注意这会掩盖潜在的文件覆盖风险：

<PropertyGroup>
  <ErrorOnDuplicatePublishOutputFiles>false</ErrorOnDuplicatePublishOutputFiles>
</PropertyGroup>

3. 调整Pipeline的发布命令参数 #

检查一下你Pipeline里的dotnet publish命令，是不是不小心把多个项目的输出目录设成了同一个？如果是这种情况，改成每个项目单独发布到不同子目录就行：

dotnet publish src/OrderService/OrderService.csproj -o $(Build.ArtifactStagingDirectory)/orderservice
dotnet publish src/UserService/UserService.csproj -o $(Build.ArtifactStagingDirectory)/userservice

额外排查小提示 #

• 先确认下Pipeline代理的.NET SDK版本是不是最近升级了——如果从5.0以下升到了5.0+，就会触发这个新检查，这大概率是问题的导火索。
• 翻一下最近的代码提交，看看是不是新增了项目或者文件，不小心引入了同名的文件。

最后再啰嗦一句，临时禁用检查只是权宜之计，长期来看还是重命名文件最稳妥，不然以后发布时真的出现文件覆盖，排查问题会更头疼。

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