dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.22k stars 1.35k forks source link

Unexpected warning/error MSB3202 #9986

Closed Archie-Yang closed 1 month ago

Archie-Yang commented 12 months ago

Attachment

ProjectNotFound.zip

Visual Studio Version

Visual Studio 2022 (17.7.6)

Summary

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

Actual Behavior

User Impact

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 commented 11 months ago

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 commented 8 months ago

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

drewnoakes commented 7 months ago

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

martyelliott7 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

@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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

drewnoakes commented 6 months ago

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

PondPackMan2023 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

@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 commented 6 months ago

Same issue on VS 2022 ver.17.9.6

MichalPavlik commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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

MichalPavlik commented 1 month ago

I think I found it. There is a check for file existence: https://github.com/dotnet/msbuild/blob/7cf66090a764f0f239671e4877255efe7ba91155/src/Build/BackEnd/Components/RequestBuilder/IntrinsicTasks/MSBuild.cs#L343

... and this abstraction calls https://github.com/dotnet/msbuild/blob/7cf66090a764f0f239671e4877255efe7ba91155/src/Framework/NativeMethods.cs#L1837

... which returns false. System.IO.File.Exists returns true for the same path. If we will get rid of this P/Invoke (https://github.com/dotnet/msbuild/pull/9223#issuecomment-2217451762) 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 commented 1 month ago

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