error CTC1030: Parameter name: path2

[DaveBubenik]

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]

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]

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]

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

[DaveBubenik]

@dbreshears Thanks!

Just wanted to let you know I also opened a bug with runner-images: https://github.com/actions/runner-images/issues/10031

Not sure who is responsible for a fix

[NCarlsonMSFT]

@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.

[robal]

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]

@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]

@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]

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

[NCarlsonMSFT]

@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]

@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]

The workaround helped me

[denmaklucky]

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

[sgutbaplicada]

Hi, any news regarding the issue @DaveBubenik reported?

[pinglev]

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]

Just an update to anyone reading this thread, I also opened a bug in the runner-images repo: https://github.com/actions/runner-images/issues/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]

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