Visual Studio .NET の Windows フォームで "View Designer" を実行しようとすると、"ファイルまたはアセンブリを読み込めませんでした..."というエラーが発生したことはありませんか?
この場合、問題のアセンブリはXYZ.dll. XYZ.dllプロジェクトの参照へのすべての参照を追加し（プロジェクトはそれらに直接依存していませんが）、ソリューション全体を再構築することで、これを修正できました。ただし、その後、プロジェクトからこれらの参照をすべて削除して再構築しましたが、それでも機能しました。
もう 1 つの情報は、Resharper 2.5を使用しているということです。他の誰かが、Resharper がシャドウ コピーを行っている可能性があると指摘しました。今度こういうことがあったら調べます。そもそもこのエラーが発生する理由と、おそらくそれを修正する「正しい」方法を理解している人はいますか?
同じ問題があります。一部の Form/UserControl クラスはデザイナーで表示できず、Visual Studio でさまざまな例外が発生します。
典型的な原因が 1 つあります。設計されたコンポーネントの 1 つが、初期化中に未処理の例外をスローしました (コンストラクター内または Load イベント内または前)。
この場合だけでなく、Visual Studio の別のインスタンスを実行し、いくつかの独立したプロジェクトを開いて作成し、メニュー -> デバッグ -> プロセスにアタッチ ... -> 問題のあるデザイナーで devenv.exe プロセスのインスタンスを選択します。次にCtrl+Alt+Eを押すと、「例外」ウィンドウが表示されます。例外のカテゴリに「Throw」をチェックします。
現在、デザイナーでビジュアル スタジオをアクティブにして、ビュー デザイナーを試してください。例外がスローされる場合は、コールスタック (および、例外がコードからスローされた場合はソース コード) と、スローされた例外に関するその他の一般的な情報が表示されます。この情報は非常に役立つ場合があります。
これは古い質問ですが、ここでも、より広いフォーラムプールでも、まだ答えがないようです。ほとんどのアドバイスは、絶え間なくクリーン>再構築または閉じる>クリーンフォルダー>マシンを再度開くか再起動することに関するものです。いくつかの調査を行い、共有するかもしれないと思っていましたが、現時点では確固たる答えはありません。要約すると、コントロールまたはフォームの設計時にすべてのデザイナーファイルがコピーされる場所、古いファイルが存在する可能性のある場所、およびデザイナーがエラーページを生成する前にすべてのデザイナー例外をキャッチする方法が説明されています。
アセンブリをロードできないか、見つからない場合が2つあるようです。1つは、ファイルが設計者が必要とする場所にコピーできないことが原因で発生し、2つ目は、古いファイルが残されていることが原因です。
上記のように、プロジェクトが、参照される参照とその参照に必要なすべての参照を再帰的にフレームワークまで直接参照できない場合、ファイルのコピーに失敗する可能性があります。これは、すべての参照とその依存関係を注意深く追跡し、すべてが考慮されていることを確認することで軽減できます。
Visual Studioデザイナーは、特定の場所を使用して、プロジェクトのソース/ binフォルダーから分離された、デザイナーで使用するdllをキャッシュします。
Windows XP：
C：\ Documents and Settings \ [user_name] \ Local Settings \ Application Data \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies
Windows 7：
C：\ Users \ [user_name] \ AppData \ Local \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies
この場所で、コンパイルされたアセンブリは、動的に作成されたフォルダーにコピーされます（アセンブリごとに1つのフォルダー）。この場所でアセンブリのバージョンの日付を確認すると、Visual Studioが終了すると削除され、かなり最新のようです。新しくコンパイルされたファイルでデザイナーを表示すると、すべてのアセンブリがコピーされます。各設計者のこの場所には、各アセンブリの新しいコピーが作成されるため、この場所には、各アセンブリの複数の同一のコピーが保持される場合があります。
ただし、アセンブリをコピーできる場所がもう1つあり、アセンブリ検索シーケンスの一部であり、明らかにProjectAssembliesフォルダーの前にあり、次の場所にあります。
C：\ Program Files \ Microsoft Visual Studio 10.0 \ Common7 \ IDE
アセンブリがこの場所にいつどのようにコピーされるかはわかりませんが、ここに到着するファイルがすぐに古い参照のソースになることはめったにありません。設計者が「ファイルまたはアセンブリのロードに失敗しました」エラーで失敗した場合、設計者が求めたバージョンは、この場所のアセンブリによってのみ参照されたバージョンでした。
これは、最初に2番目のVisual Studioインスタンスのデバッグを使用し、すべての.netシンボルが読み込まれ、すべての既知の例外が未処理の場合とは対照的にスロー時に中断することで発見されました。これにより、2番目のインスタンスが処理されたデザイナー例外をインターセプトし、そのファイルの場所を明らかにすることができました。これは、私が使用したデザイナーエラーの結果の出力でした。
=== Pre-bind state information ===
LOG: User = **************
LOG: DisplayName = ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 10.0/Common7/IDE/
LOG: Initial PrivatePath = NULL
Calling assembly : ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ソリューション内のすべてのプロジェクトのすべての bin および obj ディレクトリを削除します。C:\Users<User>\AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssemblies のフォルダーも削除します。VS2008 には 9.0、VS2010 には 10.0 などを使用します。
この問題はさまざまな理由で発生すると思いますが、とにかく私のケースを共有したいと思いました。誰かが自分のプロジェクトで何が起こっているのかの手がかりを見つけてくれることを願っています.
Visual Studio (C# プロジェクト) がマネージド c++ dll を見つけられず、それを J Collins の投稿に記載されている場所にコピーできなかったため、私の問題が発生しました => デザイナーがファイルを見つけられませんでした。他の DLL:s と一緒にそこにコピーされていないことに気付き、異なる/非標準の出力ディレクトリがあることがわかりました。これを標準に変更すると、Visual Studio でコピーが実行されます。
特にカスタムコントロールをwinformに追加するときに、VS2005で非常に頻繁に起こりました。通常、追加の参照を追加したり、VS を閉じて再度開いたりすることなく、再構築するだけで済みました。
これには明らかな原因はなく、VS のバグだけです。
VS2005 と VS2013 を使用していますが、同じ問題が発生しました。私のプロジェクトの一部の Visual Studio フォーム デザイナーは動作しますが、他のデザイナーはデザイン モードで開きません。エラーページが表示される前に、いくつかの開こうとすると Visual Studio がクラッシュし、次のように表示されます。
デザイナをロードする前にデータが失われる可能性を防ぐには、次のエラーを解決する必要があります。
観察:
フォームに継承されたコンポーネントがある場合、デザイナーは動作を停止する可能性があり
ます 観察の疑似コード例:
...
using System.Windows.Forms; // UserControl
namespace MyNamespace
{
public class MyForm : Form
{
public MyForm()
{
InitializeComponent();
...
}
private void InitializeComponent()
{
//this.ctrl = new MyNamespace.MyCtrl(); // Inherited class
this.ctrl = new System.Windows.Forms.UserControl();
...
}
//private MyNamespace.MyCtrl myCtrl; // Inherited class
private UserControl ctrl;
}
public class MyCtrl : UserControl
{
...
}
}
非擬似コードの実装では、継承されたコンポーネントをコメントアウトし、MyCtrl代わりMyFormに基本クラスを使用しましたUserControl。Visual Studio フォーム デザイナーが再び機能し始めました。Visual Studio Form Designer
を適切に作成する方法 - C# で相互作用する継承されたコンポーネント クラスは、私には理解できません。しかし、この観察は、それを解決できる誰かの手がかりになるかもしれません.
私は同じ問題に直面しました。プロジェクトから参照を削除して再度追加すると、すべて正常に機能します（ptojectファイルを見ると、参照定義が変更されていることがわかりました。たとえば、「SpecificVersion」タグが追加され、「false」に設定されています）。
私は、このような問題や他の多くの問題で、.NET フレームワークのインストールを中心に展開する傾向があることを発見しました。システム クラッシュ時など、多くの場合、ファイルが破損する可能性があります。仮想メモリがオフになっている場合。C:\WINDOWS\Microsoft.NET フォルダー内のファイルが破損した場合、これらのファイルは多数存在するため、正常に機能しません。エラーが常に発生するとは限りません。ファイルの一部は正常にロードされ、他の部分はロードされない場合があります。何年にもわたって、Microsoft.NET フォルダーのフル バックアップを、ある種の破損保護機能を備えたアーカイブに保存しておくとうまくいくことがわかりました。破損した .NET ファイルが原因で問題が発生することは、信じられないほど多くあります。IDE のほぼすべての側面は、IDE の一部や他の多くの機能に依存しています。もちろん、バックアップがない場合は、すべての NET FRAMEWORK インストールを UNINSTALL する必要があります (これはファイルが書き換えられることを保証しないため、修復しないでください。ファイルはチェックサムと長さのチェックに合格する可能性がありますが、それでも破損している可能性があります)。アンインストール後、システムを再起動し、Microsoft.NET フォルダー全体が削除されていることを確認します。削除されていない場合は、自分で削除します (これを行う必要がありましたが、一部のファイルはまだ残っています)。これが完了したら、NET フレームワークを再インストールします。OS によっては、すべてを取り除くことができない場合があります。しかし、Windows XPではできることはわかっていますが、テストに関する限り、自分で新しいOSでこれをテストしていません。使用している Visual Studio に応じて、2.0、次に 3.5 SP1 などをインストールすることから始めました。
また、フォームまたはコントロールにコントロールを含むライブラリのusing宣言があることを確認してください。デザイナーがそれを認識すると、Form.designer.cs ファイル内のオブジェクトへの参照に完全な名前空間を書き込みます。
将来この問題が発生し、下までスクロールして検索した人へ： Appdata/Local/Microsoft/VisualStudio/.. の ComponentModelCache を削除します。
Resharper のコメントに同意します。私は4.1を実行しています。無効にしてVS2008を再起動し、「Webアプリケーションに変換」を再度試したところ、うまくいきました。
このスレッドの回答は多少役に立ちましたが、カスタム ユーザー コントロールで何が起こっているのか正確にはわかりませんでした。
私の特定のケースでは、コントロールのスタイリング、バックグラウンド ログ、および私が常に行っている日常的なことを実行する汎用ヘルパー クラスなどを実行する多数のヘルパー クラス ライブラリがあります。
エラーが発生した場合にロギングを実行するために、これらの他のライブラリ静的メソッドのいくつかを使用していました。次に例を示します。
try
{
_InitializeStuff();
}
catch (Exception ex)
{
Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage);
}
ユーザー コントロールの Constructor、Load、および Property Set メソッドでこれを行いましたが、デザイナーは静的メソッド呼び出しへのパスを常に構築できるとは限らなかったため、デザイナーは失敗しました。
その周りに DesignMode チェックを配置しようとしましたが、問題は実行時ではなく、設計時であり、リンクを構築できませんでした。私にとって唯一のオプションは、カスタム ユーザー コントロールの次の場所にある静的ヘルパー クラスへのすべての参照を削除することでした。
残念ながら、セカンダリ IDE でこれをデバッグしようとして、Attach to Process を使用してもうまくいきませんでした。
私はこの問題に何度か直面しました。ほとんどの場合はclean+rebuild機能します (Visual Studio の再起動と組み合わされることもあります)。
clean+rebuildうまくいかなかったのは2回：
問題＃1
私が直面したケースの 1 つは、C# と VB.NET に関係していました。
デザイナーに読み込まれていないフォームにいくつかのユーザー コントロールがありました。ユーザー コントロールは C# でした。それらのほとんどは同じ名前空間の下にありましたが、アルファベットの大文字と小文字が一致しない名前空間の一部を持っていたものはほとんどありませんでした。
例えば：
userContorl1 was in myapp.mynamespace1, and
userControl2 was in myapp.myNamespace1
C# では大文字と小文字が区別されるため、これらは異なる名前空間です。ただし、VB.NET では大文字と小文字が区別されません。myapp.mynamespace.userControl2 を読み込もうとしたときに発生したエラーです。長い間苦労した後、エラーメッセージの名前空間に気付き、ユーザーコントロールで修正して、それらをすべて「myapp.myNamespace1」と同じにし、viola Designer を後で開きましたclean+rebuild。
問題＃2
私のフォーム (開いていなかった) には、多くのユーザー コントロールがありました。コントロールの 1 つは、列挙型のプロパティを持っていました。この列挙型は、ジェネリック クラス内で定義されました。デザイナーは、このユーザー コントロールのコードを次のように生成しました。
myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum
デザイナーを開くときに発生したエラーは、次のようなものでした。
タイプ somenamespace.SomeGenericClass[System.Date]+SomeEnum を読み込めませんでした
列挙型をクラスの外に移動し、デザイナー コードを次のように置き換えました。
myUserControl1.SomeType = somenamespace.SomeEnum
そしてデザイナーが開いた。:)
これが誰かに役立つことを願っています。