https://discord.umbraco.com logo
Join Discord
Powered by
V14 Web Deploy to Azure Web App fails
# help-with-umbraco
d
Exceeding 260 character limit for paths in Windows
Has anyone succesfully web deployed a V14 to an Azure Web app? I seem to be running into a path length error e.g. C:\Users\deanl\.nuget\packages\umbraco.cms.staticassets\14.0.0\staticwebassets\umbraco\backoffice\packages\documents\documents\user-permissions\input-document-granular-user-permission\input-document-granular-user-permission.element.js Is 261 characters where the limit is 260. Some are 290+ even moving the project to the root C: I have set the Local Group Policy Editor to Enable Win32 long paths. but to no avail. I thought the files are stored in PubTmp\Out\ whilst publishing but may be wrong. Anyway, if you have successfully published as above please let me know so I can look for other issues.
k
From Azure DevOps it works fine. Self-hosted build agent running Windows. Normal aspnetcore pipe steps with restore, build, publish, publish-artifact. Haven't actually done the deployment step, but I'm confident that will work. You are also nowhere near Azure in your error above. 🙂 By default the publish operations publishes to 
PubTmp
, that's correct. From within Visual Studio 2022 Preview I can't publish, it complains about the below. But the real root cause is not a path length limitation, I can manually create the missing files. I'm writing this off as a Preview problem. > "Unable to copy file "C:\Users\...\.nuget\packages\umbraco.cms.staticassets\14.0.0\staticwebassets\umbraco\backoffice\packages\language\collection\views\table\column-layouts\entity-actions\language-table-entity-actions-column-layout.element.d.ts" to "E:\...\obj\Debug\net8.0\win-x64\PubTmp\Out\wwwroot\umbraco\backoffice\packages\language\collection\views\table\column-layouts\entity-actions\language-table-entity-actions-column-layout.element.d.ts". Could not find a part of the path 'E:\...\obj\Debug\net8.0\win-x64\PubTmp\Out\wwwroot\umbraco\backoffice\packages\language\collection\views\table\column-layouts\entity-actions\language-table-entity-actions-column-layout.element.d.ts'.
I think you need to get rid of the path limitation... too old Windows? Maybe time to ditch XP? I've heard great things about Vista!
d
Thanks for checking @kdx-perbol I'm running W11 and the first thing I tried was removing the limitation. I've been trying CI/CD from GitHub Actions as well but no luck. If I have time I can try Dev Ops but just wondered if anyone has succesfully pushed to an Azure Web App. I assume HQ has with Cloud?
k
I've successfully pushed to an Azure App Service (Windows) now, using Azure DevOps build & release pipes.
dotnet publish
locally works fine as well.
How are you publishing "to Azure"? VS?
If you try 
dotnet publish
, do you get the same errors?
s
What happens when you do 
dotnet publish -c Release -o  .\release
in the directory where your sln file is?
d
I will try that
s
Perfect, then the problem doesn't seem to be on your machine at least. Now.. don't ask me for additional steps, it's been 8 years since I last deployed anything to an azure website 🙈
I see your user path is different now, so I believe the error message might be coming from the remote server, maybe? No idea if you can tell that one to accept long paths..
d
I am trying in VS Code and got this
Copy code
All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\8.0.300\Current\SolutionFile\ImportAfter\Microsoft.NET.Sdk.Solution.targets(36,5): warning NETSDK1194: The "--out
put" option isn't supported when building a solution. Specifying a solution-level output path results in all projects copying outputs to the 
same directory, which can lead to inconsistent builds. [C:\Users\deanl\source\repos\xDotNetTemplate\UmBootstrap-V14-01\UmBootstrap-V14-01.sln
]
k
I'm still wondering how you're publishing to Azure, and what error messages (if any) you are getting. What makes you think you are exceeding a 260 character limit?
The warning is correct, don't do that. Publish the Umbraco project, that's what you will deploy. 🙂
d
This was trying to publish the 'release' dir. I have been publishing the project in VS with web deploy or github actions with no success. Same with VS Code, deploying the project. Articles, Forums, CoPilot all say the path is too long for both windows and Azure. I have enabled long paths on windows.
Lots of these:
Copy code
Severity    Code    Description    Project    File    Line    Suppression State
Error        Unable to copy file "C:\Users\deanl\.nuget\packages\umbraco.cms.staticassets\14.0.0\staticwebassets\umbraco\backoffice\packages\block\block-grid\property-editors\block-grid-group-configuration\property-editor-ui-block-grid-group-configuration.element.js" to "C:\Users\deanl\source\repos\xDotNetTemplate\UmBootstrap-V14-01\UmBootstrap-V14-01\obj\Release\net8.0\PubTmp\Out\wwwroot\umbraco\backoffice\packages\block\block-grid\property-editors\block-grid-group-configuration\property-editor-ui-block-grid-group-configuration.element.js". Could not find a part of the path 'C:\Users\deanl\source\repos\xDotNetTemplate\UmBootstrap-V14-01\UmBootstrap-V14-01\obj\Release\net8.0\PubTmp\Out\wwwroot\umbraco\backoffice\packages\block\block-grid\property-editors\block-grid-group-configuration\property-editor-ui-block-grid-group-configuration.element.js'.    UmBootstrap-V14-01        0
k
That's the error I'm getting on publish from inside VS, see above.
I don't get that from 
dotnet publish
and you don't seem to either?
You should be able to publish the output from 
dotnet publish
to Azure. (But don't publish the whole solution to the same folder, just publish the Umbraco project.)
How are you deploying from VS Code, and what error are you getting then?
This may be a "path too long" problem, but not with Windows. If you try to perform the file copy from the error message manually, I'm sure it will work, just as it does for me.
But since the 
dotnet publish
in your screenshot worked, I'd just deploy to Azure some other way. I've only ever used "web publish from VS" as a test thing anyway.
"Path is too long for Azure" makes no sense, since you're not deploying anything (at least in your screenshots), you're publishing to your local file system. Also, I can guarantee you Azure Windows app service plans do not have a path length limitation. 🙂
d
It does but that's another story - it's basically IIS after all
k
Nope. My Umbraco 14 deploy works fine.
d
I have tried to deploy the dotnet publish twice but trying again
k
How are you trying to deploy it, and what error are you getting?
d
Using the Azure web extension and no error just socket hung up
k
Don't know what that is. Is it an extension to VS? Is there no output from it?
j
You've definitely got long paths enabled?
k
I get the same error from inside VS when using the "VS web publish". But I can create the folder structure manually. Seems like a VS bug of some kind.
d
sigh 'You do not have permission to view this directory or page.'
k
That looks like a VSCode extension? What does it do under the hood, msdeploy?
j
Interesting... Long paths is not a sure fire thing in Windows. Any given Win32 app doesn't have to support long paths because it's not technically part of the spec (hence why it's opt in).
I wonder if something is being called that simply isn't compatible.
d
I'm with @kdx-perbol and not convinced that is the issue Although they are very long! Way past the 260 char limit
k
Yeah, feels like it. Umbraco 13 projects work though.
d
I've been using web deploy to Azure web apps since V7 🙂
k
From VS you mean?
d
Yes
j
I made some fuss about this a while ago when I realised that on v14 Umbraco will not build on Windows OOTB.
k
Does it work if you use a publish profile that publishes to disk @Dean Leigh ?
d
I followed @Sebastiaan's advice and then tried to publish what it had published to disk to Azure
k
Well, that was a publish of the entire solution into the same output folder, so that might cause the error you're seeing in Azure because of the reason in the warning when you publish. If you do what I suggested from the start (just 
dotnet publish
the Umbraco project and deploy that) it would probably work. But I was wondering if the publish process in VS has the same bug when publishing to disk as it does when publishing to the web.
d
I did try 
dotnet publish
as you suggested early on as well as @Sebastiaan's suggestion
k
dotnet publish
on the Umbraco project and a subsequent deploy of that should work. Maybe the VSCode extension is doing something wrong? If you look at the Azure 
wwwroot
, does it look like it should?
The standard Azure DevOps release pipes use 
Microsoft Web Deploy V3\msdeploy.exe
, so you should be able to do that manually as well.
d
OK so I have C:\Users\deanl\source\repos\xDotNetTemplate\UmBootstrap-V14-01\UmBootstrap-V14-01\bin\Release\net8.0\publish\
k
msdeploy.exe
in my release pipe takes a zip file, I'm guessing you have a standard web project structure instead?
I'm wondering if maybe 
msdeploy.exe
and 
msdeploy.axd
on Azure does more than just copy some files. I'm guessing it configures IIS and stuff as well. But your VSCode extension should do that as well.
d
VS will deply a zip as well
k
And it couldn't be the same root cause as the publish copy fail during VS web deploy?
d
Oh well I'm calling it a night and will try again tomorrow. I have submitted an issue but would like to hear from HQ if they also published to Azure web apps from VS
j
I've just tried to replicate with the VS Code extension. It silently fails part way trhough a deployment for me.
k
Ha. It works when using a folder publish profile in VS.
d
k
I doubt GitHub Actions would fail because of the VS web deploy long path bug. To me it seems the only actual problems you've had are the VS web publish long path bug, and the VSCode extension failing for some reason sometimes, and currently producing an "unbrowsable" Azure web site.
If you turn that into a zip and 
msdeploy
it, you're done. 🙂
d
OK I will give that a try tomm
Thanks for your help
Goodnight @Jason and @kdx-perbol
k
I think I see why the VS folder publish works while the VS web publish doesn't @Jason . The web publish uses some ancient stuff, 
csc.exe
from the VS installation and then the .NET SDK Target files with asset copying. The folder publish command-line I can't see, but judging by the speed and output it seems to just 
dotnet publish
.
The 
csc
command line is 63k chars long... for a 
dotnet new umbraco
project
j
Curiously, web deploy via VS worked fine for me.
k
What the actual.
This felt like it could be the problem: https://developercommunity.visualstudio.com/t/allow-building-running-and-debugging-a-net-applica/351628 which says the Roslyn executables and compilers don't opt in because of legacy reasons.
What is the commandline when you VS web publish? For me it´s 
C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\Roslyn\csc.exe
and then 62000 characters of flags, options, source files, SDK references etc.
What do non-Windows users do? They don't have this problem. Surely they just 
dotnet publish
and then some Azure command-line deploy application? Couldn't we use that on Windows?
j
TBH, I rarely deploy outside of a CI/CD pipeline now and will be doing builds and deployments on Linux even though I develop on Windows.
At least for me, v14 will deploy to Azure OOTB in VS using Web Deploy (right click/publish) (apart from Azure's new mad auth setting you jace to enabel before you can actually deploy).
k
But what is the command-line it uses to do it?
j
Same as yours by the looks.
k
Welp. Did you simply happen to not have 2long4roslyn paths?
It does list the files on which it fails, and those are the longest path names, from a quick look.
j
Ah, maybe.
Haha, yeah
It's that.
> Severity Code Description Project File Line Suppression State > Error Unable to copy file "C:\Users\jason\.nuget\packages\umbraco.cms.staticassets\14.0.0\staticwebassets\umbraco\backoffice\packages\block\block\workspace\views\edit\block-workspace-view-edit-properties.element.js" to "D:\Code\Burn\The Quick Brown Fox Jumped Over The Lazy Dog\Peter Piper Picked A Peck Of Pickled Peppers\Fourteen\Fourteen.Web\obj\Release\net8.0\PubTmp\Out\wwwroot\umbraco\backoffice\packages\block\block\workspace\views\edit\block-workspace-view-edit-properties.element.js". Could not find a part of the path 'D:\Code\Burn\The Quick Brown Fox Jumped Over The Lazy Dog\Peter Piper Picked A Peck Of Pickled Peppers\Fourteen\Fourteen.Web\obj\Release\net8.0\PubTmp\Out\wwwroot\umbraco\backoffice\packages\block\block\workspace\views\edit\block-workspace-view-edit-properties.element.js'. Fourteen.Web 0
So, next question is, given that there's nothing special about Azure Web Apps, would we get the same problem with a bog standard IIS deployment.
k
So, mystery solved. But is there an easy way for the OP to workaround? Folder publish profile + msdeploy is not super easy...
Yeah, the web publish hasn't even gotten to the Azure part when this happens. Only reason IIS would work is if that doesn't use 
csc.exe
for some reason.
j
Right.
I'm going to take this back to HQ and see if I can get some more brains on this.
There was talk of bundling JS/TS files to get file paths down.
As it stands, V14 can not be built and deployed from Visual Studio OOTB which is not ideal.
k
HQ all use macbooks with lots of stickers, they would laugh at us Windows dinosaurs wanting to get pampered.
Next thing we'll want support for 8.3 filenames as well.
"Could it please just be one UMBRAC~1.JS? Then I could also deploy it using floppy disks!"
d
@kdx-perbol I draw the line at putting a sticker over the Windows logo on my Surface Book 😂
w
Ok I suggest you deploy to a Linux based Azure WebApp as that won’t have the filepath issue, as I assume your deploying to a windows based one @Dean Leigh AFAIK Umbraco Cloud with their Azure infrastructure probably uses Linux based WebApps and hence not run into this problem as of yet.
d
I may give that a try but as @Jason said "As it stands, V14 can not be built and deployed from Visual Studio OOTB which is not ideal.". At the end of the day I'm doing this to improve Umbraco, I had already submitted this as an issue so hopefully HQ will recognise many users will "Right Click > Publish" to Azure Web Apps on Windows
s
I have a little more time today, so I'll reproduce. But yeah, looks like paths definitely need to be shortened.
d
Thanks @Sebastiaan although it could be an excuse for me to get into Raspberry Pi 🥰
k
@Dean Leigh and @Sebastiaan , please note that this was never a deployment/hosting/Azure issue. The only actual problem was VS web publish using csc to publish, which can fail because of the non-long-path-Roslyn-optin, so @Dean Leigh never got to the deployment step. Introducing Linux or RPi for hosting solves nothing here. U14 can be successfully hosted on Windows Azure App Services without any problems.
The only long-term solution is the sticker on the Surface logo.
s
Got it! Yes well, hosting on Pi involves doing a 
dotnet publish
which works!
d
Never!
s
Anyway, we're aware, HQ is working on solutions, mainly bundling the frontend assets but we're looking to see if we can help sooner with some of the longer paths we have at the moment, like this one reported here.
k
@Dean Leigh , @Jason got VS web publish working for 14 by using really short root paths. You should be able to do the same as a workaround.
j
That's a nice workaround for anyone that comes across this. Also, keeping project directory structure short is important too. In the meantime, I've revisted the discussion with HQ on teh MVP slack where other options are being discussed, so watch this space. Given that Umbraco has moved more towards the dotnet CLI, it might be an idea as a general recommendation to use az cli for deployments: https://learn.microsoft.com/en-us/azure/app-service/quickstart-dotnetcore?tabs=net80&pivots=development-environment-cli
x
Hey, I've ran in to the same issues as described here. Is there now a way to publish using the default visual studio publish profile thing?
k
Afaik only using the super-short-path-name workaround.
136 Views
PreviousNext
Powered by