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