#Migrating App_Plugin on v14 caueses path too long error

1 messages · Page 1 of 1 (latest)

coarse lantern
#

I'm migrating my Welcome Dashboard on the new V14 Umbraco.

I was following the https://docs.umbraco.com/umbraco-cms/extending/customize-backoffice/vite-package-setup and https://docs.umbraco.com/umbraco-cms/tutorials/creating-a-custom-dashboard tutoritals.

The problem that I am now facing is, that since the node_modules is installed "deep" in the solution tree, I started to get build error by VS.

Cannot evaluate the item metadata "%(FullPath)". The item metadata "%(FullPath)" cannot be applied to the path "App_Plugins\my-welcome-dashboard\node_modules\%40umbraco-cms\backoffice\dist-cms\packages\documents\documents\user-permissions\input-document-granular-user-permission\input-document-granular-user-permission.element.d.ts". Path: C:\src\COM\MyCom\src\Cms\MyCom.Cms\App_Plugins\my-welcome-dashboard\node_modules\@umbraco-cms\backoffice\dist-cms\packages\documents\documents\user-permissions\input-document-granular-user-permission\input-document-granular-user-permission.element.d.ts exceeds the OS max path limit. The fully qualified file name must be less than 260 characters.

I excluded the node_modules folder from solution, but the compiler still tries to do something with it.

<ItemGroup>
  <None Remove="App_Plugins\my-welcome-dashboard\node_modules\**" />
</ItemGroup>

Has anyone faced this issue and solved it?

Vite Package Setup | Umbraco CMS

Get started with a Vite Package, setup with TypeScript and Lit

Creating a Custom Dashboard | Umbraco CMS

A guide to creating a custom dashboard in Umbraco

pale roost
#

Hi @coarse lantern - I am facing long path errors trying to build then publish to Azure.

coarse lantern
#

So no fix yet? 🤨

pale roost
#

Honestly I've wasted a week trying every solution so far

coarse lantern
#

I tried different CSPROJ exclusion techniques, but was not successfull so far.

pale roost
#

Are you on Windows?

#

First things to do are enable Windows Long File Paths and enable Git Long File Paths.
Easy to find with a search, sorry no links to hand.

#

As well as enabling Windows and Git to use Long File Paths I just read "The application manifest must also include the longPathAware element."

# 
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>```
#

Not sure if this would this go in web.config or appsettings?

coarse lantern
#

We don't use Web.config anymore

pale roost
#

Not sure if this would this go in web.config or appsettings?

#

I just found:

If you need to handle long paths in your Umbraco app, consider using the Path.GetFullPath() method with the \?\ prefix when working with file paths.

# 
string fullPath = Path.GetFullPath(longPath);
#

There must be a way to allow it for the app as a whole

#

Hah "Unfortunately, Visual Studio (as of version 2022) doesn’t fully support long paths."

#

I have also tried CLI which apparently bypasses the issue but with no success

storm pier
coarse lantern
#

I renamed now the package because the name was just at 261 characters, but now the problem is just different.

Severity    Code    Description    Project    File    Line    Suppression State
Error (active)    MSB3021    Unable to copy file "C:\src\Com\MyCom\src\Cms\MyCom.Cms\App_Plugins\welcome-dashboard\node_modules\@umbraco-cms\backoffice\dist-cms\packages\block\block-grid\property-editors\block-grid-type-configuration\property-editor-ui-block-grid-type-configuration.element.js" to "bin\Debug\net8.0\App_Plugins\welcome-dashboard\node_modules\@umbraco-cms\backoffice\dist-cms\packages\block\block-grid\property-editors\block-grid-type-configuration\property-editor-ui-block-grid-type-configuration.element.js". Could not find a part of the path 'bin\Debug\net8.0\App_Plugins\welcome-dashboard\node_modules\@umbraco-cms\backoffice\dist-cms\packages\block\block-grid\property-editors\block-grid-type-configuration\property-editor-ui-block-grid-type-configuration.element.js'.    MyCom.Cms    C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets    5270

I suspect that the reason for this is that also the destination folder path becomes too long and copy fails...

coarse lantern
#

Migrating App_Plugin on v14 caueses path too long error

coarse lantern
coarse lantern
storm pier
# coarse lantern Hi, could you show me where was this discussed if already?

https://discord.com/channels/869656431308189746/1252495956432261203 but in this post, the problem was that "Web Publish" from Visual Studio doesn't work because it uses csc.exe under the hood to do the web publish, and csc.exe isn't long-path enabled. dotnet publish works though, and then you have to publish your app some other way using msdeploy or the Azure CLI or the Azure Publish VS Code plug-in. There was no actual resolution to the path-too-long problem in that post (except using dotnet publish instead of VS Web Publish). Your problem sounds like something in Visual Studio is insisting on "building" the node folder.

The workaround found in that post was to use the shortest root path possible for your Umbraco project folder, e.g. A:\U\, that works for an out-of-the-box Umbraco 14 web project but maybe not when building a custom dashboard plugin.

coarse lantern
#

I managed to resolve this issue with updating MSBuild tools to v17.10
Now the project builds successfully.

storm pier
pale roost
coarse lantern
#

From the previous project I was working on I had set an environmental variable PATH to C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin .

So VisualStudio used different MSBuild version as dotnet build. If I ran the build from CLI the build was successful but from VS it failed. So I knew there must be some difference.

PS C:\src> msbuild -version
Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\src> dotnet msbuild -version
MSBuild version 17.10.4+10fbfbf2e for .NET
17.10.4.21802

Then I replaced the PATH value with C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\ and then the used versions of the MSBuild were the same:

PS C:\src> msbuild -version
MSBuild version 17.10.4+10fbfbf2e for .NET Framework
17.10.4.21802

PS C:\src> dotnet msbuild -version
MSBuild version 17.10.4+10fbfbf2e for .NET
17.10.4.21802

And after that the problem with long path names went away.

I hope it helps you too 🙂

pale roost
#

Thanks @coarse lantern I had reinstalled the latest MSBuild and the same as you, set the new path.
My build seemed fine and it was copying the files without creating the long paths for the node stuff. So I think that may be a VS thing.
I ran this from Cli as it seems that it's what MSBuild is for, I assume it doesn't enable VS to publish correctly?
Lastly mine failed unfortunately authentication on Azure but that's another issue I think I can do

storm pier
#

MSBuild is a command-line application that is the predecessor to dotnet build/publish/restore you could say. MSBuild is used by VS and by many Azure DevOps pipes. MSBuild can also "publish" in the "deploy" sense (not the dotnet publish sense) and that's what happens in Azure DevOps release pipes. Siblings to MSBuild are msdeploy (the old deployment tool) and csc (the old C# compiler) and both of these are also used by VS and Azure DevOps pipes. Some of these tools are long-path enabled, but not csc (which is used by VS Web Publish, for some very strange reason) and pre-2022 MSBuild. No idea about MSDeploy. These tools are from the .NET Framework days and only exist on Windows.

#

So, long story short: Buy a Mac

pale roost
#

Haha it took me 20 years to get rid of my macs!

#

But thanks for the explanation - some of the legacy stuff I am very familiar with.
I still have a few things to try so I'll keep you posted

storm pier
#

I'm not sure how Azure DevOps pipes authenticate using MSBuild deployments. That might be what you need to do. Otherwise, the Azure CLI could be easier to use since it's newer and documenteder

pale roost
#

OK some progress - I think I was bumping into the limits of Azures Free F1 App Service Plan.
However, I was able to publish V13 to the same plan:
https://umboostrap-v13-2024-06-24.azurewebsites.net/

Umbootstrap

UmBootstrap is an Umbraco Website Starter Kit using Bootstrap Templates and a comprehensive Component Library all available for you to use in your projects

#

So I ran a GitHub Actions CI/CD to a paid plan and this built and deployed the V14 with no errors.

Although it will not run on the server.
I am looking into why.

storm pier
#

Total duration 57m? The actual process takes seconds...

#

The app not running could be due to many things. For me, the most common are

  • Can't reach the database
  • Won't start because of Umbraco Runtime Mode validations
  • Old DLL files lying around from previous deploy that should have been removed
  • appSettings.x.json wasn't deployed
#

All of these should be findable in the Umbraco logs on the deployment. And if Umbraco didn't even start, there could be aspnetcore stdout logs

#

Not sure I've runbraco on an F1. But I think I have.