Visual Studio

「文字リテラルに文字が多すぎます」のビルドエラー

ソースコードをビルドしたときに、「文字リテラルに文字が多すぎます」というエラーメッセージが出た場合の対処法です。

文字型変数に、あきらかに誤った文字情報を入れているのでなければ、該当ソースコードの文字コードがSJISになってしまっていることがエラーの原因です。

メニューバーの、
　 ファイル　＞　保存オプションの詳細設定
のメニューで、ソースコードの文字コードをUTF-8にして保存し直し、再度ビルドすれば、エラーメッセージは解消されます。

プロジェクト参照の参照先クラスを読み込めない

参照設定で他のプロジェクトを参照し、参照先プロジェクトに含まれるクラスを呼び出せない場合の対処法。

一度VisualStudioを終了後、そのプロジェクトのソリューションフォルダにある objフォルダ と binフォルダ を全て削除。

再度VisualStudioを起動して、ソリューションをリビルドする。
すると参照先プロジェクトに含まれるクラスを、呼び出して使用することができる。

SQLServerに対してデータベース比較ツールが使えない場合の対処法

Visual Studioのバージョン

VisualStudioには、データベース比較ツールが付属しています。
このツールを使うと、2つのデータベースの定義を比較して、テーブル定義・列定義が一致しているかどうかを調べることができます。

SQLServerのデータベースに対して比較をしようとした時、エラーが出て比較をすることができませんでした。
調べたところ、VisualStudioをアップデートすれば解消されました。
VisualStudioよりSQLServerのバージョンの方が高い場合に、このような症状が発生することがあります。

権限

スキーマ比較を実行するユーザーに対して、VIEW DEFINITIONという権限が必要。Management Studioから以下のコマンドで、権限を付与できる。

GRANT VIEW DEFINITION TO [DBのユーザー名]

スキーマとしてdb_ownerを指定すれば、比較ツールを実行できる。
db_datareaderとdb_datawriterのみにするなど権限を絞った場合に、十分な権限を持てていない場合があり、追加の権限付与が必要となる場合がある。

スタックトレースに行番号が表示されない場合の対処法

例外発生時に、スタックトレースに行番号が書かれていると、ソースコード中のどの箇所でエラーが発生したのかを迅速に把握でき、プログラムの改修をピンポイントで行えるようになります。
スタックトレースに行番号が表示されない場合は、次の原因が考えられます。

拡張子pdbファイルがない

実行環境に、pdbファイルを配置し忘れたなどの理由が考えられます。
pdbファイルを実行環境に配置すれば、行番号が表示されるはずです。

pdbファイルの対応付けが誤っている

pdbファイルはあるが、異なるビルドタイミングで生成した拡張子dllやexeのファイルと併存していることが考えられます。例えば、dllファイルは更新したが、pdbファイルを更新せず古いままだった、などが考えられます。
同じビルドタイミングで生成されたdllファイルとpdbファイルを、実行環境に配置すれば、行番号が表示されるはずです。

VisualStudioの設定

VisualStudioでのビルドの設定により、pdbファイルが生成されない設定になっていることが考えられます。
VisualStudioのプロジェクトのプロパティを開き、
設定項目：ビルド＞詳細設定(D)＞デバッグ情報
設定値：fullまたはpdb-only
と設定すれば、pdbファイルが生成されるようになります。

補足

本番稼働環境にはpdbファイルを置くな、という意見も多くあります。
ただ、本番環境で万が一不具合が発生した時に、的確に最速でバグを回収して本番環境を再更新が必要とされる要件がある場合には、pdbファイルを置いておくのも一考に値します。

単体テストのトラブル

単体テストが全てスキップされる

Visual Studioの単体テスト（MSTest）を利用したら、全てのテストがスキップされる現象が発生しました。
Visual Studioをバージョンアップさせた後に、この症状が出ました。
MSTestで単体テストを行ったときに、次のようなエラーメッセージも表示されました。
（「出力」ウインドウで、ドロップダウンを「テスト」に切り替えたところに表示されていました）

同じ拡張子で複数のバージョンが見つかりました。最新のバージョンを選択しています。
Microsoft.VisualStudio.TestPlatform.MSTest.TestAdapter : 14.0.4908.2
TestSettings will soon be deprecated for automated unit and functional testing scenarios. It is recommended that you use RunSettings. To learn more, see http://aka.ms/runsettings

アセンブリ 'Microsoft.VisualStudio.QualityTools.LoadTest, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' が見つかりません。

警告: testsettings ファイル、vsmdi ファイルは MSTest V2 アダプターではサポートされていません。

この事象は、次のことを行うと解消されました。

• ソリューション内の「〜.testsettings」という拡張子のファイルを削除した。これは、VisualStudio2010時代に使われていたものらしい？
• ソリューションフォルダ内にある「.vs」フォルダに存在する、テスト関連の設定情報を削除した

マイコードのみを使用すると、デバッグ機能が低下します

デバッグテストの時に、下記のメッセージが出た。

「リリースビルド 〜.dll をデバッグ中です。コンパイラによる最適化を使用するリリースビルドで [マイコードのみ]を使用すると、デバッグ機能が低下します（例 ブレークポイントがヒットしない）

• デバッグを中止
• マイコードのみを無効にして続行
• デバッグの続行

の3種類の選択肢が出たが、「デバッグの続行」を押すことで、テストをデバッグ実行できた。

テストプロジェクトの「コードの最適化」で、以下の設定を行うと改善された。
「Debug」の方にチェックが入っていると、デバッグビルドしたときにコードの最適化が行われてしまうので、上記のメッセージが出たようだ。

一部のアセンブリでブレークポイントが引っ掛からない

単体テストプロジェクト内ではブレークポイントに引っ掛かる。しかし他のプロジェクトに対してブレークポイントが引っ掛からず、ブレークポイントにアムスカーソルを充てると「このドキュメントのシンボルは読み込まれていません」というエラーメッセージが出ている場合。

Visual Studioの ツール＞オプション をクリックし、デバッグの項目の「マイコードのみを有効にする」のチェックをOFFにすると、他のプロジェクトでもブレークポイントが引っ掛かるようになった。

アセンブリのファイルロック

VisualStudioでユニットテスト実行後、ビルドのたびに次のようなビルドエラーが発生しました。

"obj\Debug\〜〜\XXX.dll"を、"bin\Debug\〜〜\XXX.dll"にコピーできませんでした。10回の再試行回数を超えたため、失敗しました。このファイルは、"dotnet.exe" によってロックされています。

"obj\Debug\〜〜\XXX.dll"を、"bin\Debug\〜〜\XXX.dll"にコピーできません。別のプロセスで使用されているため、プロセスはファイル "〜〜\XXX.dll" にアクセスできません。

このエラーが発生すると、以後、ビルドのたびに必ず上記ビルドエラーが発生し、デバッグ実行やユニットテストを実行できなくなります。
マシンを再起動すれば再度ビルドを実行できるようになりますが、結局上記のビルドエラーが発生し、また再起動しなければならなくなります。

このエラーの原因は、ユニットテストの実行中に無限ループとなるロジックが存在していたことでした。
無限ループとなるロジックを解消すれば、上記ビルドエラーは発生しなくなりました。

ｘUnitでテスト失敗時にブレークで止まらない(例外発生しない)

xUnitでデバッグでテストを実行したとき、失敗するとそこで通常はブレークされて停止する。
しかしある時から、ブレークがかからなくなり、とまらなくなった。
メニューの デバッグ＞ウインドウ＞例外設定 で、以下のように「この一覧にないCommmonLanguageRuntimeExceptionsすべて」にチェックを入れると、ブレークがかかりテスト失敗時に泊まるようになった。
（ただし、いつものような止まり方ではないので、違和感は出る）

Visual Studioのメモリ使用量を減らす

https://takap-tech.com/entry/2023/03/28/010527