Some simple using statements clean up

[alwaysmiddle]

Not spectacular or meaningful change, but it's a bit of an improvement.
My main goal is ask if you are open for some larger modifications such as changing the git based change tracking with something like a RAG or local graph database like graphiti. Of course, the MCP servers can always be used together, however I am more in favor of packaging everything into one mcp server.

I appreciate some of your thoughts on this matter, thanks!

[kooshi]

I prefer to keep all nameof expressions when referencing code in strings, to maintain a compile time guarantee that the name is correct. If I were to rename one of the tools, then all strings which use its name must be updated.

[alwaysmiddle]

Restored the code to what they were before.

[kooshi]

Thanks! I forgot how messy I left those usings. I'll merge it after that comment is addressed and I get a chance to double check it.

changing the git based change tracking with something like a RAG or local graph database like graphiti

If you have something specific in mind, please write it out in detail as a feature request Issue, and we can discuss it there.

In general though, I like the git tracking the way that it is (though I need to add support for submodules), and I'm not sure what RAG or a graphiti would have to do with it, unless you mean triggering a change in the knowledge database when a git change happens? That could be a good idea.

If that's the goal, maybe the server could have a hook or event or function call of some sort that could trigger something else, internally or externally, to update the knowledge graph?

But right now, the point of the git tracking is for the AI to safely make whatever changes it wants at any time, and I can step through and manually only keep the changes I want.

Anyway, yes, I'm open to new features as long as they have a clear benefit and don't complicate the structure too much.
Please detail your goal and use case in a new Issue and I'll take a look.

[alwaysmiddle]

In general though, I like the git tracking the way that it is (though I need to add support for submodules), and I'm not sure what RAG or a graphiti would have to do with it, unless you mean triggering a change in the knowledge database when a git change happens? That could be a good idea.
If that's the goal, maybe the server could have a hook or event or function call of some sort that could trigger something else, internally or externally, to update the knowledge graph?

From what I understand about this repo, the goal is simply provide static analysis from Roslyn compiler via a http server. The other projects I have mentioned Graphiti, it uses a RAG database for historical tracking of conversations, and neo4j graph database to build a graph representation of the conversation, and it has shown siginificant improvement in the usage experience and performance of the AI models.

I ran into this repo as I wanted to try something similar but with Roslyn compiler's context, fitting the context into neo4j graph database, but not bothering with the RAG database. One problem is that I lack experience in the topic of compiler and Roslyn's API. I was just curious if you are open to try maybe sticking a graph database to represent the solution's context, the git system can stay of course, it is a nice developer experience, but we do run the risk of graph database and git system context being out of sync.

This change involves re-architecturing the solution, that is why I am hesitant to make this ask. If you implement a server hook, it will place the responsibility of maintaining this interal graph representation to the user. Which will be fine if you want to maintain the project's feature set as is. Since this involves a lot of unknowns, I just wanted to touch base and get an idea what are your plans about this project in the medium term.

[kooshi]

I see. The goal of this project actually has quite a bit more depth than just static analysis (though it is also very good for that). Its purpose is more similar to Claude Code, Copilot, and Cursor, in that it is an (almost) complete system for AIs to modify code (except only supporting C#). The git tracking is there to track those modifications.

Graphiti is really interesting. I'll have to experiment with it to see if it could serve any purpose here.

It may be slightly redundant, because every codebase is also inherently a knowledge graph, and this project actually leverages that heavily. For example, if the AI calls "View Definition" on a function, it will also see the fully qualified names of every function that calls it, and every function which it calls, so it can easily jump around and find the exact code it needs.

I'd say it's very unlikely that I'll implement Graphiti, unless I get really obsessed with it in the future.

I'd encourage you to start playing around with Roslyn though. It is C#'s most powerful tool and best kept secret. It enables more interesting meta-programming than almost any other programming language, and Claude is surprisingly good at it.

[alwaysmiddle]

It may be slightly redundant, because every codebase is also inherently a knowledge graph,...

Interesting way of looking at this, that is actually pretty eye opening persepective. Maybe the graph database is redundant feature when it comes to the codebase, its place maybe more suited for the business context around the problem.

Sorry that I forgot about the Git change tracking part, I did see the repo was aimed at being developed as a complete closed system that AI models can leverage, just I blanked while typing the first point out.

I am actively learning about compiler and Roslyn currently, hopefully after I gained more Knowledge I would be better of service in the future, thanks for the tip, appreciate it.