feat(vscode) - Adding additional csharp lsp server functionality#8828
feat(vscode) - Adding additional csharp lsp server functionality#8828lambrianmsft wants to merge 36 commits intoAzure:ccastrotrejo/csharpLSPServerfrom
Conversation
… call times for checking child process, added options to add new codeful workflows to the project, optimzed the get-child-process.ps1 script, and finally added the overview page for codeful workflows and ability to view runs
…ded temporary shouldExtractOrUpdate method
…d to be passed as a path and added additional telemetry to capture this whenever it happens
…ger name isn't defined, we pull the default from the lsp server sdk. Disabled the create unit test from run for codeful workflows
…perience, prevent callback url from getting continuously pinged, updated sdk version
🤖 AI PR Validation ReportPR Review ResultsThank you for your submission! Here's detailed feedback on your PR title and body compliance:❌ PR Title
✅ Commit Type
❌ Risk Level
(Note: advised risk is higher than the one assigned in the PR description — please update the PR risk field and add a
|
| Section | Status | Recommendation |
|---|---|---|
| Title | ❌ | Make the title more descriptive of scope (LSP, codeful, debug, packaging) |
| Commit Type | ✅ | feature is correct |
| Risk Level | ❌ | Update to High and add risk:high label |
| What & Why | ❌ | Expand with a bulleted list of major changes and rationale |
| Impact of Change | ❌ | Document Users/Developers/System impacts and migration notes |
| Test Plan | ❌ | Mark Unit tests added/updated and list key tests; provide manual steps |
| Contributors | Add contributors (optional but recommended) | |
| Screenshots/Videos | Add screenshots for key UI changes (recommended) |
Summary / Action Items
- Update the PR title to be more specific about what changed (LSP + codeful + debug + packaging). Example:
feat(vscode): Add C# LSP & codeful workflow support (C#/.NET8) — scaffolding, debug, LSP metadata, and tooling. - Change PR Risk Level to High in the PR body and add the
risk:highlabel to the PR. - Update the Test Plan checkboxes: mark Unit tests added/updated (this PR adds many unit tests). Provide a short list of representative test file paths and confirm CI runs them. If E2E tests were added, list them; otherwise adjust checkboxes accordingly.
- Expand the "What & Why" and "Impact of Change" sections with explicit bullets covering: LSP asset additions, extension bundle bump, codeful workflow generation & Program.cs changes, debugging changes, connection insertion race fix, PowerShell script changes, caching and telemetry, packaging/build script change (package.json build:extension line), and potential user-facing behavior changes.
- Add contributor credits.
- If the PR introduces UI changes, include screenshots or short videos.
Please update the PR body (and labels) with the items above; once updated I will re-check the PR for compliance.
If you want, I can propose a full, updated PR body (with filled template) and an improved PR title for you to paste into the PR.
Note on risk: I recommend risk:high. This is higher than your PR body selection (Medium) because of the breadth and depth of changes (LSP binaries, extension bundle updates, runtime/process validation adjustments, packaging script changes, PowerShell changes, and many cross-cutting behavioral changes). Please update the risk field and add the appropriate label. Thank you!
Last updated: Wed, 11 Mar 2026 00:03:19 GMT
| } else { | ||
| // For codeless projects, build custom code functions if they exist | ||
| const customFolderExists = await fse.pathExists(path.join(logicAppNode.fsPath, libDirectory, customDirectory)); | ||
| if (customFolderExists) { |
There was a problem hiding this comment.
Shouldn't this be if !customFolderExists? Since we would build in the case where lib/custom/* doesn't already exist for codeless, i.e. not already built
| // For codeless projects, build custom code functions if they exist | ||
| const customFolderExists = await fse.pathExists(path.join(logicAppNode.fsPath, libDirectory, customDirectory)); | ||
| if (customFolderExists) { | ||
| await buildCustomCodeFunctionsProject(actionContext, logicAppNode); |
There was a problem hiding this comment.
buildCustomCodeFunctionsProject is supposed to check whether the .net project is specifically a custom code functions project before building, part of that is to check for Microsoft.Azure.Workflows.Webjobs.Sdk in the .csproj, which I don't think will exist for codeful projects. Should there be a separate function for handling building codeful?
…AppsUX into ccastrotrejo/csharpLSPServer
|
|
||
| // Find the location to insert the new workflow builder | ||
| // Look for the "Build all workflows" comment or insert before host.Run() | ||
| const buildCallRegex = /(\s*)(\/\/ Build all workflows\s*\n(?:\s*\/\/.*\n)*\s*)(.*?)(\s*host\.Run\(\);)/s; |
There was a problem hiding this comment.
Is it possible to avoid using a regex here to update Program.cs with a new workflow, and instead just overwrite Program.cs with one containing all workflows? We would need to track the workflows in a codeful project elsewhere, but we should probably avoid using regex as much as possible since it's bound to break in some cases
…to ccastrotrejo/containerExtension
…brianmsft/LogicAppsUX into ccastrotrejo/csharpLSPServer
…brianmsft/LogicAppsUX into ccastrotrejo/csharpLSPServer
…tion, update tests
…o reduce azure auth time, updated connectionTable to look if a selected connection is inside the connections.json, updated flow to prevent hanging after use connectors from azure is selected initally
…brianmsft/LogicAppsUX into ccastrotrejo/csharpLSPServer
Commit Type
Risk Level
What & Why
Adding ability to open overview page for a workflow, adding a new workflow, reducing the connection pane load time, and updating the package.
Impact of Change
Workflows runs can now be opened and new workflows can be added
Test Plan
Contributors
Screenshots/Videos