CopyUpToDateMarker path too long

[JanKrivanek]

reported by @olgaark:

We’ve recently had to change the IntDir (IntermediateOutputPath) default value for some vc projects (which made it longer by 17 chars max) and now hitting “CopyUpToDateMarker path too long” problem in some of our tests.

Bug 1900392: Unable to read the project file because the expression exceeds the OS max path limit

The item is added in MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets

So two questions:

1. Can the path be shortened by using short(er) file name? $(MSBuildProjectFile) can be quite long and using it in other paths is often problematic. VC is currently using ShortProjectName in path’s defaults. Can something similar or Windows short 8.3 file name be used in msbuild common targets for paths too?
2. VC projects override GetTargetPathWithTargetPlatformMoniker target where it is used in the CurrentVersion.targets’ implementation. Do we need to add it in the VC’s override?

The item in question: https://github.com/dotnet/msbuild/blob/main/src/Tasks/Microsoft.Common.CurrentVersion.targets#L392

[AR-May]

MSBuild team triage: @drewnoakes Do you know of any reason we could not change this file name?

[drewnoakes]

I can't think of a technical reason not to change the name. The .NET Project System obtains the name via the CopyUpToDateMarker property, so will respond to any changes correctly.

That said, that approach is not a real fix. What component is hitting this limit, and can it be changed to support long paths properly?

[JanKrivanek]

@drewnoakes Thank you for confirming.
Yes - this is a short/mid term workaround untill devenv onboards onto long path support.
At least I suppose the scenario where this is happening involves the in-proc MSBuild node in VS - is that correct @olgaark?

[olgaark]

Yes, this happens during evaluation, so project load in the IDE is affected. And yes, the proposed change is just to reduce the probability that people will hit the limit when long path are not supported.

[JanKrivanek]

I'm wondering whether we can do this in reasonable and correct way.
VC uses a $(ProjectGuid) to generate the short name: (source):

<PropertyGroup Condition ="'$(ShortProjectName)' == '' and '$(ProjectName)' != '' and '$(ProjectGuid)' != ''">
    <ShortProjectName>$(ProjectName)</ShortProjectName>
    <ShortProjectName Condition="'$(ProjectName.Length)' &gt; '16'">$(ProjectName.Substring(0,8)).$(ProjectGuid.Substring(1,8))</ShortProjectName>
</PropertyGroup>

However ProjectGuid is no longer required/generated with the CPS. Relaying only on the shortened filename (or even MSBuildProjectName in order to get rid at least of the extension) can lead to collisions - so we'd need something uniquifying. Content hash can come to the rescue, but it's unreasonable (perf impact).

So we can possbily shorten the marker in case the ProjectGuid exists - to remedy just the non-CPS cases - e.g. like this: #9387 - but it rather feels as a nonsystematic hack (what about CPS? What about $(CleanFile), $(SuggestedBindingRedirectsCacheFile), @(CustomAdditionalCompileInputs ) etc.?)

Thoughts on this @rainersigwald?

[drewnoakes]

Within a solution, a max length project name prefix cannot be considered unique. Project names are often hierarchical and only differ at the end.

[rainersigwald]

That said, that approach is not a real fix. What component is hitting this limit, and can it be changed to support long paths properly?

It's VS/devenv.exe itself, which is tracked by https://developercommunity.visualstudio.com/idea/351628/allow-building-running-and-debugging-a-net-applica.html

[JanKrivanek]

Within a solution, a max length project name prefix cannot be considered unique. Project names are often hierarchical and only differ at the end.

Correct.
In a presence of ProjectGuid it can be uniquidied by that. Without ProjectGuid it would not be shortened. (#9387)
That means we can fix the particular problem here (CopyUpToDateMarker path too long for VC project), but other scenarios (CPS, other obj metafiles etc.) are left untouched - so question is whether we want such a 'tactical' change

[KalleOlaviNiemitalo]

It would be possible to generate a GUID by hashing the project name, when ProjectGuid is not defined.