看起来你遇到的核心问题是：dotnet restore能成功完成，但执行dotnet build时失败，而且Restore过程中NuGet会优先尝试从你无权访问的私有Azure Artifacts源查找System.ServiceModel系列包，完全忽略了nuget.org源。结合你提供的nuget.config和项目文件，我整理了几个排查和解决方向：

1. 排查NuGet配置的合并问题 #

NuGet默认会合并多个层级的配置文件：项目目录下的配置、用户目录（%appdata%\NuGet\NuGet.Config）、系统目录（%ProgramFiles%\NuGet\Config）里的配置都会生效。你日志里出现的mycompany私有源（URL是https://pkgs.dev.azure.com/mycompany/...）并没有出现在你提供的项目级nuget.config里，说明这个源来自其他层级的配置文件。

验证当前生效的源列表 #

先运行这个命令查看所有生效的NuGet源和顺序：

dotnet nuget list source

如果发现那个mycompany源排在nuget.org前面，或者被设置为唯一可用源，就会导致NuGet优先去它那里查找包，而忽略nuget.org。

强制使用项目级配置文件 #

在执行Restore时，明确指定使用项目目录下的nuget.config，避免合并其他配置：

dotnet restore --config-file ./nuget.config

完成后再执行dotnet build，看是否能正常找到System.ServiceModel系列包。

2. 检查Package Source Mapping设置 #

如果你的环境中存在Package Source Mapping配置（通常在用户级或系统级nuget.config里），可能被错误地将System.ServiceModel.*系列包映射到了那个无权访问的私有源，导致NuGet只会去该源查找这些包，完全跳过nuget.org。

修复Package Source Mapping #

如果发现有类似这样的配置：

<packageSourceMapping>
  <packageSource key="mycompany">
    <package pattern="System.ServiceModel.*" />
  </packageSource>
</packageSourceMapping>

需要修改为将系统包映射到nuget.org，私有包映射到你的Dev源：

<packageSourceMapping>
  <!-- 系统包从nuget.org获取 -->
  <packageSource key="nuget">
    <package pattern="System.ServiceModel.*" />
    <package pattern="Dapper.StrongName" />
    <package pattern="Newtonsoft.Json" />
  </packageSource>
  <!-- 私有公司包从Dev源获取 -->
  <packageSource key="Dev">
    <package pattern="CommonDatabase.*" />
    <package pattern="CryptographyTools.*" />
    <package pattern="MyCompanyLog.*" />
  </packageSource>
</packageSourceMapping>

这样NuGet就能精准地到对应源查找指定包，不会再去私有源找系统组件。

3. 确认Restore的包缓存状态 #

有时候Restore虽然返回成功，但部分包可能因为源访问问题没有正确下载到本地缓存。可以尝试清理本地NuGet缓存后重新Restore：

dotnet nuget locals all --clear
dotnet restore --config-file ./nuget.config

总结 #

你的问题大概率是多层级NuGet配置合并导致的源优先级问题，或者Package Source Mapping的错误映射。先通过dotnet nuget list source确认实际生效的源，再强制使用项目级配置文件测试，应该就能定位并解决问题。

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