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?

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

So no fix yet? 🤨

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

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

Are you on Windows?

We don't use Web.config anymore

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

Why not? The

dotnet publish

solution we talked about in the other post works for the rest of us. Wasn't it just deploying to Azure you ultimately had problems with?

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...

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.

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

How exactly did you do that?

So you can publish from VS now?

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.

ps1
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:

ps1
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 🙂

Thanks @gregor.tusar 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

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.

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

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

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/

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