Feature Request: Support for .NET Server Execution

[foxminchan]

Is your feature request related to a problem? Please describe.
Currently, mcpb does not support launching MCP servers implemented in .NET. Many .NET MCP servers rely on the standard dotnet run workflow, which requires specifying a project file or a C# entrypoint. Without explicit support, .NET developers cannot register or execute their servers using the expected .NET CLI patterns.

Describe the solution you'd like
Add first-class support for .NET server execution, enabling:

1. Project-based execution

   dotnet run --project "Mcp.csproj"

   Here, dotnet is the entrypoint and --project "Mcp.csproj" is the argument.

2. Single-file execution (simplified)

   dotnet run app.cs

   Allowing a .cs file to act as the server entrypoint, with dotnet as the runtime command.

The goal is to let .NET servers fit naturally into the existing MCPB manifest and runtime model without extra wrappers or shell scripts.

Describe alternatives you've considered
A wrapper script (e.g., bash, PowerShell, or shell shim) could be used to invoke dotnet run, but this becomes platform-dependent and breaks the portability goals of MCP. Another alternative is pre-compiling the server, but that removes the dynamic/iterative development workflow that .NET developers typically use.

Additional context
The .NET ecosystem is increasingly adopting MCP. Having native support for .NET launch patterns would streamline development workflows, improve portability across OSes, and align MCPB with other runtimes already supported.

[joelverhagen]

My personal opinion (having worked on NuGet support in the MCP Registry), is that dotnet run --project and dotnet run app.cs should not be supported by MCPB. This would require the consumer to have the .NET SDK (compiler, NuGet, dev toolchain, etc). That is a heavy weight thing. Instead, it might make more sense to include compiled .exe/.dll (assemblies) thus only requiring the .NET runtime.

Alternatively, .NET can be compiled to native assemblies with AOT but this would bring in the platform-specific binary problem alluded to in (#63).