AI Gets Lost in Visual Studio’s New Solution Philosophy
More Hidden Whimsical “Fixes”
This wasn’t a random experiment. I set out to test a small, focused conversational language model — evaluating footprint, memory usage, and response quality. I used Windows Copilot to generate a step-by-step guide, formatted for ingestion by GitHub Copilot in VS2026 Enterprise Insiders Edition.
- Instructions were placed in
/docs - A
.githubdirectory defined preferences and minimal intervention - Copilot was instructed to follow the guide and build the model autonomously
I kicked it off and moved to another machine.
The Breakdown Begins
Copilot asked for one confirmation, then proceeded. Later, I returned to a curious prompt:
“I performed tasks x.y.z and tried to run Build… but couldn’t find anything to build.”
It had created projects — but couldn’t build them. I added a solution file, linked the projects, and added a shared .shproj at the root to glob folders not tied to a project. A setup I’ve used for years.
Still, Copilot couldn’t see:
- The
.shprojfile - The solution file
- The folders it had just created
I cleared the .vs cache and restarted. Everything looked fine on my end. But Copilot still couldn’t see the shared project — and I couldn’t even share it back into the chat context.
Introducing the Broken “Fix”
I had a hunch. Copilot confirmed it:
Microsoft has tied solution/project visibility to GitHub and
.gitmanifests.
If a folder isn’t under Git control — or listed in the manifest — it’s invisible to Copilot.
There are exceptions. If you start with folders and instruct Copilot to begin, it can see them. But once Git enters the picture, visibility becomes conditional.
This hidden dependency on a third-party tool violates every coding commandment I’ve followed for 40 years.
The Solution File: From Container to Index
What It Used to Be:
- A container
- You could add folders directly
- Globs worked
- Git was optional
What It Is Now:
- An index
- Tracks only
.csproj,.shproj, and virtual folders - Non-project folders are invisible
- Globbing is no longer supported
You can hack around it with a shared project and globbing — but it’s fragile and unnecessary. The old format was clean, granular, and Git-agnostic.
Why This Breaks Formal Coding Commandments
Depending on Git/GitHub for core visibility violates foundational principles:
- Never depend on external tooling for core functionality
- The IDE should be self-sufficient
- Indexing should be explicit and reproducible
By tying Copilot’s vision to Git, Microsoft has made local, private, and experimental projects second-class citizens. That’s absurd. Scratchpads and prototypes deserve clarity without being forced into a repo.
The Bigger Lesson
Audit-grade clarity requires explicit contracts:
.slnshould manifest all files.csproj/.shprojshould contain source- Git should be optional provenance — not mandatory visibility
When the solution file lost its container role, the AI lost its anchor. It could generate — but not see. That’s not just a bug. It’s a design failure.
Closing Thought
AI shouldn’t paint itself into blind boxes. Developers shouldn’t be forced into Git for visibility. And solution files shouldn’t be broken indexes when they used to be reliable containers.
If Microsoft restored the solution file’s original behavior, this entire problem would vanish.
Until then, we’re left documenting the irony: an AI that can generate code but can’t see its own work — trapped by broken design and misplaced dependency.
— Kyle