项目从.NET5.0 升级到 8.0，加起来 1.5 万行代码， Linux 下编译经常要半个小时，有的时候又几秒钟就能编译完， Windows 下一直非常正常，怎么排查？

[drymonfidelia]

服务器是 aws m8g.2xlarge 8 核 32GB 内存
整个服务器上就一个 Docker ，里面运行这个服务
以前 .NET 5 的都是秒编译
现在经常要半个小时，有时甚至五六个小时编译不完
有时候又能 2 秒编译，不知道为什么
`docker system prune -a` 运行了好几遍，没效果



开 Debug 是因为刚才想试试是不是 Release 导致的编译缓慢才改的，并不是导致问题的原因

[w568w]

@jstony 微软改名部

[cenbiq]

@nmap .net fx （~2016 ） > .net core （ 2016~2020 ） > .net （ 2020~）

[drymonfidelia]

@netnr 你看我的 log ，restore 和 build 是完全分开的，restore 最多 50 秒 我用的是 aws ，应该不存在网络不稳定

[liuliuliuliu]

@nmap 2025 年了还能有人问出这个问题……

[netnr]

build 会内部调用 restore ，你可以创建一个空项目，无任何依赖打包，对比一下

[drymonfidelia]

@billbob
@qW7bo2FbzbC0 我帖子正文第一句就是用的是 aws 啊，美国的服务器
@netnr 无依赖空项目确实编译很快，但这不能排除依赖的问题，因为代码也没了

[mayli]

编译半小时肯定不正常，才 15k 代码，盲猜网络问题，可能是 dns?
编译的时候看下 ps, top 和 log, 应该比较容易看出是哪里卡住

[nivalxer]

nuget 的网络问题，在 build 阶段还是会走一次还原包。可以尝试加上 nuget 缓存看看：
restore 、build 阶段都可以加
例如：
RUN --mount=type=cache,id=nuget,target=/root/.nuget/packages dotnet publish "xxxxx.csproj" -c Release -o /app/publish

[nivalxer]

补充一下：如果是想最终打包为镜像发布，可以直接用 publish

[hez2010]

@drymonfidelia 不应该，按理来说应该是会出现性能数据总结的
换成 /clp:PerformanceSummary /tl:false 试试呢？

[niubiman]

@tusj 这两个问题完全不是什么问题

[niubiman]

@nmap 互联网这么发达了, 为什么信息差还是这么严重, 令人匪夷所思

[tusj]

@niubiman 我举例微软 IDE 和 dotnet7 的例子是想说，微软总是在匪夷所思的地方，搞出莫明其妙的问题！令人失望。
这种例子多得很：windows terminal 上 git version 卡死。装了微软电脑管家之后，打开 git bash 有时要 10 秒以上，匪夷所思！
什么信息差，这几个问题你倒是解释解释？

[niubiman]

@tusj #33 我回的是 "现在.net 还能开发 linux 的应用了？" 这句话

[ximi522]

感觉可能是你的 nuget 包下载到了 linux 的 temp 目录里，然后被定期删掉了，就需要重新下载，windows 不会有这种问题。可以看看这个思路。