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

error CTC1030: Parameter name: path2 #430

Open
DaveBubenik opened this issue Jun 6, 2024 · 18 comments
Open

error CTC1030: Parameter name: path2 #430

DaveBubenik opened this issue Jun 6, 2024 · 18 comments
Assignees
Labels
Fixed - Pending Release under investigation workaround-available Apply this label when there is an easy workaround available.

Comments

@DaveBubenik
Copy link

I'm seeing this error when building in Azure DevOps on Microsoft Hosted Agents. I don't see the error when I build locally on Visual Studio Pro Version 17.10.1.

Azure DevOps uses an agent with the following configuration:
https://github.com/actions/runner-images/blob/win22/20240603.1/images/windows/Windows2022-Readme.md

Here is the full error:

##[error]C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(329,5): Error CTC1030: Value cannot be null.
Parameter name: path2
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(329,5): error CTC1030: Value cannot be null. [D:\a\1\s\MyProject\src\LocalDevOnly\docker-compose.dcproj]
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(329,5): error CTC1030: Parameter name: path2 [D:\a\1\s\MyProject\src\LocalDevOnly\docker-compose.dcproj]
Done Building Project "D:\a\1\s\MyProject\src\LocalDevOnly\docker-compose.dcproj" (default targets) -- FAILED.
@mynpmpackage
Copy link

mynpmpackage commented Jun 6, 2024

I have been facing the same issue for the last 3 days,. I started seeing this issue after upgrading from .net 6.0 to .net 8

I am also seeing this error in Azure DevOps and not when building locally. Azure DevOps uses an agent Windows Server 2019

@DaveBubenik
Copy link
Author

DaveBubenik commented Jun 10, 2024

I was able reproduce this with a minimal example:

  1. Create a Blazor Project
  2. Add Docker Support
  3. Add Docker Compose Orchestration
  4. Create a minimal Azure DevOps build script

I've attached a project using the above sequence. The Azure build pipeline file is azure-pipelines.yml.
BlazorApp.zip

Can anyone give any insight on what "path2" is?

@dbreshears
Copy link
Member

@DaveBubenik , @mynpmpackage , We are investigating this and will update when we have more info.

@DaveBubenik
Copy link
Author

@dbreshears Thanks!

Just wanted to let you know I also opened a bug with runner-images:
actions/runner-images#10031

Not sure who is responsible for a fix

@NCarlsonMSFT
Copy link
Member

@DaveBubenik we suspect we know what caused the regression but are struggling to get a local repo to validate the fix.
In the meantime, we were able to work around the issue in our repro build by explicitly using the x64 version of msbuild. To do this add msbuildArchitecture: 'x64' to your VSBuild task in the build definition.

@NCarlsonMSFT NCarlsonMSFT added the workaround-available Apply this label when there is an easy workaround available. label Jun 11, 2024
@robal
Copy link

robal commented Jun 11, 2024

Hitting the same problem.
Confirmed broken in VS 17.10.1
Confirmed working in VS 17.9.x
It's actually 'Clean' that fails on docker-compose project.
It only fails when running MSBuild in console (works ok in VS GUI)

@DaveBubenik
Copy link
Author

@NCarlsonMSFT I tried your workaround, but now the project is complaining that I'm trying to build Linux containers on a host configured for Windows containers.

I realize trying to build in this configuration may seem odd, but we're attempting to run Unit Tests and Vulnerability scans on the original project. So we use a Windows agent to perform this task. Looking at older build pipelines outputs I can see that the project was being built, but I'm not sure if the actual container images are being created.

We don't actually use the container images from the docker compose for the build pipeline job. So I was able to keep things running by creating a project configuration that doesn't build the compose project.

But it would be nice to not have a separate configuration for my build pipelines.

@NCarlsonMSFT
Copy link
Member

@robal can you try the workaround for specifying msbuildArchitecture: 'x64' on the VSBuild task?

@DaveBubenik I must admit that configuring the default windows build agent to build linux containers is outside my area of expertise. Doing some quick research the general recommendation appears to be to create a custom build agent configured to meet your needs. Personally, I would create a VM Scale set agent with a base image that has the VS Build SKU installed and Docker Desktop (Depending on your licensing, you may need to use Docker CE in WSL #417). The major downside to this approach is that you will be responsible for updating your base image.

@robal
Copy link

robal commented Jun 11, 2024

@NCarlsonMSFT msbuildArchitecture: 'x64' workaround doesn't seem to work in my case

@NCarlsonMSFT
Copy link
Member

@robal What error are you getting when using the x64 msbuild?
Is this failing locally from the command line or only on the build server?

@NCarlsonMSFT
Copy link
Member

@mynpmpackage are you intending to build linux containers as well? What error are you getting? It could be that you were accidentally building windows containers when targeting .NET 6. There was a change in .NET 8 that the windows images now require a specific tag (details: https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/multi-platform-tags)

@AndreyBespamyatnov
Copy link

The workaround helped me

@denmaklucky
Copy link

The workaround helped me as well. We used the following instruction to set up our build.

@sgutbaplicada
Copy link

Hi, any news regarding the issue @DaveBubenik reported?

@pinglev
Copy link

pinglev commented Jun 17, 2024

This has been affecting us as well. I am sure this is a wider implication than people are reporting as we see more and more people upgrading to latest versions. Any updates are greatly appreciated. For now the only solution seems to be removing the docker-compose from our debug build to move on. And the only reason we are able to move on is that we only use the docker-compose for local dev environment.

@DaveBubenik
Copy link
Author

Just an update to anyone reading this thread, I also opened a bug in the runner-images repo:
actions/runner-images#10031

They basically said that I needed to convert all of my docker images to use Windows containers. This isn't possible for my project because we rely on a few Linux packages for our containers.

My guess is that things used to work because the VSBuild task used to skip building the images in the docker-compose project. Someone noticed this and "fixed" it.

If you are still searching for a solution and you don't care about the containers that are generated when using VSBuild, this is what you need to do:

  1. Add a special build configuration to your sln that skips building the docker compose project
  2. Update the pipeline script to use the new configuration
  3. Spend the rest of your life maintaining the new build configuration.

Something to note when following the above steps, it's not necessary to use the msbuildArchitecture: 'x64' fix that is recommended in the other comments because the solution is being updated to omit the project from the build.

Here is an updated version of my sample project that makes things work again:
BlazorApp.zip

@NCarlsonMSFT
Copy link
Member

We've opened a work item on our backlog to add an MSBuildProperty for disabling image build to make a more maintainable work-around.

@NCarlsonMSFT
Copy link
Member

In the 17.12 previews we've added an msbuild property for dcproj DockerComposeBuildEnabled. If you set that to false the dcproj will not build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed - Pending Release under investigation workaround-available Apply this label when there is an easy workaround available.
Projects
None yet
Development

No branches or pull requests

9 participants