Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
frankbuckley opened this issue Sep 18, 2019 · 16 comments

Comments

@frankbuckley
Copy link

frankbuckley commented Sep 18, 2019

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

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Sep 18, 2019

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

This comment has been minimized.

Copy link
Author

frankbuckley commented Sep 18, 2019

Yes I could share privately.

@frankbuckley

This comment has been minimized.

Copy link
Author

frankbuckley commented Sep 23, 2019

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
@frankbuckley frankbuckley changed the title DockerUpdateComposeVsGeneratedFiles throws "Value cannot be null" ("Parameter name: path1") after updating to VS 16.3 Preview 4 DockerUpdateComposeVsGeneratedFiles throws "Value cannot be null" ("Parameter name: path1") after updating to Visual Studio 16.3 Sep 23, 2019
@bwateratmsft

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Sep 24, 2019

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

@frankbuckley

This comment has been minimized.

Copy link
Author

frankbuckley commented Sep 24, 2019

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

No

@bwateratmsft

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Sep 24, 2019

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

@arnvanhoutte

This comment has been minimized.

Copy link

arnvanhoutte commented Sep 24, 2019

I have the same problem.

@frankbuckley

This comment has been minimized.

Copy link
Author

frankbuckley commented Sep 26, 2019

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

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Sep 26, 2019

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

@mscrivo

This comment has been minimized.

Copy link

mscrivo commented Sep 26, 2019

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

This comment has been minimized.

Copy link

WolfspiritM commented Sep 27, 2019

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

This comment has been minimized.

Copy link

WolfspiritM commented Sep 27, 2019

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

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Sep 27, 2019

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

This comment has been minimized.

Copy link

mmisztal1980 commented Oct 3, 2019

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

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Oct 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

bwateratmsft commented Oct 15, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.