AspNetCore项目仅在Linux容器中抛出System.IO.FileNotFoundException

这种跨Windows和Docker容器的依赖加载问题我之前踩过不少坑，结合你的场景，咱们一步步排查解决：

核心原因推测 #

首先得明确：Windows文件系统是大小写不敏感的，但Docker容器底层基于Linux，是严格区分大小写的。你提到的Koldata.dll在Windows下不管大小写都能被正确识别，但在容器里如果实际文件名和代码中引用的大小写不匹配（比如代码写的是Koldata.dll，容器里是koldata.dll），就会触发找不到文件的错误——尤其是PUT请求可能触发了某个特定的依赖加载分支，刚好命中这个大小写问题。

另外，直接复制Windows本地构建的产物到容器，可能存在跨平台依赖不兼容、复制不完整的情况。

具体解决方案 #

1. 先确认文件名大小写一致性 #

• 登录到运行中的Docker容器，查看目标目录下的文件实际大小写：

  docker exec -it <你的容器ID> /bin/bash
  cd /path/to/your/project/bin/Debug/netcoreapp1.1
  ls -l
  

• 如果容器里的文件名和代码中引用的大小写不一致，要么统一Git仓库里的文件名大小写（推荐，从根源解决跨环境问题），要么修改代码中的依赖引用路径为匹配容器的大小写。

2. 验证Docker构建时的依赖复制逻辑 #

• 检查你的Dockerfile，确保COPY指令正确覆盖了类库DLL所在目录：

  # 复制整个项目目录到容器（根据你的实际路径调整）
  COPY . /app
  WORKDIR /app
  

• 或者可以显式指定复制类库文件：

  COPY ./path/to/Koldata.dll /app/bin/Debug/netcoreapp1.1/
  

• 同时，在容器内重新执行构建命令，确保依赖被正确恢复和复制：

  dotnet restore
  dotnet build
  

3. 改用容器内直接构建，避免跨平台产物干扰 #

直接复制Windows本地构建的bin/Debug到容器，很容易出现平台兼容问题。建议用多阶段构建让容器自行生成适配Linux环境的依赖：

# 第一阶段：用build镜像构建项目
FROM microsoft/aspnetcore-build:1.0.7 AS build
WORKDIR /src
COPY YourProject.csproj .
RUN dotnet restore
COPY . .
RUN dotnet build -c Debug -o /app

# 第二阶段：用runtime镜像运行项目
FROM microsoft/aspnetcore:1.1
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "YourProject.dll"]

这样构建出来的镜像完全基于容器环境生成依赖，从根源避免跨平台差异。

4. 启用详细日志排查加载路径 #

如果前面的方法都没解决，可以在容器内启用.NET Core的加载日志，查看具体加载路径：

export COREHOST_TRACE=1
dotnet run

通过日志可以看到.NET Core尝试加载Koldata.dll的具体路径，确认是否指向正确位置，以及路径中的大小写是否匹配。

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