MSBuild version 17.4.0 getting CS2012 files in use by another process errors

[mwmccallum]

DevOps on premise server with update of VS2022 to 17.4 no longer builds existing solutions that have multiple projects, including test projects. These are Windows Build Agents both running on the DevOps and on a Docker Server that is running multiple ServerCore build agents. These were all updated to latest buildtools to get 17.4 functionality.

Same solution built fine on Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET, and if I take same solution and build on Ubuntu agent, it builds with no issues using MSBuild version 17.3.2+561848881 for .NET.

It appears like the main project and test project may be building the main project at the same time in parallel. By default it is not supposed to be running parallel builds according to documentation.

  -maxCpuCount[:n]   Specifies the maximum number of concurrent processes to
                     build with. If the switch is not used, the default
                     value used is 1. If the switch is used without a value
                     MSBuild will use up to the number of processors on the
                     computer. (Short form: -m[:n])

Build Command: dotnet.exe build FullPathToSolutionFile.sln --configuration Release --no-restore --self-contained false

Solution has one project and one xUnit test project in net6.0. the xUnit has a project reference to the main project.

Build error: Error CS2012: Cannot open because it is being used by another process.

[mwmccallum]

Rolled back VS 2022 17.4 on DevOps server, removed the Dotnet 7.0 SDK folder [C:\Program Files\dotnet\sdk]. Installed 6.0.403 SDK. Rebooted server. Same solution noted above builds without issues using: MSBuild version 17.3.2+561848881 for .NET.

Now my struggle on my Docker agents is to rebuild the images with changes to my Dockerfile that would get me a 17.3.2 build tools.

My Dockerfile is based on this: https://learn.microsoft.com/en-us/visualstudio/install/advanced-build-tools-container?view=vs-2022. I would need version specific settings for the following items from my Dockerfile:

# Use the latest release channel. For more control, specify the location of an internal layout.
ARG CHANNEL_URL=https://aka.ms/vs/17/release/channel
ADD ${CHANNEL_URL} C:\Central\VisualStudio.chman

    # Download the Build Tools bootstrapper.
    curl -SL --output vs_buildtools.exe https://aka.ms/vs/17/release/vs_buildtools.exe `

Any help to request 17.3.2 versions of vs_buildtools.exe in the interim would be greatly appreciated!

Thanks, Mike

[woodmeister]

Seen here as well

[rainersigwald]

By default it is not supposed to be running parallel builds according to documentation.

The default is for MSBuild.exe, but dotnet build is parallel by default. @baronfel we should probably clarify the docs on this.

That's not new, though, so it's not the problem here.

The problem here is a new race condition in the build when specifying --self-contained for a solution file. This was introduced in #6924. The flow is now:

graph TD
subgraph Library[Race between these]
Library1
Library2
end
sln[sln<br/>SelfContained=false] -->|direct| Library1[Library<br/>SelfContained=false]
sln -->|direct| Test[Library<br/>SelfContained=false]
Test -->|ProjectReference| Library2[Library<br/>SelfContained=]

To work around this, don't specify --self-contained for solution builds.

cc @dsplaisted

[mwmccallum]

Changing the Build step and removing "--self-contained $false" did resolve this issue. Thanks, Mike

[rainersigwald]

Glad to hear it! I'm going to reopen this because it'd be nice if we could keep it from happening.

[dsplaisted]

We had talked about having the solution metaproj handle the project reference protocol to each project in the solution. That would be complicated to implement but I'm not sure there's any other solution.

@rainersigwald What do you think?

@nagilson FYI, I was thinking this might be something you could tackle. Note that it is not small though :-)

[dungnh7]

Changing the Build step and removing "--self-contained $false" did resolve this issue. Thanks, Mike

This help me

[ekgurney14]

Getting same error with no self-contained in my parameters... publish xxxx.csproj /p:m=4 /p:nr=false -c Release --runtime win-x86 --output D:\Publish\Publish\DownloadApplication\win-x86 -v q without the m:4 and nr:false I am getting this error just trying to do builds too.

Can I use an older version of MsBuild with Net7.0?

[dsplaisted]

To work around this issue, I'd suggest publishing each project file separately rather than publishing the .sln file. You could also disable parallel builds but that would slow things down.

[ekgurney14]

If you look at my comment, I'm already only trying to publish the csproj not not sln. This problem is also happening on just dotnet build as well.

[rainersigwald]

@ekgurney14 that sounds like a different thing than is tracked by this issue. Can you please file a new issue with more information, like what file is reported as being in use? Or, ideally, a reproducing example.

[piju3]

I spent two days tracking down this problem. Right now building any .sln with --no-self-contained will fail with a mysterious error message.

Maybe my expectations are too high, but I don't think .NET should break this badly when you use a documented flag.

As I understand, --no-self-contained doesn't make sense on solution files anymore, (since you can’t specify a runtime so they can't be self-contained), so it should reject or ignore that flag entirely.