私的なメモなので、あまり信用しないでください。 実際の動きは自分で確認してください。 基本的に、VSは2003が対象となっています。 それ以外のバージョンの話題も含まれるかもしれませんが、まあ気にしないでください。 メモというより独り言になっている部分もありますが、今更編集しなおすのも辛いので軽くスルーしてください。 また、同じような内容が繰り返し記述されている可能性もありますが、まとめる気力がないのでスルーしてください。
現在ナッシングです。
デバッグの前準備としてQFEを適用する必要がある説明があるが、取りあえず、適用してなくてもデバッグできる（デバッグ時のパフォーマンスに関するQFEっぽいし）。 と言うか、日本語版には適用できないかも。
デフォルトの状態だと、Frameworkのソースをデバッグするには毎回対象シンボルの読み込みを行う必要がある。 それがめんどくさい場合は、ツール > オプション > デバッグ > シンボル > "シンボルが手動で読み込まれるときのみ上記の場所を探す" のチェックを外す。 シンボルファイルの場所が設定されていて且つチェックがついている状態で、上記チェックが外れていれば、必要なシンボルを全部自動でダウンロードしてくれる。 一度全てのシンボルをダウンロードしておけば、それ以降シンボルファイルの場所のチェックは外してもOK。
Frameworkのコードにブレークポイントを張る方法が説明されている。
個別に対処するなら、設定したブレークポイントのアイコンを右クリックしてコンテキストメニューから "場所" を選び、"元のバージョンと異なるソースコードを許可する" にチェックを入れる。
全体的に対処するなら、ツール > オプション > デバッグ > 全般 > "元のバージョンと完全に一致するソースファイルを必要とする" のチェックを外す。
個別に対処する方法だとブレークポイントのアイコンは消えちゃうみたいだけど、無効になったわけではない。ブレークポイントウィンドウで確認できる。
Frameworkの変数をローカルウィンドウなどで確認しようとした時に、以下のようなメッセージが出て内容が確認できないことがある。
"ローカルまたは引数 'mdiParent' はこの命令ポインタで利用できないため、値を取得することはできません。最適化されている可能性があります。"
最適化を無効にした状態でVSを起動し、プロジェクトのプロパティ > デバッグ > "Visual Studio ホスティング プロセス を有効にする" のチェックを外せばOK。
VS2008のインテリセンスはいつでもどこでも起動してくれます。 VS2005までは最初にそれっぽいキーワードを入力するまではインテリセンスが起動しなかったんですが、VS2008では1文字目からいきなり起動します。 ある意味インテリセンスの最終形態。
上記記事はVB2008の記事ですが、ちょっと確認した限りではC#も同じでした。
VS2008のDataTipsは参照するだけでもかなり強力ですが、なんとDataTips上で値の変更も可能です。 わざわざウォッチに追加して変更するまでもない場合はこの方法で変更するのが一番手っ取り早いかもしれません。
VSの「リンクとして追加」は、VSSとは相性が悪いみたい。VSSの「共有」でモジュールを共有した方が、VSSとの連携と言う意味では良さそう。
型付データセットを共有する場合は、VSからVSSの共有の機能を使って共有するんじゃなくて、まずVSS単体で対象プロジェクトに関連ファイル（*.xsd,*.vb,*.Designer.vb,*.xsc,*.xss）を全て共有する。その後、VSでプロジェクトに含めるようにする。 こうしないと、中途半端な共有になってしまう時があるっぽい。 また、例えば *.vb がなくて *.Designer.vb があるような状態だと *.Designer.vb がパーシャルクラスとして認識されないっぽいので、この場合は元のプロジェクトであらかじめ *.vb ファイルを生成しておく。 また、プロジェクトに含めた際、*.Designer.vb とは別に *1.Designer.vb みたいなファイルが新たに作成される時がある。中身は *.Designer.vb とほとんど同じっぽいのだが、宣言が全て被ってしまうので、不要な *1.Designer.vb は手動で削除する。
共有されているファイルを完全に削除する場合は、VSから削除するんじゃなくてVSSから削除した方が良いかも。 VSでも削除は出来るけど、「完全な削除」は行われないみたいで、ファイルは削除されるけど共有した関係は履歴みたいな形で残ってしまう。 一度この状態になった場合も、再度共有して、改めてVSSから完全に削除すれば問題ない。
単語単位で文字を選択する場合、Ctrl+Wやマウスのダブルクリックなどで行えるが、 Ctrlキーを押しながらマウスの左クリックでも単語選択できる。 単語単位でのコピー＆ペーストを続けて行う場合、マウスのダブルクリックが不要になるのでちょっと（と言うか結構）楽。
VSSに登録されているソリューションを開発端末から初めて開いた時に、 ソリューションが管理してるWebプロジェクトを開発端末のどの場所にコピーするかを（URLで）聞かれる。 よって、ローカルでは自分の好きな場所にWebプロジェクトを配置することが可能となる（IISの設定も自動で行われる）。 この時、「ソース管理サーバーの場所」は各プロジェクトフォルダの直下に作成される「mssccprj.scc」に書き出され、 「ここに作業ファイルの場所を入力して下さい」に入力した開発端末での作業場所は、 「[プロジェクト名].vbproj.vspscc」又は「[プロジェクト名].vbproj.webinfo」 のどちらかに書き出されると思われる（あんまり詳しく調べてない）。
ビルドは最後にビルドされてから変更があったファイルのみビルドする。 リビルドは、中間ファイルや出力ファイルなどを全てクリアして、 クリーンアップを行った後、ビルドする。 単純にビルドを行うと、実行されているモジュールが以前ビルドしたモジュールの場合がある（ビルド自体は行われているっぽい）。 そのような場合は、恐らく以前の中間ファイルなどが使用されている可能性が高いので、クリーンアップ処理も行われるリビルドを行う。
ASP.NETの場合、Webアプリケーションの実行ファイル（DLL）が格納されているフォルダは2箇所ある。
1つ目は対象Webアプリケーションの物理フォルダのbinの下。
2つ目は
%SYSTEM%Microsoft.NET\Framework\[バージョン]\Temporary ASP.NET Files\[仮想ディレクトリ名]\...\assembly\
の下の方。
[仮想ディレクトリ名]はちょっと正確じゃないかもしれない。
で、実行時（デバッグ実行も含む）に実行されるファイルは2つ目の方に格納されているDLL。
対象プロジェクトをビルドした場合、前回から変更があったソースだけビルドされ、1つ目のフォルダにDLLが生成される。
対象プロジェクトをリビルドした場合、全てのソースがビルドされ、1つ目のフォルダにDLLが生成される。
上記処理内容からも判断できるが、VisualStudioのビルド操作は2つ目のフォルダのファイルには無関係。
2つ目のフォルダのファイルはASP.NETアプリケーションが実行された場合
（IIS（嘘。より正確にはASP.NETランタイム）によりアクセスされた場合）に初めて操作される。
この「2つ目のフォルダのファイルが操作される」トリガーが問題。
ビルドを行った場合、そのWebアプリケーションが実行されても2つ目のフォルダのファイルが更新されない事がある。
実際に実行されるのは2つ目のフォルダのファイルなため、以前のソース（DLL）が実行されていることになる。
リビルドを行った場合、そのWebアプリケーションが実行されると2つ目のフォルダが最新の状態に更新されるので、
最新のソース（DLL）が実行されることになる。
でも、2つ目のフォルダってやっぱりVisualStudio絡みのフォルダ？？
ブラウザから直接Webアプリケーションを実行した場合、2つ目のフォルダは操作されなかった（例えフォルダ自体が存在していなくても）。
ちなみに、デバッグ実行中にブレークポイントがずれたり、 ブレーク情報の表示が変だったりした場合はほぼ確実に実行されているファイルが古い（もちろんVisualStudio上に表示されているのは最新ソース）。 そういう場合は、迷わずリビルド。
でも・・・リビルドして、2つ目のフォルダのファイルが最新になったとしても、なぜか以前の状態が実行されることがある。 もう一度リビルドしたりしてると最新になったりするけど・・・もしかしたら2つ目のフォルダのファイルが実行されているわけですらない？ だとしたらどこのファイルが実際に実行されているの？
Visual StudioでWebアプリケーションをビルドすると、対象プロジェクトの（Web）アプリケーション名のbinサブフォルダではなくて、 対象プロジェクトの物理フォルダのbinサブフォルダにDLLが作成される。 ただ、面白いというか良くわからないのが、対象プロジェクトが他のプロジェクトを参照している場合、 このプロジェクトをビルドすると参照している他のプロジェクトも（必要となるので）コンパイルされるが、 このDLLについては（正しく）（Web）アプリケーション名のbinサブフォルダに配置される。 本当だったら対象プロジェクト自体のDLLもそうなってくれないと困る気がするんだけど・・・なんで自分のDLLは配置されないんだろ。
・・・原因判明。 Webプロジェクトのビルド時のDLL作成先フォルダは対象プロジェクトの物理フォルダのbinサブフォルダ固定と言うわけではない。 プロジェクトのプロパティ - [構成プロパティ] - [ビルド] に、「出力パス」の指定する箇所があり、 そこのデフォルト設定が「bin\」になっている。 よって、Visual Studioでビルドした場合、 自分のWebプロジェクトに関してはIISでの仮想ディレクトリは無視してここで設定しているフォルダにDLLが作成される。 対象Webプロジェクトの仮想ディレクトリが変更されてもここの設定が自動で変更されるわけではないので、 状況によってここの設定も変更した方が良いかも。
この辺の話については、Webアプリケーション開発技術大全にも詳しく載ってる。
Visual StudioではプロジェクトのDLL出力パスはプロジェクト以下の 階層にしか設定できない（何でだよ・・・）。
後、参照しているプロジェクトについてはWebアプリケーションのbinに配置されると書いたけど、たぶん嘘。 試したところでは、ビルドを行うと参照先のプロジェクトがビルドされて、 参照先のプロジェクトの出力パスに参照先プロジェクトのDLLが作成され、 自プロジェクトの出力パスに参照先のプロジェクトのDLLと自プロジェクトのDLLが作成される。
（複数メンバーによるVSSでの管理を前提として）各サブシステムごとにプロジェクトをわけた方が良いと思う。 また、この時の分け方が問題になるわけなんだけれども、基本的には細かすぎず大雑把過ぎず、 1人1プロジェクトで作業できる粒度が開発し易い。 ただ、（中規模以上のシステムには関わったことがないので何ともいえないけど） 1ソリューションが抱えるプロジェクトの数が増えてくるとプロジェクトをロードするだけで凄い時間がかかってくるようになるので、 その辺も考慮しないと後々大変な事になってくるかも・・・。 取りあえず、2桁までだったらあまり問題ないと思う。 プロジェクト数が3桁4桁とかになってくると、VSSからロードするだけで大変な事になってくるかも・・・。 もしかしたら、まともにロードできなくなるかもしれない。まあ、そういう経験は今のところないので、予想だけど。
各開発者が自分の持分（担当プロジェクト（サブシステム））の開発を行うときは、 ローカル開発用のソリューションを作成し、そのソリューションに必要なプロジェクトのみ追加して開発を行うのも良い。 こうすることで、必要のないプロジェクトのロード時間などがかからなくなり、 もし他のサブシステムで問題があった場合も自分の開発には影響がでなくなる（逆も同じ）。
この辺については、Webアプリケーション開発技術大全にも詳しく載ってる。
プロジェクトの数は2桁だったらあんまり問題ないと書いているが、2桁後半でソリューションが開けなくなるときがあった。 ソリューション開いている最中にオフラインキャッシュがどうのこうので固まってしまう。 はっきりとした数はわからないが、できれば2桁前半ぐらいの数に収めた方が無難かも・・・。
開ける開けないの問題ももちろんあるが、開けるとしても速度が遅いと仕事にならない。 この辺りマシンスペックや状況によってもかなり変わってくるとは思うが、 1開発者が自分用のソリューションで扱うプロジェクト数は20以下に抑えるのが理想。 30以上とかになってくると毎回ビルドするのに数分以上かかるようになり、仕事にならない。 もちろん、環境や状況によって違うので一概には言えないけど。
コーディングしていると、インデントがずれることがある。 とりあえずインデントがずれているだけなので実行には何も問題ないし、 ずれているコードに対して何か操作しようとすると（オプションの設定にもよると思うが） 勝手にインデントしなおしてくれるのでそこまで問題はないのだが、「ずれていると思われる」箇所を的確に見つけるの もこれはこれでめんどくさい。 こういう時は、対象とするコードを含んでいるメソッド名を操作する。 操作すると言っても、スペースやタブを適当に入れるだけでよい。 こうすると、そのメソッド内全てのコードが整形しなおされる。
・・・メニューの[編集] - [詳細] - 「ドキュメントのフォーマット」を実行すれば万事OKっぽい・・・。
[オプション] - [環境] - [プロジェクトおよびソリューション]の 「ビルド/実行オプション」の「実行時に、スタートアッププロジェクトおよび依存関係のみをビルドする」にチェックをつける。 この項目にチェックをつけておくと、実行時に開発対象としているプロジェクトとそのプロジェクトが依存するプロジェクトのみビルドされ、 他の関係ないプロジェクトはビルドされないのでビルド時間が節約できる。 ソリューション全体のプロジェクトをビルドしたいのであれば、メニューの[ビルド] - [ソリューションのビルド]で行える。
(2008/02/02)上述していますが、VS2008では Me 使う必要ありません・・・。
Visual Studioで開発すると、インテリセンスが利用できる。 これがまた便利なんだけど・・・最初になんかのキーワードを打たないと、インテリセンスが働かない。 なので、他のオブジェクトのメソッドを呼ぶ時とかは自動で働くんだけど、 自分のクラス内のメソッドやフィールドをそのまま書いてもインテリセンスは働いてくれない （Ctrl+Jとかの方法もあるにはあるけど）。 そんな時に、Meキーワード。 Meキーワードは自分のインスタンスを指すので、自分のクラス内のメソッドやフィールドがインテリセンスにより列挙される。 ただ、これを使うと（当たり前だけど）ついてなくても構わない「Me.」の3文字がやたらと出現することになる。 ・・・けど、使い出したらもう止まらないはず。 やたらと現れる「Me.」についてはもう見てみぬ振りするしかない。それだけの価値がインテリセンスにはある。
以下のページを参照。でも、あまりにも数が多すぎて覚えきれません・・・。
ソリューションに「Webの既存プロジェクト」を追加する場合、 URLで指定したフォルダの見え方はブラウザでそのURLを指定した場合と同じなので、注意。 指定したディレクトリのISMでの「ディレクトリ参照」がチェックされていなければブラウザでもディレクトリ情報は見えないし、 「Webの既存プロジェクト」ダイアログでも見えない。
既存のWebプロジェクトをソリューションに追加しようとした場合、以下のようなメッセージが出て追加できないときがある。
「開こうとしているプロジェクトはWebプロジェクトです。URLパスを指定してプロジェクトを開いてください。」
・・・つまるところ、 「Webプロジェクトだから実行するにはURLが必要でしょ、けどその情報が見つからないんで、このままじゃソリューションに追加できないんですけど。」 ということを言いたいのかと思われる。
上記メッセージが出て追加できないのは状況によって異なる。
1．「既存のプロジェクト」及び「Webの既存プロジェクト」のどちらでも追加可能。
→たぶんwebinfoファイルが存在している
2．「Webの既存プロジェクト」でのみ追加可能。
→？？
3．どちらでも追加不可能。
→原因不明。まずwebinfoがないのは条件の一つっぽい。
それプラス、以前そのソリューションに登録してあり、
一旦ソリューションから削除したプロジェクトだったりすると駄目だったりするっぽい。
ただ、できる場合もあるし、具体的な条件は不明。ISMでの設定も絡んでるか？？
新しいソリューションだと追加できたりするので、そういう方法も試してみる価値はある。
一旦登録できればwebinfoが作成されるので、どのソリューションにも追加できるようになる。
まあ、webinfoを自分で用意しちゃうってのが最終手段だけど。
ちなみにwebinfoファイルはローカルでのURL紐つけに必要となるファイルなので、VSSには登録されないので注意。 ソリューションにWebプロジェクトが追加された際にwebinfoファイルは自動的に作成される。
VSでプロジェクトのビルドを行った場合はそのプロジェクト及びそのプロジェクトが参照している（依存関係がある） プロジェクトのファイルに変更があった場合にそれぞれコンパイルが行われる。 プロジェクトのリビルドを行った場合はそのプロジェクト及びそのプロジェクトが参照しているプロジェクトが全て強制的にコンパイルされる。 コンパイルが行われたプロジェクトに関しては、そのプロジェクトを参照している他のプロジェクトにも自動的に反映される。
他のプロジェクトのファイルが変更されていたとしても、 そのプロジェクトとビルド対象プロジェクト間に依存関係がなければビルド対象とはならないので注意。 全プロジェクトをビルド対象としたければソリューションのビルドを行うのが手っ取り早い。
VSでプロジェクトのデバッグを開始（デバッグなしで開始も含む）した時は、 スタートアッププロジェクトに対してプロジェクトのビルドが行われる。
当たり前だが、VSSとプロジェクトのリンク（バインド）は一対一になる。 よって、適当なフォルダに存在するプロジェクトをVSでVSSに登録して、 その後正式なフォルダにダウンロードして管理したい場合は、適当なフォルダに存在するプロジェクトをVSSに登録した後、 そのプロジェクトとVSSのバインドを解除する。 一旦バインドを解除してしまえばもうそのプロジェクトとVSSの関係はなくなるので、何も気にせず正式なフォルダで管理することができる。 適当なフォルダのプロジェクトとVSSのリンクを解除していない場合、 VSSの1ファイルについてローカルでは複数のファイルとリンクしていることになってしまい、色々とエラーが出たりしちゃう。
・・・当たり前とは書いたが、別にそういうわけでもないか。 VSS上のローカル作業フォルダはVSSサーバ上のiniファイルに記述されているし、 ローカルのプロジェクトのVSS参照先はプロジェクトごとに記述されているので、 これだけを見ると競合が発生していても分からない気がするけど・・・検知するということはどこかで判断できると言うことなんだろう。 どこでかがわからないけど・・・。
ちなみに、VSを開く際にプロジェクトのバインドでエラーが発生してVSSとのバインドが行えない場合がある。 この場合、再バインドも不可になる可能性があるので、その場合は新しいソリューションを作ってそこに追加すれば問題なくなることがある。 この動きを見る限り、VSSとプロジェクトのバインド情報はソリューションのどこかに保持しているとしか思えないんだけど・・・詳細不明。
ソリューションからプロジェクトを削除した場合、そのプロジェクトを参照している他プロジェクトの参照設定からも自動で削除されてしまう。 ローカルだけで使用しているソリューションだからと言って気軽にプロジェクトの削除を行うと、 状況によっては他のプロジェクトに影響が出る可能性があるので注意する。
他プロジェクトの（該当プロジェクト）参照設定削除処理は何の警告もなしに自動で行われるので注意が必要。 ただ、チェックアウトされていなければチェックアウト処理のダイアログは表示されるので、それで確認することは可能。
どちらにしろ、チェックアウトの取り消しを行えば済む問題ではあるので、そこだけ注意すれば問題ない。
変数名の説明とかのコメントがずれちゃったのを複数行まとめて揃えたい時は、 ずれてるコメントをAltキー押しながらマウスドラッグで範囲指定し、 メニューから[編集]-[詳細]-[左右スペースの削除]でトリムをかけ、後はタブで適当に配置。
次の行にカレント行をコピーしたい時、キーボード操作だったら「Ctrl+L」「Ctrl+V」×2回がたぶん一番速い。
.NET Framework以外の例外を捕捉したい場合は、 [デバッグ]-[例外]の「追加」で、追加したい例外クラスの名称を名前空間も含めたフル名で入力する。
例：
Npgsql.NpgsqlException
デバッグ開始時、以下のようなエラーが出ることがある。
'System.UnauthorizedAccessException' の初回例外が mscorlib.dll で発生しました。 追加情報 : パス "Mono.Security.DLL" へのアクセスが拒否されました。
取りあえず、例外スロー時にデバッガで中断する設定を行っていないか確認する。 行っているんだったら、例外スロー時に実行を継続する設定に変更して、再度試してみる。
と言うか、.NET Frameworkモジュールやサードパーティのモジュール（と言うか要は自分が作成した以外のモジュール）で例外が発生した場合は、 まず例外スロー時の設定を疑ってみる。
ウォッチ式で参照型の値を確認しようとしたときに、以下のメッセージが出て値が確認できないときがある。
「現時点では、式を評価できません。」 「error: cannot obtain value」
詳しくは分からないが、環境やコードが悪いというわけではなく、 値を評価しようとしている時点でVisual Studioが把握しているデータの量が多いと、 上記のエラーが出てウォッチ式による値の確認ができなくなることがあるらしい。 ちなみに、特に何もしなくてもローカルや自動変数により自動である程度のデータの把握はされているはず。
プロパティに関しても返り値が基本型であったとしても最終的にはメソッドなので見れない。 まあ、つまるところこの症状が出るとほとんど見れない。
ちなみにウォッチ式で値の確認ができないと言うだけで、実際の処理は問題ない（当たり前か）。
Visual Studioで作成したプロジェクトをVSSへ追加する場合、VSSエクスプローラを使って手作業で登録してはならない。 該当プロジェクトファイルのうち、VSSに登録すべきファイルなのかそうでないファイルなのかは、VSが知っているので、 VSからVSSへ登録を行えば適切な登録を行ってくれる。 VSからの登録方法は、ソリューションエクスプローラで対象プロジェクトを選択して、 [ファイル]-[ソース管理]-[選択されたプロジェクトをソース管理に追加]から登録を行う。 「Visual SourceSafeに追加」ダイアログでVSSのエントリポイントをツリーから選択し、 もしそこに新たにサブプロジェクトを作るのであれば、「プロジェクト」にサブプロジェクト名を入力する。 ツリーで選択したエントリポイント直下に配置するのであれば、「プロジェクト」を空にして登録する。 「作成」ボタンを押すと、 ツリーで選択されているサブプロジェクトの下に「プロジェクト」に入力されている名称で新たにサブプロジェクトが作成されるので、 これを繰り返すことで目的とする場所までサブプロジェクトを掘る事が可能（もちろん、事前にVSSでサブプロジェクトを作成しておいてもOK）。 注意しなければいけないことは、「作成」ボタン押下時も「OK」ボタン押下時も、 ツリーで選択している場所に「プロジェクト」に入力されている名称で新たにサブプロジェクトが作成される点 （共用されているのでちょっと分かりづらい）。
原因はどうでもいいが、VSとVSSとの接続を一旦切断してしまうと、手動で再接続させないとVSSから切断されたままになるので、注意すること。 チェックアウトしていないファイルのアイコンは変わらないので意外と気づきにくい。 チェックアウトしているアイコンに関しては接続している時のアイコンと異なるのでそれで気づくかもしれない。
[ファイル]-[ソース管理]-[ソース管理の変更]で接続させる。
エラーがないかタスク一覧を最後に表示するおまけつき。 コマンドバーに「ソリューションのリビルド」ボタンを用意しておけば完璧
' 全プロジェクトの最新をVSSから取得する
Sub GetLatestSolFromVSS()
Dim Sol As Solution = DTE.Solution
Dim fiSol As FileInfo = New FileInfo(Sol.FullName)
Dim strSolName As String = fiSol.Name.Substring(0, fiSol.Name.Length - fiSol.Extension.Length)
' ソリューションを選択
DTE.ExecuteCommand("View.SolutionExplorer")
DTE.ActiveWindow.Object.GetItem(strSolName).Select(vsUISelectionType.vsUISelectionTypeSelect)
' VSSから最新を取得
DTE.ExecuteCommand("File.GetLatestVersion")
' タスクリストをアクティブに
DTE.ExecuteCommand("View.TaskList")
DTE.Windows.Item(Constants.vsWindowKindTaskList).Activate()
End Sub
プロジェクトの数が増えてきた時に便利かも
' ソリューションエクスプローラの全プロジェクトを折り畳む
Sub UnExpandAllProjects()
' ソリューションエクスプローラをアクティブにして、ソリューションを選択
Dim Sol As Solution = DTE.Solution
Dim fiSol As FileInfo = New FileInfo(Sol.FullName)
Dim strSolName As String = fiSol.Name.Substring(0, fiSol.Name.Length - fiSol.Extension.Length)
DTE.ExecuteCommand("View.SolutionExplorer")
DTE.ActiveWindow.Object.GetItem(strSolName).Select(vsUISelectionType.vsUISelectionTypeSelect)
' 全プロジェクトを折り畳む
Dim UIHItem As UIHierarchyItem
Dim UIH As UIHierarchy = _
CType(DTE.Windows.Item(Constants.vsWindowKindSolutionExplorer).Object, UIHierarchy)
For Each UIHItem In UIH.UIHierarchyItems.Item(1).UIHierarchyItems
UIHItem.UIHierarchyItems.Expanded = False
Next
End Sub
リビルドとかは正常にできてるのにステップ実行がうまくいかない（ステップオーバーで次の行に進まないとか）場合は、 「デバッグ」-「ステップ バイ」が「ステートメント」以外になっていないか確認する。 ちなみに通常は「ステップ バイ」なんてメニューには存在しないし自分で変更しない限り「ステートメント」以外になったりはしないはずなので、 この問題が出ることはないはず。 後、この値が「ステートメント」以外の場合はブレークポイントの表示が左側の「●」だけになって行自体のカラーリングは行われないので、 それでも判断できると思う。 「ステップ バイ」は[ツール]-「カスタマイズ」-「コマンド」で「デバッグ」の中に存在する。
テキストエディタの「フォント及び色」の表示項目のうち、 「かっこの一致」ぐらいは「赤」とかに変えておくと見易いかも。 他の表示項目は特にいじりたいような項目なし・・・。
VSでVSS管理しているファイルを含むソリューションを開くと、基本的にVSSへのログオンダイアログが表示されて、 アカウントとパスの入力を求められる。 ので、通常はVSSへ接続する際のアカウントは自分で入力（選択）可能なのだが、パスなしのVSSアカウントで一旦接続すると、 以降はVSSに接続しなおさない限りノーダイアログでVSSへの接続が行われる。 この際使用されるアカウントは前回接続した際のログインアカウントが自動で使用される。 VS起動時に自動で接続試行されるアカウントは、[ツール]-[オプション]-「ソース管理」-「SCCプロバイダ」の「ログインID」で設定・確認できる。 ただ、この「ログインID」の設定値は、VSSに接続された状態だと変更することができない。 ので、一旦パスなし（ノーダイアログ）のアカウントで接続してしまうと、 次回以降も自動でノーダイアログでそのアカウントによる接続が行われてしまい、 且つ接続されているのでオプションダイアログからも変更することが出来ないので、 他のアカウントに変更できないように思えてしまう・・・が、上述しているようにVSSに接続していない状態なら変更可能なので、 VSを単独で起動するとか一旦VSSとの接続を解除するとかすれば、変更が可能となる（前者の方法が簡単）。
VSで新しいWebアプリケーションプロジェクトを作成しようとすると、 格納されるフォルダ名とプロジェクト名は同じ名称でしか作成できない（少なくとも自分が知っている限りは）。 もしプロジェクト名と格納フォルダ名を別にしたい場合は、少しめんどくさいが以下の方法で行う。
1．正式なプロジェクト名（フォルダ名としては間違っている）でWebアプリケーションプロジェクトを作成する。
2．作成したプロジェクトをソリューションから削除する。
3．エクスプローラで正式な名称のフォルダを適切な場所に作成し、そのフォルダに1で作成したファイル群を移動する。
4．VSで「Webの既存プロジェクト」として3の場所に移動した対象プロジェクトをソリューションに追加する。
上記作業で、格納フォルダ名とプロジェクト名が別のWebアプリケーションプロジェクトが作成できる。 ここで重要なのは、プロジェクトが存在する位置は比較的楽に変更できるが、 プロジェクト名については内部的に関わってくる箇所が何点か存在するので、プロジェクト名については初めに正式な名称で作成することが重要。 VSはプロジェクト作成時、アセンブリ名やルート名前空間にプロジェクト名と同じ値を設定する。 後で変更することも可能だが、めんどくさいので最初から正式な名称でプロジェクトを作成してしまう方が楽。
もし上記方法とは逆の手順で行う場合、プロジェクト名を正しい名称に変更した後、 アセンブリ名やルート名前空間、及びそれに影響する箇所も適宜変更すること。
[ツール]-[カスタマイズ]-「コマンド」タブでツールバーの詳細なカスタマイズが行える。 ツールバーに配置済みのボタンを選択して「選択したボタンの編集」ボタンをクリックすれば、 そのボタンに対する詳細な設定（イメージ、テキストの表示非表示、名称変更、グループの始まりの挿入など）が可能。
Option StrictがOnになっていないか確認する。 ウォッチリストではOption Strictは常にOffっぽいので、暗黙の変換もエラーなしに行えてしまう。
VSからチェックインを行う際は、チェックインする前に自分の環境でエラーが発生していない（ビルド可能）か確認するのは当たり前だが、 それに加えて「チェックアウトしているファイルを全てまとめてチェックインする」必要がある。 個別にファイルをチェックインすると、自分の環境では問題ないが、 他の端末で最新を取得した時にファイルの整合性が取れていなくてエラーとなってしまう場合がある。 なので、ソリューションごとチェックインするとか、 「保留中のチェックイン」ウィンドウを使うとかしてまとめてチェックインするように心がける。
同じ画面を複数人が同時に変更する可能性がある場合、場合によってはチェックアウトの仕方を気をつけなければならないかもしれない。 aspxはとりあえず大丈夫っぽいが、 ものによってはデザイン（.aspxとか）とコードビハインドのコード（.aspx.vbとか）をそれぞれ別々にチェックアウトして作業を行える場合がある。 デザインとコードは別々のようで結構密接に結びついているので、 少なくとも継承元のデザインファイルをチェックアウトする場合は継承先のコードファイルもチェックアウトしないと、 まずい事になる場合がある。 例えば、デザインとコードを別の人がチェックアウトしていて、 コードをチェックインした後にデザインファイルをチェックインすると、 コードが昔のコードでチェックインされてしまったりする（VSSの仕様的にあり得ない気もするが、ActiveReportsでは実際にありえる）。 ファイルを暗黙的にチェックアウト（何らかのプロパティやコードを変更しようとした結果、VSが勝手にチェックアウトしようとするやつ） するとそういうチェックアウトの仕方が有り得るので、そういう場合は継承元のファイルを選択して明示的にチェックアウトする。 そうすると継承先のファイルもまとめて同時にチェックアウトされるので、一部のファイルのみチェックアウトしてデグレする可能性もなくなる。 この動きに関してはもしかしたら継承とかは関係ないのかもしれないけど、その辺はあまり調べてない。
ま、色々と方法はあるけど、例えば次のような方法で比較的簡単にスロー箇所の特定が可能。
1. エラーが発生すると思われる箇所の手前にブレークをはる（例えば、Page_LoadとかでもOK）。
2. 1のブレークで止まったら、メニューの[デバッグ] - [例外]を選択し、例外ダイアログのツリーから 「Common Language Runtime Exceptions」を選択し、下の「例外がスローされたとき」の設定を「デバッガで中断」に設定する。
3. 実行を再開する。
4. CLRのExceptionがスローされた箇所でブレークされる。
5. 後は、やりたいことをやるだけ。ウォッチで値を確認するも良し、呼び出し履歴でコールスタックを確認するも良し。
6. 実行を終了したら、2で変更した「例外がスローされたとき」の設定を「継続」に戻しておく。 そうしないと、単純に実行するだけでもブレークしまくり（内部的に例外が発生している場合だけど）なので注意。
ブレークポイントを設定することにより、その行が実行されるタイミングで止めることが可能だが、場合によっては止まる時の条件をもうちょっと指定したい。 ブレークポイントを設定した後、ブレークポイントのマークを右クリックすることにより、更に条件を追加することができる。 例えば、特定のメンバの値が特定の値だった場合のみブレークしたい場合は、以下のような条件設定を行えば良い。 追加設定が行われたブレークポイントはブレークポイントのマークも変わるみたい。
全画面表示した時も通常と同様のツールバー項目を表示するには、 「全画面表示」ツールバーの枠内に必要なツールバー項目を全て移動させれば大丈夫そう。
基本的にデザイナ上で操作していれば両者の定義は合っているはずだが、 色々なことをやっているうちにどうしても整合性が取れなくなってくる。 aspxに存在しないコントロールがaspx.vbにゴミとして残っている場合が比較的多い気がするが、 そのような状態から1つ1つ確認しつつ正しい状態に戻すのはかなりめんどう。 この場合、相当強引だがaspx.vbのコントロール定義を全て手動で削除した後にaspxのコントロールを少し移動させたりすると、 aspxに定義されているコントロールだけがaspx.vbに再定義される・・・と思う。 かなり強引なので、駄目だった時に備えて事前保存必須。
VSで検索した場合、今現在どんな条件で検索しているのかは実はステータスバーに全部表示されてたりする。 ・・・でも、全画面表示だとステータスバーが表示されないんだよなぁ。 オプションから表示するように設定しても、設定が保存されてないっぽいんだよなぁ・・・。