System.IO.PathTooLongException - VS2022

[MariusEls]

I recently installed VS2022 and attempted to build a solution that currently builds successful in VS2019, and got the below error:

> This is an unhandled exception in MSBuild -- PLEASE UPVOTE AN EXISTING ISSUE OR FILE A NEW ONE AT https://aka.ms/msbuild/unhandled.
>     System.IO.PathTooLongException: Path: C:\xxx\xxxxxx\xxxxxxxx\xxxx\xxxxxxx\xxxxxxxxxxxxxxxxx\xxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\xxxxxxxx\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL exceeds the OS max path limit. The fully qualified file name must be less than 260 characters.
>    at Microsoft.Build.Shared.FileUtilities.GetFullPath(String path)
>    at Microsoft.Build.Shared.FileUtilities.NormalizePath(String path)
>    at Microsoft.Build.Shared.FileUtilities.GetFullPath(String fileSpec, String currentDirectory)
>    at Microsoft.Build.Evaluation.LazyItemEvaluator`4.LazyItemList.ProcessNonWildCardItemUpdates(Dictionary`2 itemsWithNoWildcards, Builder items)
>    at Microsoft.Build.Evaluation.LazyItemEvaluator`4.LazyItemList.ComputeItems(LazyItemList lazyItemList, ImmutableHashSet`1 globsToIgnore)
>    at Microsoft.Build.Evaluation.LazyItemEvaluator`4.LazyItemList.GetItemData(ImmutableHashSet`1 globsToIgnore)
>    at System.Linq.Enumerable.<SelectManyIterator>d__17`2.MoveNext()
>    at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
>    at System.Linq.OrderedEnumerable`1.<GetEnumerator>d__1.MoveNext()
>    at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
>    at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, Project project, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
>    at Microsoft.Build.Execution.ProjectInstance.Initialize(ProjectRootElement xml, IDictionary`2 globalProperties, String explicitToolsVersion, String explicitSubToolsetVersion, Int32 visualStudioVersionFromSolution, BuildParameters buildParameters, ILoggingService loggingService, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, Nullable`1 projectLoadSettings, EvaluationContext evaluationContext)
>    at Microsoft.Build.BackEnd.BuildRequestConfiguration.<>c__DisplayClass60_0.<LoadProjectIntoConfiguration>b__0()
>    at Microsoft.Build.BackEnd.BuildRequestConfiguration.InitializeProject(BuildParameters buildParameters, Func`1 loadProjectFromFile)
>    at Microsoft.Build.BackEnd.RequestBuilder.<BuildProject>d__68.MoveNext()
> --- End of stack trace from previous location where exception was thrown ---
>    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
>    at Microsoft.Build.BackEnd.RequestBuilder.<BuildAndReport>d__59.MoveNext()	Converter			

Using

• MSBuild version 17.5.1+f6fdcf537 for .NET Framework
• VS Professional 2022 (64-bit) version 17.5.3

Not too sure why this issue is creeping back into MSBuild as I'm sure it was resolved in VS 2019

[jrdodds]

Just to confirm: Are you building from the same directory path in VS2022 as you did in VS2019? Do you still have VS2019 installed? The same solution on the same machine in the same directory path builds successfully in VS2019 and fails in VS2022?

[MariusEls]

Good afternoon Are you building from the same directory path in VS2022 as you did in VS2019? *Yes* Do you still have VS2019 installed? *Yes* The same solution on the same machine in the same directory path builds successfully in VS2019 and fails in VS2022? *Yes* Thank you and Regards

On Tue, 04 Apr 2023 at 16:18, Jonathan Dodds ***@***.***> wrote: Just to confirm: Are you building from the same directory path in VS2022 as you did in VS2019? Do you still have VS2019 installed? The same solution on the same machine in the same directory path builds successfully in VS2019 and fails in VS2022? — Reply to this email directly, view it on GitHub <#8629 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABOCPAENZLEFFCZO4HWBTHLW7QUS5ANCNFSM6AAAAAAWSVZQWY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Regards Marius Els +27 82 389 9499 "...as for me and my house, we will serve the Lord."- Joshua 24:15 b

[jwarner381]

Is this defect gaining any traction? Was posted over a year ago, and it's definitely still happening!

Why in the world is it considering fully-qualified assembly information to be part of a 'file path' in the first place? It's isn't the name of a file! It's an ASSEMBLY REFERENCE.

Would you please fix this? Otherwise we're all having to manually turn e.g.

Reference Include="Microsoft.Office.Interop.Excel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, processorArchitecture=MSIL"

into e.g.
Reference Include="Microsoft.Office.Interop.Excel"

which works fine as long as it is not a GAC'd assembly reference, and we give it a HintPath so that it finds it!
(I had to remove the brackets from the assembly reference in this post or this won't render it correctly)

[jrdodds]

(I had to remove the [less-than and greater-than symbols] from the assembly reference in this post or this won't render it correctly)

Enclose code in backticks (`):

<Reference Include="Microsoft.Office.Interop.Excel">

Or use use entitles (< and >):

<Reference Include="Microsoft.Office.Interop.Excel">

[taberon]

I happened to notice on the main MSBuild github repo site (in the primary ReadMe.md) for "building" -- step number 2 says "Ensure long path support is enabled at the Windows level.".

Anyway, one might easily see this being a regression in VS 2022 if part of building the code requires long path support to be enabled for Windows, so I'm sure no one will be able to reproduce if actually building/working on the code. : )

I guess the question is whether the team ran into the issue themselves and resolved by enabling long path support, or if that setting was always required and then the "version" and "culture" info started to be appended to paths and it still just happened to work because devs working on MSBuild already have long path support enabled..?

[jwarner381]

Requiring 'long path support' to work around a defect like this is not the right 'solution'. Can you imagine the pain point that would be, on a corporation with thousands of developers, to have to fiddle with each of their registries? And how about build agents in the cloud - do they all automagically have this feature enabled? I doubt it.

Bottom line is this is definitely a defect. Again, an assembly reference is not part of a file path. The fact that it is being treated as if it were, and being subject to the constraints of file path lengths, is what needs to be fixed, rather than working around it by enabling long file path support.

[maridematte]

So we can look at this to check what is going on could you please share a binlog?

Details on sharing binary logs More information on binary logs
NOTE: Binary logs capture environment information. Ensure it does not include any information you don't want to be public before you share one. If you decide to provide a binlog, we recommend sharing binary logs privately with Microsoft.

[jwarner381]

@maridematte Ok, how do I do that? I have captured a .binlog file, but it is not allowed to post it here.

Details

File type not allowed: .binlog

[maridematte]

To share binlogs we recommend opening a feedback ticket with the developer community, link this github issue and ask the issue to be routed to the MSBuild team. This way your binlog is shared privately with us, since it can contain sensitive information.

[jwarner381]

@maridematte That is extremely clunky. I go to Visual Studio and select to 'report a problem' and it won't let me sign in.

Details

Error signing in: 'ERR_SIGN_IN: System.Exception: ERR_USER_PROFILE_NULL: System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult) at
...

Could you provide me an email address to email the binlog file to? 'Your' system is really awful for doing this.

[maridematte]

That is not great. You can try changing the extension to .txt and then uploading it to github itself. So filename.binlog.txt and it should work.

[jwarner381]

build.binlog.txt

@maridematte Please see the attached file renamed to a .txt extension. Thanks

[jwarner381]

@maridematte Any progress on this?
Note however that for me personally and for my company this is less of an issue now. When Visual Studio adds assembly references it does so in the shorter form without the ",Version=..." attributes on the reference so we don't have to manually manipulate these moving forward. Our issue came up because we had (legacy format) .csproj files that we have been converting to SDK format, and the tool that helped with converting them did not remove the ",Version=..." attributes and this led to seeing the MSBuild defect (PathTooLongException) in some cases. We have now worked around this by removing those attributes everywhere in our SDK format .csproj files, and since moving forward Visual Studio will generate the references in the shorter form, there is no issue going forward.
But, I think it should still be something for Microsoft to be aware of and fix regardless, because it is turning assembly references into "file path" parts, which they are not.