Open mwmccallum opened 1 year ago
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
Seen here as well
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
Changing the Build step and removing "--self-contained $false" did resolve this issue. Thanks, Mike
Glad to hear it! I'm going to reopen this because it'd be nice if we could keep it from happening.
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 :-)
Changing the Build step and removing "--self-contained $false" did resolve this issue. Thanks, Mike
This help me
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?
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.
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.
@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.
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.
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.
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.