When a file is opened through WebDav the extension crashes

[J0F3]

When a PowerShell File is opened through a WebDav Path (e.g SharePoint Library access through Windows Explorer) the extension crashes with the following error in the EditorServices.log:

FATAL UNHANDLED EXCEPTION:

System.UriFormatException: Invalid URI: The hostname could not be parsed.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Uri..ctor(String uriString)
   at Microsoft.PowerShell.EditorServices.Workspace.ResolveFilePath(String filePath)
   at Microsoft.PowerShell.EditorServices.Workspace.GetFileBuffer(String filePath, String initialBuffer)
   at Microsoft.PowerShell.EditorServices.Host.LanguageServer.HandleDidOpenTextDocumentNotification(DidOpenTextDocumentNotification openParams, EditorSession editorSession, EventContext eventContext)
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher`1.<>c__DisplayClass4`1.<AddEventHandler>b__3(Message eventMessage, TSession session, MessageWriter messageWriter)
   at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher`1.<DispatchMessage>d__6.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PowerShell.EditorServices.Host.LanguageServer.<ProcessMessage>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PowerShell.EditorServices.Host.MessageLoop.<ListenForMessages>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PowerShell.EditorServices.Host.MessageLoop.<StartMessageLoop>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Nito.AsyncEx.AsyncContext.<>c__DisplayClass3.<Run>b__1(Task t)
   at System.Threading.Tasks.ContinuationTaskFromTask.InnerInvoke()
   at System.Threading.Tasks.Task.Execute()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Nito.AsyncEx.AsyncContext.Run(Func`1 action)
   at Microsoft.PowerShell.EditorServices.Host.MessageLoop.Start()
   at Microsoft.PowerShell.EditorServices.Host.Program.Main(String[] args)

[daviwil]

Thanks for the report, JOF3! Can you also give me the scheme for the file path that was used? It should be just above the stack trace you copied in the log file. I'll need to add another case in the path validator to allow it.

[J0F3]

Sure. The file path is like the following:
"file://xyz.sharepoint.com%40ssl/DavWWWRoot/sites/Documents/PS%20Scripts/New-VM.ps1"

[daviwil]

Thank you! I'll get this fixed.

[kilasuit]

There are some considerable issues with opening files from a SharePoint based WebDAV folder when the SharePoint Site is on https not http

Key crux is this against SharePoint Online or on premises? As that makes the difference between being able to do this easily or not due to the different auth in place.

[J0F3]

Cool! Thank you!
In my case it is against SharePoint Online and using https.

[kilasuit]

Also are you on Mac/Windows?

If windows do you have the site marked as a mapped drive? If not you'll need to get that down before you can work with it.

Will try and dig out an article explaining it in more detail but will be late on this evening as I'm off to the London PowerShell User Group tonight

[J0F3]

I am on Windows (Windows 10 with November Update)

I have just tested with a mapped drive. This way it works and the path in the EditorServices.log is like this: "uri": "file:///z%3A/New-VM.ps1"

So the mapped drive is the solution/workaround for this.(?) But I think the extension should not just fail if the file is opened without the mapped drive. Maybe it makes sense that a message is displayed that the extension does not work with the current path

[dfinke]

Don't know if this may help. A new release if code is out with this fix

Webdav network drive not work

[daviwil]

Path validation in PowerShell Editor Services still needs to be fixed so that the language service doesn't crash when a WebDAV path is opened.

I agree @J0F3, the extension shouldn't fail when such a path is opened. I'll try to get a fix out for that next week.

[daviwil]

Hey @J0F3, do you still see this issue when trying to load WebDav files? I apologize it's taken me this long to get back to it.

[J0F3]

Hey @daviwil, No problem. I have just tested it and it unfortunately still happens.

[ERROR] - Method "CurrentDomain_UnhandledException" at line 125 of C:\projects\powershelleditorservices\src\PowerShellEditorServices.Host\Program.cs

System.AggregateException: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.UriFormatException: Invalid URI: The hostname could not be parsed.

(PowerShell Editor Services Host v0.4.2.264 and Version 0.10.10 of VS Code)

[daviwil]

Thanks for confirming, I'll have a look and see if I can do something about this for the 0.5.0 release.

[daviwil]

It looks like the problem here is the odd @ssl suffix in the SharePoint file URI. .NET's System.Uri class considers this invalid so it throws an exception when being parsed. I think I'm going to need to come up with a more general solution for this anyway which doesn't require parsing file paths in the language service.

The only reason I need to parse the paths is so that I can resolve referenced files (through dot-sourcing, etc). My plan is to put that responsibility on the editor, but that will take a bit more work. I'll make this happen for 0.6.

[SydneyhSmith]

We recently published an update to our extension which has addressed a number of underlying uri issues, would you mind giving it a try and letting us know if you are still hitting this issue?

[ghost]

This issue is being closed as inactive, if this issue is still occurring it will be re-opened