CSharp API Endpoints
Added the plugin yesterday and built some generic endpoints, chased down some issues I was having. I don't expect this to impact the plugins functionality, but I'm able to workaround these for the time being.
PSU Version: 2026.2.2 (also found in 2026.2.4 DLLs)
Host: Windows Server 2025
Web: IIS
DB: SQL
Component: PowerShellUniversal.Language.CSharp
Finding #1 - ApiRequest.Roles is nested under nullable parent SecurityContext and is List<string> not string[]
// expected usage, from current documentation var roles = request.Roles ?? Array.Empty<string>(); // corrected, working var roles = request.SecurityContext?.Roles ?? new List<string>();
Finding #2 - ref/using extraction match literal CRLF. LF-only lines never hit. CSharpExecutionService extracts directives with:
private readonly Regex _reference = new Regex("#ref (.*)\r\n");
private readonly Regex _using = new Regex("#using (.*)\r\n");
Finding #3 - Directive-extraction is not anchored and will hit on comments and string literals. Reference #2.
Finding #4 - Matched `#using` directives are not terminated with `;`. Documentation shows code snippets without trailing `;`
// reproduce with #ref System.Collections #using System.Collections.Generic var roles = request.SecurityContext?.Roles ?? new List<string>(); // corrected with trailing ; on using directive
All Comments (6)
Hello tomtaylor,
Thank you for the detailed report and for documenting the workarounds you identified.
The four findings are specific enough for us to validate independently, so I would like to reproduce them separately rather than make assumptions based solely on the implementation details.
I will review:
* The current `ApiRequest` / `SecurityContext.Roles` contract against the documented example.
* `#ref` and `#using` behavior with CRLF versus LF line endings.
* Whether directive extraction can also match comments or string literals.
* Whether `#using` requires a trailing semicolon and how that compares with the current documentation.
I will also compare the behavior across the relevant PSU versions so we can determine which findings are documentation discrepancies and which, if reproduced, represent product behavior that requires further review.
Thank you again for providing such a focused reproduction.
Best regards,
Ruben Tapia
Hello tomtaylor,
Thank you again for the detailed report.
We completed our internal validation and were able to reproduce the reported C# endpoint behaviors consistently across the PSU versions tested.
Based on these results, we will review the findings with our Product team to determine the appropriate next steps. We will keep you updated here as soon as we have additional information.
Best regards,
Ruben Tapia
Thanks Ruben. Appreciate the quick follow-up!
Hello @tomtaylor ,
Thank you for your patience while we reviewed these findings.
We have now reviewed the results with our Development team. The line-ending issue from finding #2 has also been identified internally, and a fix is planned for PSU 2026.3.0.
The remaining findings are also being tracked for additional review. Depending on the outcome, some of them may require product changes while others may be addressed through documentation updates.
We will keep this topic updated as we receive further information on those items.
Thank you again for the detailed report and for helping us isolate each behavior.
Best regards,
Ruben Tapia
Hello,
The fix has been implemented and is available in the latest version 2026.3.0.0 of PowerShell Universal.
Could you please confirm that this version works as expected now? We recommend testing this fix in a staging environment prior to deploying it on your production environment.
Thank you for your collaboration.
Best regards,
Maxim Robert
The first finding still stands - the documented contract for ApiRequest has not been updated. Everything else appears to be working as expected now.