Visual Studio 2026でも、従来の.net framework 4.8のアプリ開発はできる。Visual Studio 2019からの乗り換えもできそう。
ただし、開発しているアプリが32bitでなければの話。Visual Studio 2026だと64bitでコンパイルしてくるので、参照している外部DLLが32bitのものがあるとコンパイル（というか実行自体）ができなくて、エラーになる。開発段階だと普通に作業できてしまうので、実行段階になって、32bitのDLLの読み込みが行われて気がつく。古いアプリの改修を行うときにはハマるので注意。
.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 への移行で学んだことは、動くけれど、長期間動作させると新機能などにより、予期せぬ不具合が具現化するかもしれないということ。今回も気を付けないと。
開発環境をWindows10からWindows11にアップグレードした。Windows11のVisual Studio 2019の開発環境のコードから、Windows Server 2003 R2上のSQL Server 2005に対して、接続ができなくなった。接続時のセキュリティの不一致のため。
.NET6のアプリをIISにデプロイしたが、500エラーで動作せず。コンパイル自体はエラーになっていなかったが、IIS上にデプロイして、実行するとエラーになった。
いろいろと調べていくと、「アプリケーションの発行」の設定の「Entity Frameworkの移行」のところにバツマークがついていた。内容は、「dotnet tool restore」だ。これが影響しており、正常にアプリケーションの発行ができていなかった。
対処として、ソリューションのクリーンとリビルドを行ったが、改善せず。
表示されていたパスにある「dotnet-tools.json」を別のファイル名にリネームして、再度発行を試したところ、正常に発行ができて、IIS上でも動作した。「dotnet-tools.json」のファイルの更新で問題があったことが原因だった。
古いASP.NETのプロジェクト（言語はVB）をVisual Studio 2019で開いて、デバック実行したところ、「assenbly.csが見つからない」とエラーになる。
これを回避するには、以下の設定を行う。
もう一度、デバック実行して、「assenbly.csが見つからない」が出なければ問題なし。
古いASP.NETのプログラムを、新しい環境でコンパイルして、アプリケーションサーバ（IIS）にデプロイして、テストしたら、下記のエラーが表示された。Visual Studio 2019上では動作している。
ファイルまたはアセンブリ 'xxxxxxxx.DLL'、またはその依存関係の 1 つが読み込めませんでした。 は有効な Win32 アプリケーションではありません。 (HRESULT からの例外:0x800700C1)
問題は、アプリケーションサーバであるIISの設定だった。Windows Server 2019のIIS10は、デフォルトでは64ビットのアプリケーションサーバとして動作する。そのため、32ビットのDLLが混じったアプリケーションを実行するためには、IISの設定で、32ビットのアプリケーションを動作するようにしないといけなかった。
32ビットのアプリケーションを動作するようにするIISの設定方法は下記。
これで、32ビットのアプリケーションも動作するようになる。
VS2008のアプリをVS2019で開いて、デバック実行したら「Assembly.csが見つかりません」が表示された。「Assembly.cs」を探したが見つからず。元のプロジェクトはVB.NETで書かれている。
VS2019上には、逆コンパイルで作成も選択できたので、実行してみたが失敗した。
失敗したので、今度は、Assenbly情報を再作成した。
これでエラーが出なくなった。
Visual Studio 2008のソリューションを、Visual Studio 2019の形式に変換した。.NET Frameworkも3.5から4.8に変更した。Visual Studio 2019でデバック実行したところ、ログインユーザの値が「Request.ServerVariables(“LOGON_USER”)」でとれなくなった。
言語のバージョンか、.NET Frameworkのバージョン違いか、調べたが、ちゃんと残っていた。
変わっていたのは、Visual Studio 2019上での開発サーバー（IIS）の設定値だった。プロジェクトのプロパティを開いたところ、開発サーバーの設定があり、そこの設定では、「Windows認証」が無効で、「匿名認証」が有効になっていた。これだと、LOGONしたことになっていないので、「LOGON_USER」の値は、空になる。
開発サーバーの設定を、「Windows 認証」を有効にし、「匿名認証」を無効にした。その後、デバック実行して確認したところ、正常にログオンユーザが取れた。
Visual Studio 2019を使っていると、細かく更新プログラムの自動アップデートが行われる。普段ならば、ダウンロードサイズを気にしなくてもよいが、リモートワーク中などでダウンロードに回線を使いたくないときがある。自動更新を止める方法は下記。
なお、手動で更新プログラムを確認するときは、「ヘルプ」から「更新プログラムの確認」を選択する。
人から受けとったASP.NET MVCのプログラムをVisual Studio 2019でデバック実行したところ、下記のエラーが発生した。
'/' アプリケーションでサーバー エラーが発生しました。 パス 'C:\xxxx\xxxx\xxxx\bin\roslyn\csc.exe' の一部が見つかりませんでした。
調べていったところ、NuGetにある「Microsoft.CodeDom.Providers.DotNetCompilerPlatform」のパッケージのバージョンをアップデートしたところ、この問題が解消され、このエラーは解消された。
依存関係の問題なので、アップデートではなく、「Microsoft.CodeDom.Providers.DotNetCompilerPlatform」の再インストールでも解決すると思われる。