.NET: ci: switches to a dedicated solution for dependabot

[Vincent Biret (baywet)]

follow up to #8476 because dependabot is still timing out for dotnet. I now believe this is because the restore is doing some level of build, which with all the samples and on a small machine times out. This adds a solution file with everything but the samples and points dependabot to that in the hope that it'll final start working

[Copilot]

🟢 Approval recommended

The dedicated solution is complete, valid, and consistent with the documented timeout mitigation.

Pull request overview

Introduces a dedicated .NET solution for Dependabot to avoid sample-related timeouts.

Changes:

• Adds a solution containing all current source and test projects.
• Points NuGet Dependabot discovery to the dedicated solution.

File summaries

File	Description
.github/dependabot.yml	Targets the dedicated Dependabot directory.
dotnet/dependabot/README.md	Documents purpose and maintenance expectations.
dotnet/dependabot/agent-framework-dependabot.slnx	Includes all 84 source and test projects while excluding samples.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MAF Automated Review — Iteration 1

Result: No findings
Scope: full PR (1 commit(s)): 1c9687e40e57
Model: gpt-5.6-sol-fast

Overview

The PR redirects NuGet Dependabot discovery to a dedicated solution containing all 84 non-sample source and test projects while preserving the existing schedule and update policy. The solution parses, all referenced paths resolve, central package management remains discoverable, and existing CI enumerates every solution file, so no publishable residual risk was established.

Reviewed the supplied pull-request change set across correctness, security/reliability, architecture, and failure behavior.
No publishable findings remained after source verification for this scope.

[github-code-quality]

Code Coverage Overview

Languages: C#

C# / code-coverage/dotnet

The overall line coverage in commit 1c9687e in the ci/dependabot-dedica... branch is 84%. Line coverage data for the main branch is not yet available.

Show a line coverage summary of the most covered files.

File	main	ci/dependabot-dedica... 1c9687e	+/-
/home/runner/wo...valConverter.cs	—	100%	—
/home/runner/wo...entsProvider.cs	—	99%	—
/home/runner/wo...nticAnalyzer.cs	—	94%	—
/home/runner/wo...tClientAgent.cs	—	91%	—
/home/runner/wo...putConverter.cs	—	90%	—
/home/runner/wo...kflowBuilder.cs	—	90%	—
/home/runner/wo...SkillsSource.cs	—	89%	—
/home/runner/wo...kflowSession.cs	—	87%	—
/home/runner/wo...onExtensions.cs	—	81%	—
/home/runner/wo...ctionVisitor.cs	—	70%	—

[SergeyMenshykh]

I wonder how our CI workflows will handle the new solution file. Will they discover it and build it in addition to the main solution file? or ignore it?

[Vincent Biret (baywet)]

the pipelines (ADO) have a variable defined solution: 'dotnet/agent-framework-dotnet.slnx' that's used by all the dotnet tasks. So it'll use that solution, and ignore the new one I'm introducing.

[Vincent Biret (baywet)]

On GHA side, this will need an update to stop looking into the new directory,

agent-framework/.github/workflows/dotnet-build-and-test.yml

Line 133 in b043790

export SOLUTIONS=$(find ./dotnet/ -type f -name "*.slnx" | tr '\n' ' ')

the other workflows are using the csproj as far as I can tell.

[SergeyMenshykh]

We’ll have to remember to update this file every time we add, remove, or update a project. Maybe we can use it to confirm that the timeouts are caused by the large number of dependencies that need to be analyzed, and then decide on a more maintainable solution.

[Vincent Biret (baywet)]

I'd like to try this solution since I've already tried:

• manually updating a lot of the dependencies, thinking the issue came from the sheer number of outdated ones
• excluding the samples path

Unfortunately, for me to try anything, I need to merge into main. Nothing guarantees it'll work, and if it does, we can always adjust to negate any trade offs like these.

[SergeyMenshykh]

If it works, we’ll also need a way for Dependabot to update the sample dependencies.

[Vincent Biret (baywet)]

The other alternative I thought of was to add entries dedicated to csproj, so it does the different runs on separate jobs. But that's going to be a pain to maintain. Which is why I'd like to try the solution first.

[westey (westey-m)]

Also check out https://github.com/microsoft/agent-framework/blob/main/dotnet/eng/scripts/New-FilteredSolution.ps1

We are using this in a few places in the main dotnet-build-and-test.yml to create smaller slnx files to avoid building everything in every parallel stream.

It supports a switch for removing all samples, but can also filter projects by target framework.

E.g.

          ./dotnet/eng/scripts/New-FilteredSolution.ps1 `
            -Solution dotnet/agent-framework-dotnet.slnx `
            -TargetFramework ${{ matrix.targetFramework }} `
            -Configuration ${{ matrix.configuration }} `
            -ExcludeSamples `
            -OutputPath dotnet/filtered.slnx `
            -Verbose

[Vincent Biret (baywet)]

unfortunately I don't have control over how dependabot does the discovery or which steps it runs besides pointing it to a directory. So it won't be able to execute this script. (there's no workflow definition for dependabot)