Unexpected warning/error MSB3202

[Archie-Yang]

Attachment

ProjectNotFound.zip

Visual Studio Version

Visual Studio 2022 (17.7.6)

Summary

• Building project, unexpected warning message: ..\Microsoft.Common.CurrentVersion.targets(1797,5): warning MSB3202: The project file "xxx.csproj" was not found.
• In more large and complex solution, randomly showing the same MSB3202 message but as error and failed to build

Steps to Reproduce

1. Open the solution in attachment file
2. Build the CompanyName.OrganizationName.PackageName.Hardware project
3. Open and save Class1.cs in the project
4. Build the project again
5. Repeat steps 3 to 4, warning MSB3202 is shown in the output window

Build started...
1>------ Build started: Project: CompanyName.OrganizationName.PackageName.Hardware, Configuration: Debug Any CPU ------
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\arm64\Microsoft.Common.CurrentVersion.targets(1797,5): warning MSB3202: The project file "..\..\OtherCompanyName.OrganizationName.PackageName\Network\OtherCompanyName.OrganizationName.PackageName.Network.Connection\OtherCompanyName.OrganizationName.PackageName.Network.Connection.csproj" was not found.
1>Done building project "CompanyName.OrganizationName.PackageName.Network.Communication.IO.csproj".
1>CompanyName.OrganizationName.PackageName.Hardware -> C:\ProjectNotFound\CompanyName.OrganizationName.PackageName\CompanyName.OrganizationName.PackageName.Hardware\bin\Debug\net7.0\CompanyName.OrganizationName.PackageName.Hardware.dll
========== Build: 1 succeeded, 0 failed, 4 up-to-date, 0 skipped ==========
========== Build started at 7:57 PM and took 01.367 seconds ==========

Expected Behavior

• Build succeeded without any warning/error MSB3202 message because project file(s) does exist

Actual Behavior

• Unexpected warning/error MSB3202

User Impact

• Failed to build if error MSB3202 is shown

Notes

1. This problem can be found in Visual Studio 2019 also
2. If we use dotnet build or msbuild command to build the project with the same steps, no warning/error MS3202 is shown
3. If we set Maximum number of parallel project builds to 1, no warning/error MS3202 is shown in Visual Studio
4. If we disable BuildInParallel in CompanyName.OrganizationName.PackageName.Hardware project, no warning/error MS3202 is shown in Visual Studio
5. If we unchecked Don't call MSBuild if a project appears to be up to date, no warning/error MS3202 is shown in Visual Studio
6. If we enable DisableFastUpToDateCheck in CompanyName.OrganizationName.PackageName.Network.Builder and CompanyName.OrganizationName.PackageName.Network.Communication.IO projects, no warning/error MS3202 is shown in Visual Studio
7. This issue seems to be related to long path issue
8. Set LongPathsEnabled = 1 in registry does not help

[PondPackMan2023]

I am also running into this issue. Turning off the "Don't call MSBuild if a project appears to be up to date" option is not an option for us. Our solution has 491 projects in it. If this option is turned off, it takes several minutes to build if no changes are made at all.

Is this issue caused by a long path problem? If so, we can investigate on renaming our projects if necessary. But if LongPathsEnabled is set to 1 in the registry, there should be no issue at all.

[martyelliott7]

@drewnoakes @melytc any further thoughts or updates here? Been running into the same thing.

[drewnoakes]

There's no update here and we can't give any timeline, sorry. Any update will be posted here directly.

[martyelliott7]

@drewnoakes thanks for the update. Just wanted to check, is there any sense of what might be causing this? In particular if there's a specific length at which project file paths start becoming problematic.

[drewnoakes]

Could folks who also hit this please verify that all the workarounds listed in the issue actually prevent the error? They seem to all be tweaks to unrelated features, so I'm surprised that they'd all work as described. Maybe the problem is intermittent and some of them don't actually help. Narrowing the list down could help.

That said the MSB3202 diagnostic is coming from MSBuild directly. VS uses the .NET Framework version of MSBuild, whereas dotnet build uses the .NET Core version, which might be a factor.

Understanding if the error occurs in a VS Developer Prompt command line build would be helpful.

[martyelliott7]

@drewnoakes I can confirm setting the number of parallel project builds to 1 fixes the issue. There are several .NET Framework projects in the solution, so I can't test out with dotnet build.

If it's any help, this error only gets logged for ~8 or so projects (out of a ~500 project solution) which seem to all have longer paths.

[moxplod]

Facing the same issue on MacOs and rider as well.
dotnet build works fine

Moving the entire directory to a simpler path solves the issue

[martyelliott7]

For some more info, this error usually seems to stem from a specific group of projects as well. The projects which throw this error (i.e. the referencing projects, not the referenced projects) all seem to be .NET Framework projects with non-SDK style .csproj files.

[PondPackMan2023]

That is not the case with me. Other than C++ projects, all projects are SDK-style. 1/2 of them target net48 and 1/2 target net6 (multitargeting with a single project file is not an option for us). Though it seems the ones that fail the most often with this issue are net48 targeted projects.

[martyelliott7]

From looking some more, this seems to be invoked from the _GetProjectReferenceTargetFrameworkProperties target

[drewnoakes]

There's enough signal that this isn't VS-specific, so I'm going to move this to MSBuild for further investigation.

[PondPackMan2023]

There's enough signal that this isn't VS-specific, so I'm going to move this to MSBuild for further investigation.

@drewnoakes Can you please provide a link to the issue under MSBuild so those of us interested can follow it?

[rainersigwald]

There's enough signal that this isn't VS-specific, so I'm going to move this to MSBuild for further investigation.

Can you elaborate on this? My read is that all of the failures are in VS. I suspect the workarounds listed are pushing more of the build out-of-proc and thus avoiding the devenv.exe MAX_PATH restrictions.

The overall "VS should support long paths" issue is https://developercommunity.visualstudio.com/idea/351628/allow-building-running-and-debugging-a-net-applica.html.

Unfortunately, I suspect the most expedient option in these cases is to shorten your paths.

[drewnoakes]

@PondPackMan2023 the issue was transferred across repos, so this is still the one to track.

There's enough signal that this isn't VS-specific, so I'm going to move this to MSBuild for further investigation.

Can you elaborate on this?

I can't see how changing the degree of parallelism would be related to anything in VS, but perhaps it's changing where the build occurs, as you say.

If you think any fix here would be on the project system side, please transfer back and provide some guidance, as it's not clear what we could do here. Maybe the issue needs to go to VS platform, who schedule the builds (and aren't on GitHub).

[ctodor]

Same issue on VS 2022 ver.17.9.6

[MichalPavlik]

I tried to repro by using Archie's solution, and I can confirm it's reproable (pretty consistently) on VS 17.10.5. I see warnings in Output Window, but not in Error List.
If it's really reproable also with Rider on MacOS, it could be some weird MSBuild issue. I will assign myself for further investigation, but as this issue is not blocking, I will probably get to it in September (earliest).

[PondPackMan2023]

I've been working on readding multitargeting to our primary solution. This drops the project count to 543. But, if the root path is too long, then I start to run into the "project not found" build issue.

This issue does not seem to occur with projects that target a single framework. Right now, our solution has 913 projects. But this is because we have pairs of C# projects where one targets net48 and the other net6.0-windows. The project not found issue doesn't occur, even with the "longer" paths. But as soon as I apply multitargeting, things start to break down.

What VS/msbuild appears to be doing is taking the path of the project and then appending the relative project reference path to it but then not resolving it with Path.GetFullPath. By leaving the relative path portion (........\Base<etc.) it creates a string that is 260+ characters long and that is what causes the build error.

We have a plan to mitigate the issue by shortening the paths to the projects and that will help. But if one of my colleagues ends up using a root path that is too long, then they run into the issue.

It seems the best fix here is for VS/msbuild to use GetFullPath after doing the appending to get a "real" project path of the project reference. Then if it can't find the project, create the build error. But don't create the build error on the non-resolved string.

Two of my colleagues kept telling me they weren't seeing the problem. But it ends up they were using a root path of g:\of and I was using a root path of g:\src. That difference of 1 character made all the difference.

A string length of 259 works. 260 or more does not. Multitargeting seems to make the issue occur more frequently.

[MichalPavlik]

I'm wondering if the #9223 (issue #4247) could be related.

[MichalPavlik]

I think I found it. There is a check for file existence:

msbuild/src/Build/BackEnd/Components/RequestBuilder/IntrinsicTasks/MSBuild.cs

Line 343 in 7cf6609

if (FileSystems.Default.FileExists(projectPath) || (skipNonExistProjects == SkipNonExistentProjectsBehavior.Build))

... and this abstraction calls

msbuild/src/Framework/NativeMethods.cs

Line 1837 in 7cf6609

internal static bool FileExistsWindows(string fullPath)

... which returns false. System.IO.File.Exists returns true for the same path. If we will get rid of this P/Invoke (#9223 (comment)) then it should resolve this issue.

It still doesn't explain why is this happening on MacOS. I guess it's a different issue, because the FileExistsWindows is Windows only implementation :)

[MichalPavlik]

The PR is merged and I tested VS with latest main MSBuild. I can't repro the issue anymore, so I'm closing it.