DockerUpdateComposeVsGeneratedFiles throws "Value cannot be null" ("Parameter name: path1") after updating to Visual Studio 16.3

[frankbuckley]

This seems similar to issue #174 although parameter name is path1:

1>------ Build started: Project: docker-compose, Configuration: Debug Any CPU ------
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.Docker.targets(67,5): error : Value cannot be null.
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.Docker.targets(67,5): error : Parameter name: path1

It began after updating to VS 16.3 Preview 4 and migrating web app projects to ASP.NET Core 3.0.

Moving the Dockerfileout of the project root does fix the problem. However, should this really be necessary when upgrading?

[bwateratmsft]

Can you share your solution? In particular we'd be interested to see the Dockerfiles, docker-compose.*.yml files, and docker-compose.dcproj, along with the structure of the solution...

[frankbuckley]

Yes I could share privately.

[frankbuckley]

Having got this working (though not exactly sure how) in Preview 4, it is now back with the release of 16.3.

Solution structure:

/Solution
  Solution.sln
  docker-compose.dcproj
  docker-compose.yml
  /src
    /Project1/
      Project1.csproj
      Dockerfile
  /test

Each Dockerfile follows this template:

FROM dsegroup/aspnetcore-base:3.0.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/core/sdk:3.0.100-disco AS build
WORKDIR /w

COPY ./Solution.sln ./NuGet.config ./docker-compose.dcproj ./version.props ./

COPY build build/

COPY src/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p src/${file%.*}/ && mv $file src/${file%.*}/; done

COPY test/*/*.csproj ./
RUN for file in $(ls *.csproj); do mkdir -p test/${file%.*}/ && mv $file test/${file%.*}/; done

RUN dotnet restore ./Solution.sln

COPY ./src ./src
COPY ./test ./test

RUN dotnet build ./Solution.sln -c Release -o /b/build -v Normal

FROM build AS publish
RUN dotnet publish ./src/Project/Project.csproj -c Release -o /b/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /b/publish .
ENTRYPOINT ["dotnet", "Project.dll"]

docker-compose.yml follows this pattern:

version: '3.4'

services:
  service1:
    image: services/service1
    build:
      context: .
      dockerfile: src/Service1/Dockerfile

  service2:
    image: services/service2
    build:
      context: .
      dockerfile: src/Service2/Dockerfile

networks:
  default:
    external:
      name: my_services

docker-compose -f .\docker-compose.yml build runs successfully.

Building in Visual Studio results in:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.Docker.targets(67,5): error : Value cannot be null.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.Docker.targets(67,5): error : Parameter name: path1

[bwateratmsft]

@frankbuckley Do these csproj's use a custom output path?

[frankbuckley]

@frankbuckley Do these csproj's use a custom output path?

No

[bwateratmsft]

Rats, that was my best guess. Are you able to share the full solution so I can try it out?

[arnvanhoutte]

I have the same problem.

[frankbuckley]

Rats, that was my best guess. Are you able to share the full solution so I can try it out?

Yes - I can - can I email a zip?

[bwateratmsft]

Yes, my email is my username, except microsoft.com instead of msft, and @ instead of at. :)

[mscrivo]

similar issue here after updating from asp.net core 2.2 to 3.0, although it builds fine in VS, but using msbuild on command line I get the above errors.

[WolfspiritM]

I've the same issue. Compared to a fresh project the files "RelativeOutputAssemblyPath.Fast.cache" and "RelativeOutputAssemblyPath.Regular.cache" are not in obj/Docker. If I copy over these two files the error disappears.

I then removed the bin and obj folder from the fresh Project I created and did a rebuild and now I'm getting that error there, too. It seems like these two files are not regenerated. Even a clean and rebuild doesn't help.

As they are located in the "obj" folder they shouldn't be required but generated, right? Especially as obj usually is .gitignore'd

[WolfspiritM]

It seems like these files are generated when starting the docker-compose project but not when just building the Solution or the Project via rightclick -> Build.

What I also noticed is that when switching Debug to Release the RelativeOutputAssemblyPath.*.cache files still contain the Debug build until starting the project which then create the new files.

[bwateratmsft]

We've identified the issue, it is in the SDK so it will need to be addressed in a servicing update. As far as I know there are two possible workarounds--

• Force the RelativeOutputAssemblyPath*.cache files to be generated, by doing F5 at least once on the docker-compose project. This shouldn't be needed every session unless the source tree is cleaned, and those files are removed. These files get generated during this process, before the build, thus avoiding the issue.
• If you don't specifically need to do docker-compose debugging, you can right click and unload the docker-compose.dcproj, and debug the other projects directly.

For command line builds, if you do a release build instead of debug (i.e. /p:Configuration=Release or -c Release), it should avoid the code path causing the problem.

[mmisztal1980]

Is there an ETA on the fix? or perhaps is it posible to put a Target into the .dcproj file that could run before the build?

[bwateratmsft]

@mmisztal1980 Unfortunately a target would not be very simple to do at all. You can enable warmup or F5 the docker-compose project once and the issue should no longer occur (until you clean your source enlistment).

We have just put the fix into the 16.3 servicing branch, so it will be available in the next servicing release of 16.3 (16.3.3), as well as the next preview of 16.4 (16.4 Preview 2)

[bwateratmsft]

Now that 16.3.4 is released the fix is available. I'll close this issue. Please let us know if you still see the problem!

[ShreyasJejurkar]

Hi there, I am facing the same issue on Visual Studio version 16.4.3.

Steps to reproduce the issue:

1. Run a container with following docker command
   docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=password' -p 1433:1433 -d mcr.microsoft.com/mssql/server:2019-latest
2. Then connect to SQL Server running in docker by using SQL Server Object Explorer which is under following location in Visual Studio View -> SQL Server Object Explorer
3. The VS successfully connects to the SQL server instance, but when I try to create the database, by right-clicking on the database option then add new database option.
   

Then I get the following error message popups continuously, it just doesn't stop. Then I have to force close the VS via Task Manager.

I think its physical path issue, where VS tries to map Linux directory path to Windows directory location and at last it doesn't work, the value gets passed as null to the parameter.

I don't face this issue while using SSMS, please solve this bug under VS.

[bryanbr23]

Are there work-arounds to get this working under VS2019?
I haven't even installed SSMS, so maybe I should. Was trying to avoid that route.

I am using: Microsoft Visual Studio Enterprise 2019, Version 16.5.4, VisualStudio.16.Release/16.5.4+30011.22, Microsoft .NET Framework
Version 4.8.03752.