DI Support

[Simonl9l]

Migrating from OmniSharp - it came with a DI support, via .WithServices() and the Handlers were setup similarly with DI, such that the underlying services, that the LSP wraps, could be injected into the handlers.

Do you have any recommendations on how to achieve this?

I'll need a DI service container either way as that is the only way to get to the afore mentioned underlying services as they in turn are very DI dependent.

At 10,000ft I'd figure one needs to:

• Override LanguageServer to make it DI aware and override the Run to build the container before delegation to the base.
  • This can also expose a WithServices delegate such that the other services can be registered.
  • However given the private constructor this eliminate this path of extensibility.
• Create a generic proxy object that either derived from IJsonHandler that takes the type of the handler as the generic template, and the server as the constructor arg.
  • This can then register the actual Handler implementation in the DI Container (likely as a singleton), and delegate to the underlying
  • Its Handle implementations retrieve the actual handler from the DI container and delegate the Handle calls.

In this way the handler handler will get the request series injected.

If you think there is an appetite to accept an PR for this I may consider undertaking the work to build this into the base LanguageServer.

[CppCXY]

When I first implemented it, I considered whether Dependency Injection (DI) was necessary. I concluded it wasn't, because supporting DI might complicate Ahead-of-Time (AOT) compilation, and manual creation could avoid DI altogether. I’ve already built a real-world server based on this approach.
However, if you prefer using DI and can resolve AOT-related challenges, I recommend directly using the JSON-related classes I wrote instead of insisting on my LanguageServer class.

[Simonl9l]

Hi @CppCXY thanks for the followup!

AFAIK - with net9.0 there are "no" DI implications for AoT - this is the 99.9% reason for switching to your framework - we'd rather our language compiler remains private and not de-compileable from the IL of a non AoT target.

I generally like what you have done with the Language server and base handler class abstractions via the IJsonHandler and the RegisterHandler to hook up the pieces/parts, and figure a DI proxy can look something like this:

public class HandlerDiProxy<THandler> : IHandlerDiProxy, IJsonHandler where THandler : class, IJsonHandler
{
    private THandler? _handler;
    public void RegisterHandler(LSPCommunicationBase lspCommunication)
    {
        _handler?.RegisterHandler(lspCommunication);
    }

    public void RegisterCapability(ServerCapabilities serverCapabilities, ClientCapabilities clientCapabilities)
    {
        _handler?.RegisterCapability(serverCapabilities, clientCapabilities);
    }

    public void RegisterDynamicCapability(LanguageServer server, ClientCapabilities clientCapabilities)
    {
        _handler?.RegisterDynamicCapability(server, clientCapabilities);
    }

    public void Init(IServiceProvider services)
    {
        _handler = services.GetRequiredService<THandler>();
    }
}

With a simple interface so passing the built service provider:

public interface IHandlerDiProxy
{
    void Init(IServiceProvider services);
}

The minimal changes then the the Language server look something like this:

public class LanguageServer : LSPCommunicationBase
{
     ...

    private ServiceCollection Services { get; set; } = new();

    public LSPCommunicationBase AddHandler<T>() where T: class, IJsonHandler
    {
        Services.AddSingleton<T>();

        var handler = new HandlerDiProxy<T>();
        return AddHandler(handler);
    }

    public override Task Run()
    {
        // add language server as a singleton so it can be DI'd into Handlers
        Services.AddSingleton(this);

        // build Service Provider
        using var provider = Services.BuildServiceProvider();

        //Init each handler so it instantiates the handler implementation via DI
        foreach (var handler in Handlers)
        {
            if (handler is IHandlerDiProxy handlerDiProxy)
            {
                handlerDiProxy.Init(provider);
            }
        }
        return base.Run();
    }

    // entry point to allow dependent services to be registered
    public LanguageServer WithServices(Action<IServiceCollection> servicesAction)
    {
        servicesAction(Services);
        return this;
    }


   ...
}

Is Run the best place to hook it all up?

From a Program.cs one can the use it like this:

   var ls = LanguageServer.From(input, output);
        ls.OnInitialize((c, s) =>
        {
            s.Name = "myLSp";
            s.Version = "1.0.0";
            Console.Error.WriteLine("initialize");
            return Task.CompletedTask;
        });
        ls.OnInitialized(async (c) =>
        {
            await Console.Error.WriteLineAsync("initialized");
            var r = await ls.Client.GetConfiguration(new ConfigurationParams
            {
                Items =
                [
                    new ConfigurationItem
                    {
                        Section = "files"
                    }
                ]
            }, CancellationToken.None);
    
            Console.Error.WriteLine(r);
        });

        ls.AddHandler<TextDocumentSyncHandler>();
        ls.AddHandler<SemanticTokensHandler>();
        ls.WithServices(
            services =>
            {
                services.AddSingleton<{ImyInternalInterface}, {InternalImplementaiton}>();
            }
        );
        
        await ls.Run();

Any thoughts on this approach - Amy I missing anything - I'm still migrating my OmniSharp code so have not as yet tested this?

It should in no-way would impact on any _already built a real-world server(s) - but just be an extension of folks can go either way! All the effort that has gone into the JsonSerializerContext for AoT support has been noted.

TBH I don't follow your _ I recommend directly using the JSON-related classes I wrote instead of insisting on my LanguageServer class_ , as a LanguageServer construct of some kind is still needed. It seems sensible to extend that, than reuse the innards a different way?

I have some questions related to how to register Schema/Patterns related to the TextDocumentSyncHandler (at least from an OmniSharp perspective as a DocumentSelector as part of TextDocumentSyncOptions, but am trying to collect a full set than piece/part, and can post them as other questions on discussions.

More broadly - Whist I currently see limited forks, my hope is that this repo grows a community, and that you are intending to continue to support this into the future, as and when the protocol evolves, or supporting other use cases like DI, and as of now is seems pretty stable, and you have support for 3.18. Outside of that a regression test harness vs. the spec would probably be beneficial.

[CppCXY]

If you can test this method to pass AOT compilation and run correctly, I am happy to accept a PR as long as it does not change the basic API.

More broadly - Whist I currently see limited forks, my hope is that this repo grows a community, and that you are intending to continue to support this into the future, as and when the protocol evolves, or supporting other use cases like DI, and as of now is seems pretty stable, and you have support for 3.18. Outside of that a regression test harness vs. the spec would probably be beneficial.

That's a great suggestion, but my current spare time is primarily spent maintaining my language server written in Rust. It would be even better if you could help me implement these tests

[Simonl9l]

If you can test this method to pass AOT compilation and run correctly, I am happy to accept a PR as long as it does not change the basic API.

I have the basics working, but am not at a point where I can submit a PR given other deadlines. I'll get back to you in a while.

I do have it running as an AoT build, and zero changes to the basic API - just extensions to meet the need, but did need to add <TrimmerRootAssembly Include="myAssembly"/> into the csproj.

I note that:

• with the Test project, that the Command Line parser is not AoT compatible, so am using ConsoleAppFramework here - this is an AoT compatible CLI framework that uses code generation.
• that the LSPCommunicationBase is currently handing its own CancelationContext. I'd suggest that be moved outside and be the responsibility of the host (CLI) and have Run just take a CancelationToken - of note here ConsoleAppFramework has SIGTERM / <Crtl-C> cancelation built-in.

[CppCXY]

You can do anything, I just hope not to change the existing API