error MSB3795: There was a problem in the GetSDKReferenceFiles task

I'm getting this error randomly (but more frequently) when my builds are running.

I have 4 build agents running on the same build machine, in 4 separate build agent folders:

C:\A1\
C:\A2\
C:\A3\
C:\A4\
When all four are performing builds at the same time, this error randomly pops up.
The error says:

 

[06:57:21] :     [Step 4/5] Build FAILED.
[06:57:21] :     [Step 4/5] 
[06:57:21] :     [Step 4/5]        "C:\C1\w\UWPx8623\Batch\SLN\23\UWP\Toolkit.sln" (Build target) (1) ->
[06:57:21] :     [Step 4/5]        "C:\C1\w\UWPx8623\src\Kernel\UWP\LicLib\LtLicLib.vcxproj" (default target) (64) ->
[06:57:21] :     [Step 4/5]        (ExpandSDKReferences target) -> 
[06:57:21] :     [Step 4/5]          C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2767,6): error MSB3795: There was a problem in the GetSDKReferenceFiles task. Could not find a part of the path 'C:\C2\temp\buildTmp\MSBuildTemp'. [C:\C1\w\UWPx8623\src\Kernel\UWP\LicLib\LtLicLib.vcxproj]
[06:57:21] :     [Step 4/5] 
[06:57:21] :     [Step 4/5]     0 Warning(s)
[06:57:21] :     [Step 4/5]     1 Error(s)

Note that the builds are running in C:\C1, but MSBUILD is complaining about files from the TEMP folder for C:\C2.

Please help.

0
7 comments

Hi,

The error you are seeing indicates that MSBuild is attempting to access a temporary directory that doesn't exist or is inaccessible, which is causing the build to fail.

Ensure that each build agent is configured to use a separate temporary directory.

For example, you can configure the environment variables in each buildAgent.properties file like so:

tempDir=C:\A1\temp

Repeat this configuration for each agent (A1, A2, A3, A4) with their respective directories.

If the issue persists, consider running the build with diagnostic logging enabled to get more detailed information about what MSBuild is doing at the time of the failure. This can be done by adding the  switch to your MSBuild command. /verbosity:diagnostic

0

Thanks Tom.

Yes, each agent is configured to use a DIFFERENT tempDir. That was the first thing I checked.

Note that this problem only started to appear when I switched all of my Build Steps to use PowerShell Runner with scripts that call the latest version of MSBUILD (that comes with VS 2022).

Previously I was using the Visual Studio SLN Runner for the Build Steps.

It looks to me like the TEMP folder gets changed somewhere during the build. As you can see from this log, the build is running in C:\C3\ but at some point, MSBUILD thinks the TEMP is C:\C3

 

[07:59:41] :     [Step 4/5]     58>GetInstalledSDKLocations:
[07:59:41] :     [Step 4/5]          Searching for SDKs targeting "Windows, 8.1".
[07:59:41] :     [Step 4/5]        ResolveSDKReferences:
[07:59:41] :     [Step 4/5]            Reading SDK manifest file "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs\14.0\SDKManifest.xml".
[07:59:41] :     [Step 4/5]            Targeted configuration and architecture "Retail|ARM"
[07:59:41] :     [Step 4/5]            Could not find "FrameworkIdentity" attribute "FrameworkIdentity-Retail-ARM" in the SDK manifest. 
[07:59:41] :     [Step 4/5]            Found "FrameworkIdentity" attribute "Name = Microsoft.VCLibs.140.00, MinVersion = 14.0.30704.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'" in the SDK manifest.
[07:59:41] :     [Step 4/5]            Found "APPX" location attribute "AppX-Retail-x86=.\AppX\Retail\x86\Microsoft.VCLibs.x86.14.00.appx" in the SDK manifest.
[07:59:41] :     [Step 4/5]            Found "APPX" location attribute "AppX-Retail-x64=.\AppX\Retail\x64\Microsoft.VCLibs.x64.14.00.appx" in the SDK manifest.
[07:59:41] :     [Step 4/5]            Found "APPX" location attribute "AppX-Retail-ARM=.\AppX\Retail\ARM\Microsoft.VCLibs.ARM.14.00.appx" in the SDK manifest.
[07:59:41] :     [Step 4/5]            Found "APPX" location attribute "AppX-Retail-ARM64=.\AppX\Retail\ARM64\Microsoft.VCLibs.ARM64.14.00.appx" in the SDK manifest.
[07:59:41] :     [Step 4/5]     58>C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2767,6): error MSB3795: There was a problem in the GetSDKReferenceFiles task. Could not find a part of the path 'C:\C2\temp\buildTmp\MSBuildTemp'. [C:\C3\w\UWPARM23\src\Kernel\UWP\LicLib\LtLicLib.vcxproj]
[07:59:41] :     [Step 4/5]     58>Done Building Project "C:\C3\w\UWPARM23\src\Kernel\UWP\LicLib\LtLicLib.vcxproj" (default targets) -- FAILED.

0

I tried /verbosity:diagnostic for MSBUILD.

In the builds that fail, the only place I see the WRONG temp folder mentioned is in the actual error line.

I've uploaded the log here: https://1drv.ms/u/s!AivmmOhbKa5iku8zhVHbs-banx4Geg?e=nvKSFt

0

I also notice in the log file that one of the very first steps each time is to clear the temp folder:

[12:54:04] : Updating tools for build
[12:54:04] :     [Updating tools for build] Tools are not required for the build
[12:54:04] : Clearing temporary directory: C:\C3\temp\buildTmp
 

I think somehow, TeamCity is changing the TEMP env var for the whole system and if that happens at just the right time when multiple builds are running on the same system, then BANG.

0
Hi,

Could you please share the teamcity-agent.log files to us for further investigation?

Files can be uploaded via https://uploads.jetbrains.com/. Please let us know the exact id after the upload.

Best Regards,
Tom
0

I think I may have resolved this problem.

I changed my MSBUILD arguments to include the /nr:False option:

$MsBuildArgs = "`"$ProjectOrSolution`" /t:`"$Target`" /m /nr:False /tv:$ToolsVersion /p:PlatformToolset=$PlatformToolset /p:Platform=`"$Platform`" /p:Configuration=$Configuration /p:LEAD_VER=$LEADTOOLSVersion"

The builds have been running over and over for 12 hours now with no return of the error.

0

Hi,

I'm glad to know that you have resolved your issue, and thank you for sharing the details.

By default, the value for nr is set to True. Using the /nr:False option disables node reuse, which means that MSBuild(https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-command-line-reference?view=vs-2022) will not reuse previously created nodes and will start fresh nodes for each build invocation

In your specific case, the error indicated issues with temporary files and paths, which might have been caused by conflicts or leftover state from reused nodes. Disabling node reuse ensures that each build agent has a clean start, avoiding these conflicts and ensuring that temporary files and paths are managed correctly for each build.

0

Please sign in to leave a comment.