小規模なプロジェクトでは、デザインビューにほぼ即座に切り替えることができます（< 1秒）。デザインビューが非常に遅くなる原因は何ですか？
私は、デザインビューでコントロールやフォームを開くのに約60秒かかる大規模なプロジェクトを持っています。これは初回のみです。この60秒の遅延の後に、私はプロジェクトを再コンパイルするまで、ほとんどすべてのコントロールをデザインビューで開くことができます。
このプロジェクトによって構築されたexeが別の（小さな）プロジェクトで参照されている場合、小さなプロジェクトはすぐに大きなプロジェクトほど遅くなります。同様に、大規模プロジェクトのすべてのファイルを小規模プロジェクトに個別に追加すると、小規模プロジェクトは低速になります。
大きなプロジェクトは大きなManaged C++プロジェクトを参照しますが、小さなプロジェクトに同じ参照を追加して（参照から関数を呼び出してロードされていることを確認してください）、小さなプロジェクトはまだ高速です。
私の大きなプロジェクトはSandDockを使用しています。私の小規模プロジェクトでSandDockを使用している場合、まだ高速です。
大きなプロジェクトには、ツールボックスに表示される約60個のユーザーコントロールがあります。小さなプロジェクトに60個のユーザーコントロールを追加すると、小さなプロジェクトはまだ高速です。
[System.ComponentModel.ToolboxItem（false）]を使用してツールボックスからユーザーコントロールを非表示にすると、大きなプロジェクトはまだ遅いです。
この問題は、vs2005とvs2008の両方で発生します。
大きなプロジェクトでデザインビューを初めて開くのが遅いのはなぜですか？いくつかの他の参照？多数のコントロール？たくさんのクラス？その他の原因は？
ProjectAssembliesフォルダ（C：\ Documents and Settings \ tim.gradwell \ Local Settings \ Application Data \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies）が巨大であることがわかりました（1GB以上）、ここにあるほとんどのフォルダには私のManaged C++ dllのコピーがあります！これらのフォルダは、デザインビューが（再コンパイル後に）再オープンされるたびに再作成されるように見えます。これは減速と関係がありますか？
さらに情報：
ユーザーコントロールまたはフォーム内のToolStripは、フォームのロードに60秒かかります。ツールストリップを取り外すと（ただし、フォーム上にいくつかの異なるコントロールが残っている）、スイッチをデザインビューに即座に切り替えることができます。
これは全部の話ではありません...新しいプロジェクトのツールストリップは大きな減速を引き起こさないため、大きなプロジェクトでツールストリップに影響を与えるものがなければなりません。また、ツールストリップを持たない他のフォームやコントロールでは、デザインビューを表示するのにまだ60秒かかるので、ツールストリップに影響を与えているものは他のコントロールにも影響します。私は正確にどのコントロールを釘付けにしようとしているのでしょうか、それが原因であるのかもしれません！
わかりやすくするために、スローダウンを引き起こす大きなプロジェクトはC＃で正しいですか？ – overslacked
プロジェクトはC＃で書かれています...管理されたC++プロジェクトも参照していますが、管理されたC++プロジェクトを隔離して、その違いが生じたかどうかを確認する時間がありませんでした。 –