doent support mono repos

[kri-kan]

the project assumes there will be only one .sln file per git repo, which is not true in many real time cases, can we accomodate this requirement?

[bbajt]

Hi @kri-kan!

You're right, and thanks for the precise description. CodeMap's auto-discovery does currently assume a single solution: when you don't pass a solution path, it scans the repo root only and picks the first .slnx/.sln it finds, so in a monorepo it silently grabs one and ignores the rest. That's a real limitation, not intended behavior you're working around wrong.

What works today: both index.ensure_baseline and workspace.create take an explicit solution_path, and it can point anywhere in the tree, including a solution nested in a subdirectory:

index.ensure_baseline { repo_path: ".", solution_path: "services/OrderService/OrderService.sln" }

So you can absolutely index a specific solution in a monorepo right now.

The honest caveat: baselines are keyed by repo + commit, so within one repo at one commit there's effectively one active index at a time. Indexing solution B would overwrite solution A's baseline rather than sit alongside it. So the explicit-path approach lets you work on one solution in the monorepo, but not query across several simultaneously.

Properly accommodating multiple solutions per repo, indexing them side by side under one repo identity, needs a per-solution sub-key in the baseline layout. It's a legitimate feature and honestly the most compelling of the current requests; I'm capturing it as a known limitation and a candidate for a future release. I can't promise a date, but this is the kind of thing that moves up the list with real-world demand, so it helps to know you hit it.

In the meantime, if you tell me a bit about your layout (how many solutions, whether they share projects), I'm happy to suggest the smoothest way to drive it with explicit solution_path calls.

[kri-kan]

ok, I work on a kind of proejct which acts like a extemsible framework, which is also a lgeacy web solution, alongside it has some more silutions that are meant to provide tooling to the framework like SDK, installer, log monitor etc, leaving them apart there many business specific solutions built on top of the base framework which live along side. Also the repo is a mixture of dotnet and custom config files that are read and processed by the base framework these are kind of custom xml specs that contribute to the solution behaviour, For a better visualisation consider like we are developing a share point application, where the enterprise will host the sharepoint solution along with dlls and static assets for the enhacements or customisations we do on top of the Out of the box features.

So I want to track the codemaps for each project in the Repo, or if we consider solutions as the way to consilidate them, all solutions in the GIT repo

[bbajt]

Thanks, you've described the limitation accurately, and it's a real one. Two parts to the answer: what works today, and where full support stands.

What works today (per-solution, one at a time). Both index.ensure_baseline and workspace.create take an explicit solution_path that accepts any path, including a nested one:

index.ensure_baseline { repo_path: ".", solution_path: "services/Orders/Orders.sln" }

So in a monorepo you can point CodeMap at a specific solution and it indexes exactly that one. The auto-discovery is what assumes a single solution - it scans the repo root and picks the first .sln/.slnx it finds, so passing solution_path explicitly is the workaround, and it covers most day-to-day navigation.

The real limitation. Baselines are keyed by (repo, commit), so at a given commit a repo maps to one baseline. Indexing a second solution at the same commit overwrites the first, you can't hold two simultaneously, and you can't query across them. That's the part the workaround doesn't solve.

Where full support stands. I've scoped this properly. The good news is the storage keyspace already partitions by a repo identifier, so the clean fix is to give each solution its own logical identity (fold the solution's path into that identifier) - each solution becomes its own indexable unit that can coexist and be queried independently. Importantly this needs no new tools and no interface changes - it's a contained, medium-sized change concentrated in the identity/routing layer, not a rewrite. Selecting the "active" solution reuses conventions CodeMap already has (a workspace is born pinned to its solution_path; committed-mode gets a sticky-default + optional selector). It's not built yet, it's demand-driven, and as I said, you're the first ask, but I'll for sure add it pretty soon.