.NET Core 1.1 Docker容器加载System.ComponentModel.TypeConverter异常求助

这个问题我在处理早期.NET Core容器化部署时也踩过坑，核心是.NET Core 1.x的依赖加载逻辑在容器环境下，误把仅用于编译的引用程序集当成了运行时需要执行的程序集，给你几个实用的解决方向：

1. 调整项目依赖的私有资产配置 #

检查你的项目文件（.csproj），如果直接引用了System.ComponentModel.TypeConverter包，给它加上PrivateAssets="all"属性，告诉MSBuild这个包只用于编译阶段，不需要复制到发布目录：

<PackageReference Include="System.ComponentModel.TypeConverter" Version="4.3.0">
  <PrivateAssets>all</PrivateAssets>
</PackageReference>

这样发布时就不会把这个引用程序集打包到输出文件夹，从根源避免运行时加载冲突。

2. 改用自包含部署（SCD）模式 #

.NET Core 1.x的框架依赖部署（FDD）在容器环境下容易和基础镜像的系统依赖产生冲突，改用自包含部署可以把所有需要的运行时组件都打包到发布包中：
修改Dockerfile里的发布命令，指定目标运行时并开启自包含：

RUN dotnet publish -c Release -r linux-x64 --self-contained true -o /app

同时基础镜像要对应使用runtime镜像，比如microsoft/dotnet:1.1-runtime-linux-x64，确保运行环境和打包的依赖完全匹配。

3. 手动排除发布目录中的引用程序集 #

如果确认这个dll只是编译依赖，运行时完全用不到，可以在项目文件里配置排除它：

<ItemGroup>
  <Content Remove="System.ComponentModel.TypeConverter.dll" />
</ItemGroup>

或者在Dockerfile的发布步骤后添加删除命令：

RUN rm /app/System.ComponentModel.TypeConverter.dll

⚠️ 注意：这个方法要先确认项目运行时真的不需要该组件，否则会引发新的缺失异常。

额外建议 #

.NET Core 1.x已经停止官方维护多年，容器化支持本身就有不少局限性，如果业务允许，建议升级到.NET Core 3.1（长期支持版）或更高版本，这类依赖加载问题会大幅减少，同时安全性和性能也会提升。

内容的提问来源于stack exchange，提问作者Bui Quang Huy