我在openshift上运行dotnet core 2.2 Web api,我有一个api方法返回FileResult。该文件是使用epplus生成的。但是,在对应用程序进行容器化之后,端点将返回以下错误。如果使用system.drawing库,我相信会发生此异常,但是我没有使用任何system.drawing功能。
System.TypeInitializationException:'Gdip'的类型初始值设定项引发了异常。 ---> System.DllNotFoundException:无法加载DLL'libgdiplus':找不到指定的模块。
public async Task<FileResult> GetPSACostCaseAndFeedData([FromQuery] int caseId, [FromQuery] int proposalId, [FromQuery] int equipmentId)
{
try
{
var queryParams = new Dictionary<string, string> { { "caseId", caseId.ToString() }, { "proposalId", proposalId.ToString() }, { "equipmentId", equipmentId.ToString() } };
var restObj = _restFactory.createRestRequest(Method.GET, "ProposalService/PSACostData/GetPSACostCaseAndFeedData", queryParams);
Console.WriteLine("Base URL - " + restObj.Item2.BaseUrl);
var response = await restObj.Item2.ExecuteTaskAsync(restObj.Item1);
if (response.StatusCode == HttpStatusCode.OK)
{
var result = JsonConvert.DeserializeObject<PSACostCaseDetailsResponse>(response.Content);
Console.WriteLine("result -" + response.Content.ToString());
Console.WriteLine("start writing file");
var excelPackage = await _iPSACostExcelHelper.PopulatePsaCostFile(result, Path.Combine(_hostingEnvironment.ContentRootPath, "App_data", "PSACOST_V9.2.2.xlsm"));
Console.WriteLine("finished writing file");
return await Task.FromResult(File(_excelHelper.ConvertWorkBookToByteArray(excelPackage), ContentTypeEnums.excel, result.customerInformationModel.ProposalNum + "_" + result.caseDataModel.CaseNm + ".xlsm"));
}
throw new Exception("There is no PSA cost data for this case");
}
“完成的写入文件”行确实被打印到标准输出,此后的行失败。有人可以帮我了解这里出了什么问题吗?为什么返回FileResult类型的方法需要system.drawing?
下面也是我的dockerfile。
FROM mcr.microsoft.com/dotnet/core/aspnet:2.2.7-alpine3.10
LABEL pipelineName="PSACOST.API" \
pipelineKey="UMAOKJOH" \
offeringKey="KKWEECBH"
RUN apk upgrade -U
EXPOSE 5000
ENV ASPNETCORE_URLS=http://*:5000
WORKDIR /app
COPY . /app
USER guest
ENTRYPOINT ["dotnet", "PSACOST.API.Web.dll"]
[在从生成QR码的库中使用System.Drawing时遇到类似的情况。
问题似乎是DotNet Core docker映像,sdk或运行时没有libgdiplus
。对于Linux而言,这不是问题,因为您可以在容器中执行类似apt-get install -y libgdiplus
的操作,或者使用DotNetCore运行时映像加上此libgdiplus
来构建应用程序Docker映像。
这是一个令人讨厌的问题。我不确定是否有任何解决方案不需要弄乱官方docker映像,但到目前为止还没有运气。
目前,我可以看到一些解决方案选项。
选项A:如果您正在使用用于Linux的Docker DotNetCore映像,那么似乎应该使用apt安装缺少的运行时依赖项,例如libgdiplus
,因为它们不属于docker映像。
选项B:找到一个具有所有这些依赖关系的好的Docker DotNetCore映像(SDK或运行时)
选项C:查找一个不依赖epplus
的System.Drawing
的不同于libgdiplus
的库。但我什至不知道是否可能