Users

All Posts (5)

avatar

scheived

API endpoints can't be edited using VS Vode

avatar
avatar
avatar
avatar
avatar

Editing an API endpoint using VS Code and PSU Extension doesn't work. When creating an API endpoint I tried supplying a Path: testendpoint.ps1. However in vs code the file it seems to be editing is not the file live on powershell universal. How is this supposed to work?

VS Code extension: editing a file-backed API endpoint saves to the wrong path (.universal prefix dropped)

avatar
avatar
avatar

I can't get edit to work for api endpoint through vs code

VSCode extension for PowerShell Universal, anybody using it?

avatar
avatar
avatar
avatar
avatar

I've used VS Code, the api endpoints are saved differantly on PSU it seems the extension can no longer edit them.

VS Code extension: editing a file-backed API endpoint saves to the wrong path (.universal prefix dropped)

avatar
avatar
avatar

Title: VS Code extension: editing a file-backed API endpoint saves to the wrong path (.universal prefix dropped)

## Summary

In the PowerShell Universal VS Code extension 2026.2.3, using the per-endpoint Edit action on an API endpoint backed by an external script file (-Path) opens and saves the file resolved against the repository root instead of the .universal directory where the runtime actually stores/executes it. Edits are written to the wrong location and never reach the running endpoint — the save silently has no effect.

## Environment

- PowerShell Universal server: 2026.2.3

- VS Code extension: ironmansoftware.powershell-universal 2026.2.3

- Windows; repository at C:\ProgramData\UniversalAutomation\Repository (config-as-code, git-backed)

## Steps to reproduce

1. In the admin UI, create a file-backed endpoint via the Path parameter — URL /pathtest, Path pathtest.ps1. PSU creates ...\Repository\.universal\pathtest.ps1 and stores path = "pathtest.ps1".

2. In VS Code, use the endpoint's Edit action to open pathtest.

3. Modify the code and save.

4. Call GET /api/pathtest.

## Expected

Changes are written to .universal\pathtest.ps1 and, after a configuration reload, the endpoint returns the updated output.

## Actual

- Edit opens/saves a file at the repo root (...\Repository\pathtest.ps1) — a different file from the one the runtime reads.

- The endpoint keeps serving the original code; the edit is silently lost.

- Confirmation: writing directly to .universal\pathtest.ps1 does update the endpoint after reload, proving the runtime file is the .universal copy while Edit targets the repo root.

## Root cause (from the extension code)

- getEditableEndpointPath() returns endpoint.path (e.g. "pathtest.ps1") with no .universal prefix.

- editResource() sets configurationPath = resourcePath for endpoints (unlike scripts, which use getScriptConfigurationPath() with a base folder), then opens createConnectionFileUri(profile, configurationPath).

- The psu:// filesystem provider calls getFileContent(toRelativePath(uri)) -> GET /api/v1/configuration/content/pathtest.ps1, relative to the repo root — not .universal.

The stored path is .universal-relative (runtime), but the extension treats it as repo-root relative (editor); the two resolve to different files.

## Related symptoms

- Inline endpoints (path = null) throw "Endpoint '/api/x' does not have a configuration file path." on Edit.

- A file-backed endpoint whose -Path doesn't match a real file (e.g. -Path "/gam/get_userinfo" when the file is gam/Get_user_info.ps1) is likewise unopenable.

## Impact

Per-endpoint editing of file-backed API endpoints from VS Code does not work — edits appear to succeed but are discarded.

## Suggested fix

Resolve an endpoint's editable path against the .universal directory (the base the runtime uses for -Path), consistent with how scripts resolve via a base folder — e.g. have getEditableEndpointPath()/editResource() prefix .universal/ (or use fullPath) for endpoint resources.

Webpage not responding after upgrade

avatar
avatar
avatar
Product: PowerShell Universal

I’m upgrading from 5.5.4 to 5.6.13. It says it’s successful but after I run the MSI the webpage no longer responds. I don’t see any additional steps on the docs under upgrade what more needs to be done?

1 - 5 of 5 items