[McpServerToolType] class does not support dependency injection for constructors with parameters

[JeffreySu]

Describe the bug
When [McpServerToolType] class has an constructors with arguments need to be dependency injected, it will throw "Cannot resolve scoped service 'xxx' from root provider." when the function was been called by MCP.

To Reproduce
Steps to reproduce the behavior:
I forked this project and built a branch for the Test: https://github.com/JeffreySu/mcp-csharp-sdk/tree/DI-Error-Test/samples/AspNetCoreSseServer

You can run this project and add the Server to a host(like Cursor), then launch "Echo" function, then you can see the error

Expected behavior
Constructors with arguments should be well supported.

Logs

Additional context
For this test project, I added a new class named MyData, and added it to DI register progress:

Then add MyData as a parameter to ctor. of EchoTool class:

[JeffreySu]

I also created a simple project to reproduce this problem, but there was no reply yet: #114 (comment)

[stephentoub]

I assume it's only for scoped services that you're having troubles? If so, that's likely #198.

[JeffreySu]

I assume it's only for scoped services that you're having troubles? If so, that's likely #198.

I cannot sure if it's the sample problem. But I found the point:

https://github.com/JeffreySu/mcp-csharp-sdk/blob/343f0e0107e766eeaaad74a5bf0de0fc129d1325/src/ModelContextProtocol/Configuration/McpServerBuilderExtensions.cs#L44-L44

Here just support for AddSingleton, so when the class needs to be scoped as AddScoped, it wouldn't be found.

And when I cry to change the AddSingleton in source code, an other error raised when the console launch:

So here is the problem: how could AddTools<> and WithToolsFromAssembly() and other functions support for AddScoped?

PS: I re-read the reply of #198, maybe the source of the problem is the same, but the scenarios are different and complicated. In many scenarios, we want to share this class, and hope that this class can work in the system as AddScroped. As a base library, I think it needs to take into account various usage scenarios.

[JeffreySu]

@stephentoub Are there any current plans to support it?

BTW: at present, the Nuget package and the main-branch code seem to be out of sync, causing a lot of debugging trouble, can we consider synchronization processing, like using CI/CD ?

[JeffreySu]

@stephentoub Thank you, I tested with source code is successes, but when I use nuget package is faild with another error:

Does Nuget package out of sync with the source code?

[stephentoub]

We don't publish a nuget package for every commit. As such, the nuget package invariably lags. The package doesn't yet include #276.

[JeffreySu]

@stephentoub Okay, that makes sense, but it's important that master or some distribution branch and Nuget package are synchronized, otherwise the debugger will get very messy, and we've already wasted 2 days on this.

[stephentoub]

otherwise the debugger will get very messy

Can you elaborate on this? Why is the debugger impacted by the current state of the repo? The source you step into when using the nuget should be the source it was built from, not whatever is current in main.

[JeffreySu]

otherwise the debugger will get very messy

Can you elaborate on this? Why is the debugger impacted by the current state of the repo? The source you step into when using the nuget should be the source it was built from, not whatever is current in main.

During the debugging process, it is often necessary to look for the source code (the source code in a dll). Directly using the decompiled source code in the dll is certainly a way, but since it has been compiled, you cannot guarantee that it is the original one, and you cannot modify it to do more tests(of course, needs to relate source code, and it's not so easy). So another approach is to Fork the source code on GitHub locally, and then directly set breakpoints in the source code and associate them (the debug program still uses the dll of Nuget package), then we can do some tests in source code. But if the source code(from GitHub) is not the same as Nuget package, This kind of test is meaningless.

Therefore, there needs to be a place that can provide a copy of the source code exactly the same as Nuget package, such as creating a Tag/Release, or directly use CI/CD to ensure that the code entering main will automatically publish the Nuget package directly.

[stephentoub]

Directly using the decompiled source code in the dll is certainly a way

That shouldn't be necessary... source link should enable mapping to the exact actual source from which it was built.
https://learn.microsoft.com/en-us/visualstudio/debugger/how-to-improve-diagnostics-debugging-with-sourcelink?view=vs-2022

@jeffhandley / @eiriktsarpalis, if we don't already have source link configured, can we do so?