Add lsp config for dotnet.

[jmoseley]

Add lsp server config for dotnet.

[github-actions]

SDK Consistency Review

I've reviewed this PR for cross-SDK consistency.

Summary

✅ No consistency issues found - This PR adds development tooling (LSP configuration) for the .NET SDK and does not modify any SDK client APIs or functionality.

Analysis

The changes add:

1. .github/lsp.json - Centralized LSP server configuration with C# language server setup
2. dotnet/dotnet-tools.json - .NET tool manifest for the csharp-ls language server

This is infrastructure/tooling for development environment support (IDE integration, code intelligence), not SDK client functionality.

Observation

The .github/lsp.json structure supports multiple language servers (it's a "lspServers" object), but currently only includes C#. While TypeScript, Python, and Go already have their native tooling:

• TypeScript: Has tsconfig.json and TypeScript language server support via standard tooling
• Python: Has pyproject.toml with Ruff and type checking configuration
• Go: Has native gopls support through standard Go tooling

If the intent is to centralize LSP configuration for all SDKs in .github/lsp.json, you might consider adding entries for the other languages in a future PR. However, since each language ecosystem already has well-established LSP tooling, this may be unnecessary.

Conclusion

This PR maintains consistency - it's adding optional development tooling that doesn't impact SDK feature parity or public APIs.

AI generated by SDK Consistency Review Agent

[Copilot]

Pull request overview

This PR adds Language Server Protocol (LSP) configuration for the dotnet/C# SDK components of the repository. It configures the csharp-ls language server to provide IDE features like intellisense, go-to-definition, and other language services for C# files.

Changes:

• Added dotnet tools manifest (dotnet/dotnet-tools.json) to declare csharp-ls as a project tool
• Added LSP configuration (.github/lsp.json) to configure how csharp-ls should be invoked for C# files

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
dotnet/dotnet-tools.json	Declares csharp-ls version 0.21.0 as a dotnet local tool for the project
.github/lsp.json	Configures LSP server to use csharp-ls for .cs files with the GitHub.Copilot.SDK.sln solution

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jmoseley]

Regarding the review comments:

Solution file path: The config uses rootPath: "dotnet" which tells the LSP tool to run from the dotnet/ subdirectory. So the paths in the config are relative to that - GitHub.Copilot.SDK.sln is correct.

packageId: For local tool manifests (dotnet-tools.json), the tool name key (csharp-ls) serves as the package identifier. The packageId field is only required when using dotnet tool install directly. This is valid dotnet-tools.json format.

rollForward: Fixed - removed the explicit false to allow default patch roll-forward behavior.

[github-actions]

SDK Consistency Review ✅

This PR adds LSP (Language Server Protocol) configuration for development tooling and does not modify any SDK client code. The changes are:

1. .github/lsp.json - LSP server configuration for C# and Go
2. dotnet/dotnet-tools.json - .NET tool manifest for the csharp-ls language server

No cross-SDK consistency issues identified. This is purely development environment setup that doesn't affect the SDK APIs, functionality, or feature parity across languages.

AI generated by SDK Consistency Review Agent

[github-actions]

Cross-SDK Consistency Review

This PR adds LSP (Language Server Protocol) configuration for development tooling, which is infrastructure rather than SDK functionality. However, there's a minor consistency gap:

Current State

• ✅ C# (dotnet): LSP configured (Roslyn Language Server)
• ✅ Go: LSP configured (gopls)
• ❌ TypeScript/Node.js: No LSP configuration
• ❌ Python: No LSP configuration

Suggestion

For a consistent developer experience across all four SDK implementations, consider adding LSP configurations for TypeScript and Python as well:

TypeScript:

"typescript": {
  "command": "typescript-language-server",
  "args": ["--stdio"],
  "fileExtensions": {
    ".ts": "typescript",
    ".tsx": "typescriptreact"
  },
  "rootUri": "nodejs"
}

Python:

"python": {
  "command": "pylsp",
  "args": [],
  "fileExtensions": {
    ".py": "python"
  },
  "rootUri": "python"
}

This would ensure all SDK contributors have equivalent IDE support regardless of which SDK they're working on. However, this is a nice-to-have rather than a critical consistency issue since it's development infrastructure, not SDK API parity.

AI generated by SDK Consistency Review Agent