"FullPath cannot be applied" error for nested node_modules in VS2015 CTP6
Asked Answered
A

6

8

I'm playing around with MVC6 + Aurelia project in Visual Studio 2015 CTP6, and came across something interesting.

My node_modules is by default in the project root and everything works fine. However, I'd like to keep source tree a bit more organized and moved node_modules, jspm_modules and related stuff to a subfolder - eg. MyApp\client\node_modules etc.

But now Visual Studio stops loading the project. Here's exception from "VsProjectFault.failure.txt":

(Inner Exception #1) System.InvalidOperationException: The item metadata "%(FullPath)" cannot be applied to the path "client\node_modules\conventional-changelog\node_modules\lodash.assign\node_modules\lodash._basecreatecallback\node_modules\lodash.bind\node_modules\lodash._createwrapper\node_modules\lodash._basecreatewrapper\node_modules\". C:\Work\xxxxxxxxxx\xxxxxxxxxx.xxx\src\client\node_modules\conventional-changelog\node_modules\lodash.assign\node_modules\lodash._basecreatecallback\node_modules\lodash.bind\node_modules\lodash._createwrapper\node_modules\lodash._basecreatewrapper\node_modules\
   at Microsoft.Build.Shared.ErrorUtilities.ThrowInvalidOperation(String resourceName, Object[] args)
   at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowInvalidOperation(Boolean condition, String resourceName, Object arg0, Object arg1, Object arg2)
   at Microsoft.Build.Shared.FileUtilities.ItemSpecModifiers.GetItemSpecModifier(String currentDirectory, String itemSpec, String definingProjectEscaped, String modifier, String& fullPath)
   ...
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.ProjectSystem.Utilities.DataflowExtensions.<>c__DisplayClass37`2.<<CreateSelfFilteringTransformBlock>b__38>d__0.MoveNext()

Apparently the problem is in node_modules recursive path being too long - and there's bug #6960 in Node tracker

Node needs an alternative approach to endless, recursively nested node_modules folders on Windows. Most Windows tools, utilities and shells cannot handle file and folder paths longer than 260 characters at most.

...which seems like closed as won't fix to me:

Node isn't going to change, so this isn't really a Node issue. The problem is not with the module loading semantics, but with the module installation semantics. (The two are related, but not identical.)

But then I don't understand how come the project was loading in the first place, because some paths are definitely over 260 symbols even if node_modules is under the project root!

Is there some setting in config or something which helps Visual Studio 2015 to load the project with node_modules, what's going on?

Alecto answered 31/3, 2015 at 13:30 Comment(1)
this may be getting worse. I will suggest to file an issue on github, the Microsoft team is very responsive and open to track down those scenarios. For what it's worth, there's some guys working on the flow of NET5 with aurelia because of the wwwroot file system, so maybe you should also check out in gitter.im/Aurelia/Discuss <-- pretty awesome guys there.Lorrainelorrayne
E
5

I managed to fix this issue in a Windows 10 development machine by enabling the Win32 long paths policy using the Group Policy Editor. Here are the required steps (depending if you've the Anniversary Update installed or not):

Before Anniversary Update

If you’re running a Windows 10 build between 14352 and RTM 1607, aka “Anniversary Update“, you need to do the following:

  • Launch the Group Policy Editor by pressing Windows Key and manually typing gpedit.msc, then hit the Enter key.
  • Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem > NTFS
  • Locate the Enable NTFS long paths option and enable it with a click.

As an alternative, you can also achieve the same results by executing the following registry commands:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

After Anniversary Update

If you’re running a post-Anniversary Update Windows 10 build (RTM 1067 or newer), you need to use the following:

  • Launch the Group Policy Editor by pressing Windows Key and manually typing gpedit.msc, then hit the Enter key.
  • Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem
  • Locate the Enable Win32 long paths option and enable it with a click.

In case you need additional details you can also check out this blog post I wrote on the topic.

Encephalogram answered 17/1, 2017 at 0:16 Comment(2)
Unfortunately, this is not a solution in all cases. I have made all RegEdits / Group Policy Edits and still get the same problem. I am, however, using VStudio for R projects, which may be one potential cause of trouble. For others out there unable to use this RegEdit solution, I recommend finding the error log ("VsProjectFault...") and identifying the individual culprits.Benn
fixed the same error for me on VS 2022Standardize
H
4

http://bstruthers.com/weblog/2013/02/06/Cannot_evaluate_the_item_metadata_FullPath/

This is because the character limitation in file path in VS has crossed. Copy the folder inside a root folder and try.

Haematothermal answered 15/7, 2016 at 9:41 Comment(0)
O
0

VS2015 / project.json Build + VS2017 / CSProj build

http://dan.clarke.name/2017/02/including-excluding-files-from-build-with-vs2017-and-net-core/

Just change to (inside the "Project" tag):

<ItemGroup>
    <Compile Remove="[ClientAppRoot]\node_modules\**" />
    <Content Remove="[ClientAppRoot]\node_modules\**" />
    <EmbeddedResource Remove="[ClientAppRoot]\node_modules\**" />
    <None Remove="[ClientAppRoot]\node_modules\**" />
</ItemGroup>
Operative answered 7/6, 2017 at 10:57 Comment(0)
K
0

I found it, you can move your solution file to the very folder you have your project in. The error is caused because windows has path policy which limits the number of characters provided in the execution path.

client\node_modules\conventional-changelog\node_modules\lodash.assign\node_modules\lodash._basecreatecallback\node_modules\lodash.bind\node_modules\lodash._createwrapper\node_modules\lodash._basecreatewrapper\node_modules\". C:\Work\xxxxxxxxxx\xxxxxxxxxx.xxx\src\client\node_modules\conventional-changelog\node_modules\lodash.assign\node_modules\lodash._basecreatecallback\node_modules\lodash.bind\node_modules\lodash._createwrapper\node_modules\lodash._basecreatewrapper\node_modules\

Just move your project file (the whole solution with all packages) to the Work/xxxx folder and this would resolve it.

Kidnap answered 21/8, 2017 at 5:3 Comment(0)
A
0

It looks like your project exceeds MAX_PATH, You can try to move your project to a shorter path (e.g. c:\src) For more details, please check here

Ankara answered 11/2, 2018 at 12:5 Comment(0)
F
0

To resolve this, I moved my solution to C:\ drive. By doing this, the characters were shortened and the error was no more after rebuilding the project.

Frump answered 31/5 at 9:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.