Home: file '<source folder>/obj/project.assets.json' already exists (dotnet restore on docker)

Created on 31 Jan 2020  路  13Comments  路  Source: NuGet/Home

Details about Problem

/usr/share/dotnet/sdk/2.2.207/NuGet.targets(119,5): error : The file '/app/.nupkg/system.numerics.vectors/4.4.0/system.numerics.vectors.nuspec' already exists.

NuGet product used: dotnet restore
NuGet version (x.x.x.xxx): not sure how to check nuget version
dotnet.exe --version: 2.2.207
OS version (i.e. win10 v1607 (14393.321)): win10 19551 pro
SDK Docker image: mcr.microsoft.com/dotnet/core/sdk:2.2-alpine
Docker version 19.03.5, build 633a0ea

Detailed repro steps so we can see the same problem

Mount app in docker image mcr.microsoft.com/dotnet/core/sdk:2.2-alpine and run restore

dotnet restore ./MyApp --packages .nupkg --runtime linux-musl-x64

Running the dotnet from windows directly does not cause issues.
Tested with dotnet sdk image 3.1 as well, same results.
Nuget package does not matter, it can happen with any package.

Verbose Logs

https://filebin.net/p2csdej08vp8ln1b/logs.txt?t=suthfyn8

Docker External

Most helpful comment

It is happening for me as well. I assumed it was Windows Defender but after disabling it, it still happens. This happens when I restore to a volume, mounted on the container.

For me it complains randomly for system.xml.xmlserializer/4.0.11/system.xml.xmlserializer.nuspec or system.xml.xmlserializer/4.3.0/system.xml.xmlserializer.nuspec.

All 13 comments

It is happening for me as well. I assumed it was Windows Defender but after disabling it, it still happens. This happens when I restore to a volume, mounted on the container.

For me it complains randomly for system.xml.xmlserializer/4.0.11/system.xml.xmlserializer.nuspec or system.xml.xmlserializer/4.3.0/system.xml.xmlserializer.nuspec.

+1 happens for me as well. As soon as I use compose's volumes key in any service that dotnet restore is run in, it complains that

The file '<source folder>/obj/project.assets.json'  already exists

Issue seems to be docker for windows and not nuget. I do not have a proof yet but have a feeling nuget is a red herring here.

Thanks @aliostad , that solved it for me. Downgraded from 2.2.0.3 to 2.1.0.5 and the issue is gone.

Download links to older versions can be found in the release notes:
https://docs.docker.com/docker-for-windows/release-notes/#docker-desktop-community-2105

I do not see how the docker desktop is affecting this, or is the docker desktop downgrade also downgrading the docker version? @Xcone what is your docker --version

It broke after upgrading my docker for Windows although realised it now. It works on a colleagues machine with older Docker for Windows. It is funny that they have the same Docker Engine (19.03.5) but different Compose - and that is killing it.

I'm pretty sure this is fixed by the just-released Docker for Desktop version 2.2.1.0 https://docs.docker.com/docker-for-windows/edge-release-notes/ (look at the fixed issues)

I'll test this now

I upgraded, not solved yet :/

Alright, I fixed my case with the help of this excellent blog article:

https://natemcmaster.com/blog/2018/05/12/dotnet-watch-2.1/

I added the Directory.Build.props file in my solutions root directory and made sure that, if using volumes, only the projects I need are copied.

So, instead of

app:
    volumes:
        - ./src:/app/src # mapping the whole solution
app:
    volumes:
        # mapping each individual project (not that big of a deal)
        - ./src/MyApp.Api:/app/src/MyApp.Api
        - ./src/MyApp.Services:/app/src/MyApp.Services
        - ./src/MyApp.Data:/app/src/MyApp.Data
        - ./src/MyApp.Common:/app/src/MyApp.Common

I don't know if this will work for everyone however, since some of you seem to be getting errors inconsistently (It always was the same file that caused troubles for me)

Unfortunately I had no proper solution for this yet. What I have done is disabled the cache for local WSL development: $$(which wsl.exe > /dev/null || echo '--packages .nupkg')

Hey all,

This is a docker permission issue.
The process running in the container does not have the rights to overwrite files like the assets file or any other NuGet caches in the obj folder.

NuGet is really the red herring here.

When creating your imagine ensure that you are not copying the obj artifacts.

Thanks @Xcone, I also downgraded from 2.2.0.5 to 2.1.0.5 and the issue is gone. 馃憤 馃挴

Was this page helpful?
0 / 5 - 0 ratings