.NETの新しいLTSバージョンの、.NET 10.0が2025年11月11日にリリースされた。ぼちぼち、.NET 8.0のアプリのコンバートや実行環境の変更を試さないと。Visual StudioもVisual Studio 2026(v18.0)になるので、これもインストールしなきゃ。
https://dotnet.microsoft.com/ja-jp/download/dotnet/10.0
前回の、.NET 6.0 から .NET 8.0 への移行で学んだことは、動くけれど、長期間動作させると新機能などにより、予期せぬ不具合が具現化するかもしれないということ。今回も気を付けないと。
Microsoftより、Powershell 2.0の具体的な廃止のスケジュールが発表された。これによると、2025年8月（今月）～9月（来月）には、Windows11 24H2から削除されるという。
「PowerShell 2.0」は間もなく削除、今月～来月の更新で ～Windows 11 バージョン 24H2/Server 2025で
https://forest.watch.impress.co.jp/docs/news/2039392.html
基本的に、Powershell 5.1がWindows11 24H2にあるので、Powershellがなくなるということはない。けれど、Powershell2.0で明示的に動かしている場合や廃止されているコマンドレットを使っていると動かなくなる。
Powershellを別のバージョンに移行するとして、候補がPowershell 5.1（Windows Powershell 5.1）か、Powershell 7系だ。２つの違いは、Windows Powershell 5.1が.NET Framework 4.8で動作、Powershell 7系が、.NET（.NET core）で動作、ベースになる環境が異なる。この先を考えるならば、Powershell 7系がいいのだろうけれど、ベースになる.NETはLTSで3年のサポートなので、LTSがリリースされる2年ごとにバージョンを上げていくことになる。互換性はあるから大丈夫なんだろうけれど、ベースの.NETの入れ替えは必要になる。
Windows PowerShell 5.1 と PowerShell 7.x の相違点
https://learn.microsoft.com/ja-jp/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.5
なんとも悩ましい。割り切って、Powershell 7系に乗り換えて、定期的にアップグレードしていくのがいいのだろうけれど。
Microsoftの公式サンプルのソースコードであっても、信じてはいけないという話。サンプルコードを使うと、Windowsのメモリ不足を引き起こすかもしれないという。
Windowsのメモリ不足、公式サンプルコードのコピーだけで発生する可能性 https://news.mynavi.jp/techplus/article/20250526-3333822/
多くの場合、メモリ不足は無限にメモリを消費するプログラムのバグが原因で引き起こされる。今回の例もプログラムのバグを原因とするが、公式のサンプルコードをコピーしただけで発生するという。
かなり無理に近いけれど、公式サンプルをコピペして使う場合でも、その設定内容や何を行っているのか、を理解した上（理解しょうとした上）で使わないといけないわけだ。昔は、そういうのを信じるな、と言われたものだが。公式のサンプルコードくらいは信用したかった。今後は、生成AIが生成したコードがそれにあたるのだろう。その場合は、別の複数のＡＩにチェックさせて、合議する感じだろうか。もしくは人でチェックか。どちらにしても、最終的には、採用した（そのコードを使った）人の責任なわけだ。
.NET8のアプリで急に動作が遅くなるときがある。このときは、Dynamic PGOを疑ってみるといい。
.NET8のDynamic PGOは、基本的にはアプリ実行が早くなる。アプリのサイズが巨大で、ほとんど使われない機能があり、いろいろな機能を呼び出しているときは、一定の閾値をこえると急激に遅くなることがある。これは、Dynamic PGOの特性のようだ。
Bing on .NET 8: The Impact of Dynamic PGO
https://devblogs.microsoft.com/dotnet/bing-on-dotnet-8-the-impact-of-dynamic-pgo
.NET Framework 4.8系のASP.NETのMVCから、.NET Core系のASP.NETのMVCにアップグレードするためのツール（.NET アップグレード アシスタント）が公開された。MVCモデルなので、これは精度よくアップグレードできそうな気がする。
従来型のASP.NET Framework Web Forms アプリも変換できるようだが、、、こっちはかなり構造が変わるので、どうなんだろうか。
■参考
ASP.NET MVC と Web API から ASP.NET Core MVC へのアップグレード
https://learn.microsoft.com/ja-jp/aspnet/core/migration/mvc?view=aspnetcore-9.0
ASP.NET Framework Web Forms アプリを ASP.NET CORE MVC にアップグレードする
https://learn.microsoft.com/ja-jp/aspnet/core/migration/web_forms?view=aspnetcore-9.0
.NET アップグレード アシスタントとは
https://learn.microsoft.com/ja-jp/dotnet/core/porting/upgrade-assistant-overview
ちょっと検索で探しにくかったので、メモ。
.NET8.0（.NET9.0も同じだった）が対応しているWindows OSは以下。
参考：
https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md
https://github.com/dotnet/core/blob/main/release-notes/9.0/supported-os.md
現在、稼働している.NETのアプリが、どのバージョンのライタイムで、アプリケーションが動作するようになっているのかを調べてみる。この方法は、.NET5よりも後の.NETアプリについて、調べることができる。
アプリのフォルダで、下記の名前のファイルがあるかを調べる。[appname]の部分には、そのアプリの名前がついている。
[appname].runtimeconfig.json次のそのJSONファイルを開く。メモ帳などのテキストエディタで開けばよい。
下のような中身になっているので、「tfm」や「version」の部分を確認し、どの.NETバージョンを利用するようになっているのかを確認する。
{
"runtimeOptions": {
"tfm": "net8.0",
"includedFrameworks": [
{
"name": "Microsoft.NETCore.App",
"version": "8.0.5"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "8.0.5"
}
],
"configProperties": {
"System.GC.Server": true,
"System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
"System.Reflection.NullabilityInfoContext.IsSupported": true,
"System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false
}
}
}参考： https://learn.microsoft.com/en-us/dotnet/core/runtime-config/
.NET6のサポート終了が近づいているので、.NET8に変更して実行したところ、SQL Serverとの接続でエラーが発生した。
An unhandled exception occurred while processing the request.
Win32Exception: 信頼されていない機関によって証明書チェーンが発行されました。
Unknown location
SqlException: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - 信頼されていない機関によって証明書チェーンが発行されました。)
Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, bool breakConnection, Action<Action> wrapCloseInAction)「Microsoft.Data.SqlClient パッケージ」の破壊的変更の影響だった。対処としては、ConnectionStringsの接続文字列の最後に、「TrustServerCertificate=True;」を追加した。下記みたいな感じ。
"ConnectionStrings": {
～～～略～～～;Database=DBname;TrustServerCertificate=True
},これでもう一度実行して、実行できることを確認した。
参考： https://learn.microsoft.com/ja-jp/ef/core/what-is-new/ef-core-7.0/breaking-changes?tabs=v7