概要
VSCode の GitHub Copilot Agent に Visual Studio 系のソリューションを触らせると、C# だけなら dotnet でだいたい進みます。ところが C++/CLI やネイティブ C++ が混ざると、msbuild を見つけられない、dotnet test を失敗扱いにするといった詰まり方をしやすく、実用上かなり厳しかったです。そこで、作って見て効果があった 2 つの skills を紹介します。
最初に結論まとめ
次の2つの問題を解決する Agent Skills を作りました。
- msbuildの場所を探して迷う場合がある
- VC++混在ソリューションで dotnet test がエラー扱いになる場合がある
このリポジトリに置いています。
ビルドはmsbuild前提でskillsを作った
まずはビルドです。msbuildの探索をしようとして適当なパスで何度も試したり、PowerShellコマンドの実行に失敗したりして、何度も無駄な失敗をしている動作をよく見かけます。ここを解決します。
skills では、MSBuild の場所を vswhere.exe で取得して、変数に入れてから実行する形に揃えました。これによって、PowerShellのコマンドの形としても最低限が整うので、一発で成功してくれる率が上がりました。
$msbuild = & "${env:ProgramFiles(x86)}\\Microsoft Visual Studio\\Installer\\vswhere.exe" `
-latest -products * -requires Microsoft.Component.MSBuild `
-find "MSBuild\\**\\Bin\\MSBuild.exe"
& $msbuild "<.sln / .slnx などのソリューションフルパス>" /restore /m /p:Configuration=Debug
作った skill はこれです。
テストはNUnitをDLL指定実行するskillsを作った
次はNUnitのテストです。C++混在といってもNUnitのテストは dotnet test で実行出来るので問題ないかと思いましたが、そうはいきませんでした。
NUnit 自体は dotnet test で実行できます。しかし C++ や C++/CLI などが混在すると、テスト実行前の前段のビルドでエラーが出るので、テストが合格であっても GitHub Copilot が「テスト不合格」と見なすことがありました。
ここは、テスト対象の DLL をファイル名パターンで検索して、その DLL を指定して実行するやり方にしたら回避できました。混在する DLL があっても、その方式だとVC++部分は「ビルドエラー」ではなく「テスト 0 件、成功」という扱いになり、 GitHub Copilot が止まりにくくなりました。
作った skill はこれです。
ただしこのやり方はDLLを探索する都合上、テスト対象のDLLが見つからなくても成功で終わります。対象のソリューションで正しくテスト対象DLLを見つけられているかを確認して、ダメな場合は探索方法を変えるなどの工夫は必要になります。
Awesome-copilotでは埋まらなかった
こうしたGitHub Copilot 向けの Skills を探す上では、 Awesome Copilot はかなり便利です。
ただ、自分が今回困ったような、msbuild等をがっつり使いこなすようなものは見つかりませんでした。そういうのはやはりニーズが限られているのか、自分で作るしか無さそうです。
msbuild一般知識の入った.NET向けskillsが2026/3に登場した！
ありがたい取り組みです。これはmsbuild自体の使い方の知識なので、この記事で紹介したmsbuildの具体的な探索コマンドの固定や混在ソリューションでのテスト実行などとは、補完的に使っていけると思います。
まとめ
今回作った2つのskillsは割と実用的に役に立ちました。少なくとも自分の環境では、この 2 つを入れてからビルドとテストの進み方がかなり素直になりました。同じところで詰まっている人がいたら、そのまま使えると思います。