Docker build抱怨找不到nuget fallback包文件夹

时间:2018-08-31 10:49:30

标签: docker .net-core nuget

我正在按照https://docs.microsoft.com/en-us/dotnet/core/docker/docker-basics-dotnet-core#dockerize-the-net-core-application上的教程学习如何将.net核心应用程序容器化为Docker。

除了将Dockerfile指向microsoft/dotnet:2.1-sdk作为基本图像,并添加RUN dotnet --info行以获取版本/环境信息以外,其他所有内容都是相同的。但是,在dotnet publish步骤上出现错误:

Step 7/8 : RUN dotnet publish -c Release -o out
 ---> Running in 6739267c7581
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 34.46 ms for /app/Hello.csproj.
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018: The "ResolvePackageAssets" task failed unexpectedly. [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Program Files\dotnet\sdk\NuGetFallbackFolder'. [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at NuGet.Packaging.FallbackPackagePathResolver..ctor(String userPackageFolder, IEnumerable`1 fallbackPackageFolders) [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(LockFile lockFile, String projectPath) [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task, Stream stream) [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAssets task, Byte[] settingsHash) [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task) [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups() [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore() [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() [/app/Hello.csproj]
/usr/share/dotnet/sdk/2.1.401/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(198,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask) [/app/Hello.csproj]
The command '/bin/sh -c dotnet publish -c Release -o out' returned a non-zero code: 1

到目前为止,我在该主题上唯一能找到的是一些github问题,要求在膨胀容器时将fallback文件夹丢弃在Docker中。在这个阶段,我不太担心膨胀,我只是希望它构建一个hello world应用程序。


如果有帮助,dotnet --info命令返回以下内容:

Step 3/8 : RUN dotnet --info
 ---> Running in 17dad2f04a7e
.NET Core SDK (reflecting any global.json):
 Version:   2.1.401
 Commit:    91b1c13032

Runtime Environment:
 OS Name:     debian
 OS Version:  9
 OS Platform: Linux
 RID:         debian.9-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.401/

Host (useful for support):
  Version: 2.1.3
  Commit:  124038c13e

.NET Core SDKs installed:
  2.1.401 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.3 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

5 个答案:

答案 0 :(得分:3)

如果您的Docker容器是Linux家族的,请将此标记-r linux-x64添加到publish命令,该标记应涵盖“(大多数桌面发行版,如CentOS,Debian,Fedora,Ubuntu和衍生产品)”的构建;因此,发布命令应如下所示:RUN dotnet publish -r linux-x64 -c Release -o out 有关其他RID,请参考此https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

答案 1 :(得分:1)

这可能是由于打开项目时Visual Studio生成的obj\project.assests.json文件所致。如果您在其中查找,则会在Windows系统中找到对NuGet软件包文件夹的引用。

例如

"packageFolders": {
  "C:\\Users\\<UserName>\\.nuget\\packages\\": {},
  "C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder": {}
},

一个简单的解决方法是在Dockerfile中添加一个步骤,以删除binobj文件,然后再运行任何还原,构建或测试步骤。一种方法是利用find程序:

find -type d -name bin -prune -exec rm -rf {} \; && find -type d -name obj -prune -exec rm -rf {} \;

以您链接到的教程中的Dockerfile为例,它看起来像这样:

FROM microsoft/dotnet:2.1-sdk
WORKDIR /app

# copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore

# copy and build everything else
COPY . ./
RUN find -type d -name bin -prune -exec rm -rf {} \; && find -type d -name obj -prune -exec rm -rf {} \;
RUN dotnet publish -c Release -o out
ENTRYPOINT ["dotnet", "out/Hello.dll"]

答案 2 :(得分:1)

您可以添加一个 .dockerignore 文件,以便在使用 docker 构建映像时忽略本地创建的任何 obj 目录,例如把它放在 .dockerignore 中。这对我有用。

*/obj/*

答案 3 :(得分:0)

问题是您的bin和obj目录中有一些挥之不去的文件,您无需从源代码构建应用程序。因此,我认为最好的解决方案是将bin和obj目录添加到.dockerignore文件中,这将阻止这些文件夹复制到您的Docker上下文中,从而带来较小的性能提升。这是dotnet应用程序的.dockerignore文件的样子:

.dockerignore
.env
.git
.gitignore
.vs
.vscode
docker-compose.yml
docker-compose.*.yml
**/bin
**/obj
bin/
obj/

答案 4 :(得分:0)

就我而言,在检查了所有这些响应后,问题仍然存在之后,唯一的解决方案是重新启动Docker桌面。