2026年6月28日から7月4日までに公開された、C#/.NET関連の主なニュースをまとめます。 今週は大きなSDK本体のリリースよりも、既存アプリの保守、Windowsアプリの配布、ビルド診断、Visual StudioのAI支援まわりの更新が目立ちました。.NET 8や.NET 9を使っているプロジェクトでは、今すぐ移行が必要という話ではありませんが、2026年11月のサポート終了を見据えて.NET 10への移行計画を立て始める時期です。
Windowsユーザーへの影響
WindowsでVisual Studioを使ってC#/.NET開発をしている場合、まず確認したいのは利用中のTargetFrameworkです。.NET 8と.NET 9は2026年11月10日にサポート終了予定のため、業務アプリや長期運用するデスクトップアプリでは.NET 10への移行可否を早めに確認しておくと安心です。
WPFやコンソールなどの.NETデスクトップアプリをWindows機能と深く連携させたい場合は、WinApp CLIの更新も実用的です。通知、共有、ファイルハンドラー、Windows AI APIなど、パッケージIDが必要な機能を試すときに、手作業でmanifestや証明書設定を組む負担を減らせます。Visual StudioのJune Updateでは、Copilotの利用量表示とMCPサーバーの信頼確認が強化されているため、AI支援を日常的に使うチームほど確認しておきたい変更です。
.NET 8と.NET 9は2026年11月10日にサポート終了予定
https://devblogs.microsoft.com/dotnet/dotnet-8-9-end-of-support/
2026年6月29日、.NET Blogで「.NET 8 and .NET 9 will reach End of Support on November 10, 2026」が公開されました。 .NET 8と.NET 9は、どちらも2026年11月10日にサポート終了予定です。この日以降は、これらのバージョンに対する新しいセキュリティ更新、サービス修正、技術サポートが提供されなくなります。.NET 8はLTS、.NET 9はSTSですが、STSのサポート期間が24か月になったことで、両方とも同じ日に終了する形です。
初心者の方は、まずプロジェクトファイルのTargetFrameworkを確認してください。net8.0やnet9.0を使っている場合、すぐに壊れるわけではありませんが、長く運用するアプリでは.NET 10への移行計画が必要です。実務では、SDKだけでなく、Visual Studio、CI環境、Dockerイメージ、ホスティング先、依存NuGetパッケージが.NET 10に対応しているかも合わせて確認しましょう。
SkiaSharp 4.0の初回安定版が公開
https://devblogs.microsoft.com/dotnet/skiasharp-4-0-stable/
2026年6月29日、.NET Blogで「SkiaSharp 4.0 is here: announcing the first stable release」が公開されました。 SkiaSharp 4.148.0が、SkiaSharp v4系の最初の安定版として利用できるようになりました。SkiaSharpは、.NET MAUI、WebAssembly、WinUI 3などでも使われるクロスプラットフォームな2D描画ライブラリで、今回の更新ではSkiaエンジンのm148相当への追従、OpenType可変フォント軸の制御、カラーフォントパレット、アニメーションWebPエンコードなどが含まれます。
Windowsで.NET MAUIやデスクトップアプリの描画を扱っている人にとっては、パフォーマンスと安定性の両面で確認する価値があります。ただし、v4では古いAPIの整理も進んでいるため、既存アプリで使う場合はNuGetを上げるだけで終わらせず、リリースノートを読み、描画結果、フォント、画像処理、ネイティブ依存関係をテスト環境で確認してから本番へ反映しましょう。
WinApp CLIで.NETデスクトップアプリにパッケージIDを付けやすく
https://devblogs.microsoft.com/dotnet/packaging-dotnet-apps-winapp/
2026年6月29日、.NET Blogで「Packaging and Package Identity for .NET apps with WinApp CLI on Windows」が公開されました。
WinApp CLIを使うことで、.NETのデスクトップアプリにWindowsのパッケージIDを付けたり、MSIXとしてパッケージ化したりしやすくなります。記事では、winget install Microsoft.winappcli --source wingetでCLIを入れ、winapp init . --use-defaultsでプロジェクトを初期化し、通常のdotnet runでパッケージID付きの実行を試す流れが紹介されています。
パッケージIDは、通知、バックグラウンドタスク、共有ターゲット、ファイルハンドラー、Windows AI APIなど、一部のWindows機能を使うときに重要です。初心者の方は「WindowsアプリをStore配布するためだけの仕組み」と考えるより、「Windowsの機能を安全に使うためにアプリをOSへ登録する仕組み」と理解すると分かりやすいです。実務では、署名、MSIX配布、既存インストーラーとの関係、アンインストール時のデータ扱いを確認してから採用しましょう。
Binlog MCP ServerでCI上のMSBuild失敗を自動診断
https://devblogs.microsoft.com/dotnet/mcp-build-diagnostics-workflows/
2026年6月30日、.NET Blogで「MCP Beyond the Chat Window: Build Diagnostics in CI」が公開されました。
Microsoft Binlog MCP Serverを、チャット内の手動調査だけでなく、GitHub Actions上のCI診断にも使う例が紹介されています。dotnet build /blなどで生成したMSBuildのbinlogをMCPサーバーに読ませ、失敗したターゲット、タスク、エラーの根本原因をAIエージェントがPull Requestコメントとして説明する流れです。
C#/.NETのビルド失敗は、ログが長くなると原因の切り分けが難しくなります。Binlog MCP Serverは、ログ全文を人間が読む代わりに、binlog_errorsやbinlog_diagnoseのような専用ツールで構造化された情報を取り出せる点が強みです。実務では、AIコメントをマージ判定そのものに使うのではなく、まずは「失敗理由を説明する補助」として導入し、通常の必須ビルドや人間のレビューと組み合わせるのが安全です。
Visual Studio 2026 June UpdateでCopilot利用量表示とMCP信頼確認を強化
Visual Studio GitHub Copilot MCP
2026年6月30日、Visual Studio Blogで「Visual Studio June Update – Track Your Usage, Trust Your Tools」が公開されました。 Visual Studio 2026のJune Updateでは、Copilot Usageウィンドウが更新され、利用量の状況や上限に近づいたときの通知が分かりやすくなりました。また、MCPサーバーの設定やツール内容が以前信頼した状態から変わった場合に、実行前に確認する信頼ダイアログも追加されています。
AI支援を使う開発では、便利さだけでなく、どのツールがどの権限で動くのか、どれくらい利用量を消費しているのかを把握することが大切です。初心者の方は、Copilotの利用量表示を「料金や上限の確認場所」として覚えておくとよいです。MCPサーバーを追加している場合は、信頼ダイアログを機械的に許可せず、設定、提供ツール、接続先が意図したものかを確認してから実行しましょう。
初心者が次に確認すること
まず、手元のプロジェクトでdotnet --infoを実行し、使っているSDKとランタイムを確認しましょう。次に、.csprojのTargetFrameworkがnet8.0やnet9.0になっているプロジェクトを洗い出し、.NET 10へ移行する時期とテスト範囲を決めてください。
Windowsデスクトップアプリを作っている場合は、通知やWindows AI APIなど、パッケージIDが必要な機能を使う予定があるかを確認しましょう。Visual StudioでCopilotやMCPサーバーを使っている場合は、June Updateを適用したうえで、Copilot UsageウィンドウとMCP信頼確認の挙動を一度見ておくと、チーム内で説明しやすくなります。