web-dev-qa-db-ja.com

Windowsフォームデザイナー：ファイルまたはアセンブリを読み込めませんでした

Visual Studio .NETのWindowsフォームで「デザイナーを表示」しようとするとエラーが発生するという問題が発生したことはありますか？"ファイルまたはアセンブリをロードできませんでした..."？

この場合、問題のアセンブリはXYZ.dllでした。これを修正するには、XYZ.dllとそのすべての参照をプロジェクトの参照に追加し（プロジェクトが直接依存していない場合でも）、ソリューション全体を再構築しました。ただし、その後、プロジェクトからこれらの参照をすべて削除し、再構築しましたが、引き続き機能しました。

もう1つの情報は、Resharper 2.5を使用することです。誰かがシャドウコピーを行うResharperかもしれないと指摘しました。これが次に起こるとき、私はこれを調べます。誰もこのエラーが最初に発生する理由と、おそらくそれを修正する「正しい」方法を理解していますか？

visual-studiowindows-forms-designer
48
Chien Chern Khor

同じ問題があります。一部のForm/UserControlクラスはデザイナーで表示できず、Visual Studioはさまざまな例外を引き起こします。

典型的な原因が1つあります。初期化中（コンストラクターまたはLoadイベントまたはそれ以前）に設計されたコンポーネントの1つが未処理の例外をスローしました。

この場合だけでなく、Visual Studioの別のインスタンスを実行し、独立したプロジェクトを開いて作成し、メニュー->デバッグ->プロセスにアタッチ...->問題のあるデザイナーでdevenv.exeプロセスのインスタンスを選択します。次に、Ctrl + Alt + Eを押すと、「例外」ウィンドウが表示されます。例外のカテゴリで「スロー」をチェックします。

デザイナーでビジュアルスタジオをアクティブにし、ビューデザイナーを試してください。例外がスローされる場合、コールスタック（および、例外がコードからスローされた場合はソースコード）およびスローされた例外に関するその他の一般的な情報が表示されます。この情報は非常に役立つ場合があります。

30
TcKs

これは古い質問であり、ここでも、より広いフォーラムプールでもまだ答えがないようです。ほとんどのアドバイスは、容赦ないclean> rebuildsまたはclose> clean folder> reopenまたはマシンの再起動に関するものです。現時点では確かな答えはありませんが、いくつかの研究を行っており、共有できると思いました。要約すると、コントロールまたはフォームの設計時にすべてのデザイナーファイルがコピーされる場所、古いファイルが存在できる別の場所、およびデザイナーがエラーページを生成する前にすべてのデザイナー例外をキャッチする方法が記述されています。

アセンブリを読み込むことができないか、見つからないという2つのケースがあるようです。 1つは設計者が必要とする場所へのコピーに失敗したファイルが原因で、2つ目は古いファイルが残されていることです。

前述のように、プロジェクトが、参照される参照とその参照に必要なすべての参照を再帰的にフレームワークに直接参照できない場合、ファイルのコピーに失敗する可能性があります。これは、すべての参照とその依存物を注意深く追跡し、すべてが確実に説明されるようにすることで軽減できます。

Visual Studioデザイナーは、プロジェクトのソース/ binフォルダーから分離された、デザイナーで使用するために特定の場所を使用してdllをキャッシュします。

Windows XP：

C：\ Documents and Settings\[ユーザー名]\Local Settings\Application Data\Microsoft\VisualStudio\10.0\ProjectAssemblies

Windows 7：

C：\ Users\[ユーザー名]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

この場所では、コンパイルされたアセンブリは動的に作成されたフォルダー（アセンブリごとに1つのフォルダー）にコピーされます。この場所でアセンブリバージョンの日付を確認すると、Visual Studioが終了すると削除されるため、かなり最新のようです。デザイナーが新しくコンパイルされたファイルで表示されると、すべてのアセンブリがコピーされます。各アセンブリの新しいコピーがデザイナーごとにこの場所に作成されるため、場所には各アセンブリの同一のコピーが複数保持される場合があります。

ただし、アセンブリをコピーできる別の場所が1つあり、アセンブリ検索シーケンスの一部であり、明らかにProjectAssembliesフォルダーの前にあり、次の場所にあります。

C：\ Program Files\Microsoft Visual Studio 10.0\Common7\IDE

アセンブリがこの場所にコピーされる方法やタイミングについては知りませんが、そうではないことが多いので、ここに到着するファイルがすぐに古い参照のソースになります。デザイナーが「ファイルまたはアセンブリのロードに失敗しました」エラーで失敗した場合、デザイナーが求めるバージョンは、この時点でアセンブリによってのみ参照されるバージョンでしたロケーション。

これは、すべての.netシンボルがロードされ、未処理の場合とは対照的に、すべての既知の例外がスローで中断する、2番目のVisual Studioインスタンスのデバッグを使用して発見されました。これにより、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.
24
J Collins

ソリューションに含まれるすべてのプロジェクトのすべてのbinおよびobjディレクトリを削除することができました。前述のように、C：\ Users \\ AppData\Local\Microsoft\VisualStudio\9.0\ProjectAssembliesのフォルダーも削除します。 VS2008には9.0、VS2010には10.0などを使用します。

12
Raymond Holmboe

VS 2005を使用して、この同じ問題に遭遇しました。 Chienが元の質問にリストした手順を実行しましたが、VSを閉じてソリューションを再度開くまで、まだ動作しませんでした。これで、デザイナビューが正常に表示されます。

5
Dean Hill

この問題に数時間苦労していました。私が学んだことは次のとおりです。DLLデザイナーISロードしようとするIS 64ビットDLLの場合。

VSは32ビットアプリケーションであるため、VS Designerであることに驚きました。驚き！また、32ビットアプリケーションであるため、64ビットDLLへの参照を持つUserControlまたはその他のWinFormsコントロールがある場合-THAT IS A BIG NO -NOを指定すると、フォームはVS Designerでレンダリングされず、could-not-load-file-or-Assemblyエラーが生成されます。したがって、最初にすべきことは、Designerが不平を言っているDLLが[〜＃〜] not [〜＃〜] 64ビットDLLであることを確認することです。

3
Denis

この問題はさまざまな理由で発生すると思いますが、とにかく私のケースを共有すると思いました。誰かが彼らのプロジェクトで何が起こっているかについての手がかりを見つけることを願っています。

Visual Studio（C＃プロジェクト）がマネージc ++ dllを見つけることができず、J Collins postに記載されている場所にコピーできなかったため、私の問題が発生しました。他のDLL：sでコピーされていないことに気づき、異なる/非標準の出力ディレクトリがあることがわかりました。これを標準に変更すると、Visual Studioがコピーを実行します。

3
SolSken

同様の問題がありました。

私の場合、混合モードdll（アンマネージライブラリへのc ++マネージラッパー）のクラスを参照するベースフォームがありました。派生フォームが正しくロードされず、上記と同じエラーが発生しました。

ただし、次の問題は解決されました。 http://support.Microsoft.com/kb/96705

  1. Win32用の混合モードプロジェクトとUIプロジェクトの両方をビルドします。 VSは32ビットなので、x64アンマネージコードを読み込むことはできません。
  2. ProjectAssembliesフォルダーをクリアします（VSを最初にシャットダウンする必要があります）

VSを再度開くと、デザイナーは問題なくロードされます。デフォルトでは、C＃プロジェクトはWindows x64でx64にコンパイルされるCPUとしてコンパイルされることに注意してください。

これが誰かを助けることを願っています。

2
Mahen

VS2005で、特にwinformにカスタムコントロールを追加したときに、非常に頻繁に起こりました。通常、追加の参照を追加したり、VSを閉じて再度開いたりする必要なく、再構築するだけで済みます。

これには明らかな原因はなく、VSのバグだけです。

2
Santiago Palladino

この問題は、c ++/cliプロジェクトで発生しました。

他の人が言ったように、Windowsフォームデザイナは、レンダリングする前にフォーム/ユーザーコントロールのあるバージョンをインスタンス化しているようです。

フォームデザイナが何らかの理由でクラスをインスタンス化できない場合、失敗します。したがって、私がやったことは、問題のあるUsercontrolのコンストラクターをコメントアウトし、プロジェクトを再構築することでした。

これにより、フォームデザイナを再び使用できるようになりました。

もちろん、このメソッドを使用して、コンストラクターの一部を選択的にコメントアウトして、フォームデザイナーをチョークする部分を特定し、可能であれば修正することができます。

1
IJC

また、フォームまたはコントロールにコントロールがあるライブラリのsing宣言があることを確認してください。デザイナーは、それについて知ると、Form.designer.csファイル内のオブジェクトへの参照に完全な名前空間を書き込みます。

0
S. Rojak

私は同じ問題に直面しました。プロジェクトから参照を削除して再度追加しましたが、すべて正常に動作します（ptojectファイルを見ると、参照定義が変更されていることがわかりました。たとえば、「SpecificVersion」タグが追加され、「false」に設定されました）。

0
ili

Fromを取得するため。まず、Visual Studio 2008コマンドプロンプトに移動します。

タイプdevenv /resetsettings
タイプdevenv /resetSkippkgs

  1. ソリューションエクスプローラーで[すべてのファイルを表示]をクリックします
  2. 次に、ダブルクリックしてForm1.vbを開き、[+]をクリックして展開します。
  3. Form1.Designer.vbを開きます
  4. エディターウィンドウ（IDE）に両方のタブが表示されます。
  5. タブ「Form1.vb」を右クリックして保存します
  6. 同様に、タブForm1.vb [デザイン]を右クリックして保存します
  7. プロジェクトを再構築します。
  8. Visual Studioを再起動します。
0
user8515392

このような問題や他の多くの問題を抱えて、問題は.NET Frameworkのインストールを中心に展開していることがわかりました。システムのクラッシュ時など、多くの場合、ファイルは特に破損する可能性があります。仮想メモリがオフになっている場合。 C：\ WINDOWS\Microsoft.NETフォルダー内のファイルが破損した場合、これらのファイルが多数あるため、エラーが常に発生するわけではないため、正常に機能しません。ファイルの一部は問題なくロードでき、他の部分はロードできません。長年にわたって、Microsoft.NETフォルダーの完全バックアップを、何らかの種類の破損防止機能を備えたアーカイブに保存しておくことは、私にとってはうまくいくことを発見しました。破損した.NETファイルが原因で問題が発生する数は信じられません。 IDEのほぼすべての側面は、その一部と他の多くの機能に依存します。もちろん、バックアップがない場合は、すべてのNET FRAMEWORK INSTALLATIONSをアンインストールする必要があります（修復しないでください。これは、ファイルが書き換えられることを保証しません-ファイルはチェックサムと長さのチェックに合格するかもしれませんが、それでも壊れています。）アンインストール後、システムを再起動し、Microsoft.NETフォルダー全体が削除されていることを確認してください。これを行うには、いくつかのファイルが残っています。これが完了したら、NETフレームワークを再インストールします。OSによっては、すべてを削除できない場合があります。ただし、windows XPできることはわかっていますが、テストを行う限り、新しいOSでこれを自分でテストしたことはありません。最初に2.0、3.5 SP1などをインストールすることから始めました。私は2008年に固執しているのは、それが私にとって最速であり、WPF、tr1などの新しいもののいくつかをまだサポートしているからです... sは.NETの問題を抱えている他のユーザーを支援します。エラーメッセージはしばしば誤解を招くものですが、私にとっては99％がMicrosoft.NETファイルの破損です。

0
osirisgothra

私はこの問題に何度か直面しています。その時間の大半 clean+rebuildは動作します（Visual Studioの再起動と組み合わせることもあります）。

clean+rebuildは機能しませんでした：

問題＃1

私が直面したケースの1つでは、C＃とVB.NETに関係していました。

フォームに複数のユーザーコントロールがあり、デザイナーに読み込まれていません。ユーザーコントロールはC＃でした。それらのほとんどは同じ名前空間の下にありましたが、それらのいくつかはアルファベットケースで一致しなかった名前空間の一部を持っていました。

例：

userContorl1 was in myapp.mynamespace1, and 
userControl2 was in myapp.myNamespace1

C＃では大文字と小文字が区別されるため、C＃では名前空間が異なります。ただし、VB.NETは大文字と小文字を区別しません。 myapp.mynamespace.userControl2をロードしようとしたときに発生したエラー。長い間苦労した後、エラーメッセージのネームスペースに気付き、ユーザーコントロールで修正し、それらをすべて「myapp.myNamespace1」と同じにし、clean+rebuild。

問題＃2

私のフォーム（開いていませんでした）には、多くのユーザーコントロールがありました。コントロールの1つに列挙型のプロパティがありました。この列挙型は、ジェネリッククラス内で定義されました。このユーザーコントロールのデザイナーが生成したコードは次のようなものでした。

myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum

デザイナーを開いているときに得たエラーは次のようなものでした：

タイプsomenamespace.SomeGenericClass [System.Date] + SomeEnumをロードできませんでした

クラスの外に列挙型を移動し、デザイナーコードを次のように置き換えました。

myUserControl1.SomeType = somenamespace.SomeEnum

そして、デザイナーが開きました。 :)

これが誰かの助けになることを願っています。

0
Brij

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 Form Designerが再び機能し始めました！

適切な記述方法Visual Studio Form Designer-相互作用する、C＃の継承されたコンポーネントクラスは私を超えています。しかし、この観察は、それを解決できる誰かの手がかりになるかもしれません。

0
c-iii-O

私はこの問題に直面しました。上記のことをしましたが、意味がありませんでした。次に、アセンブリを参照に追加しました。プロジェクトをリビルドします。 Visual Studioを閉じました。その後、画面を再度開くと、デザイナーが通常どおり表示されます。

よろしく、

0
Fatih UÇAR

これをチャイムに。他のプロジェクトを開いて参照している間に、UserControlの新しいバージョンを作成します。ユーザーコントロールを参照するフォームでデザイナを表示するために戻ったとき、特定のバージョンの.dllが見つからないと言っていました。

コントロールへの参照とツールボックスからの参照を削除しようとしましたが、うまくいきませんでした。コードは問題なくコンパイルされますが、デザイナーはエラーなしでは表示されません。

上記のすべてを試してみましたが、うまくいきませんでした。

フォームの.resファイルにはいくつかのXMLがあります。

<data name="EventBar1.EventCheckedSubscriptions" mimetype="application/x-Microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
  </data>
  <data name="EventBar1.EventLengthSubscriptions" mimetype="application/x-Microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
  </data>
  <data name="EventBar1.EventLengthTypes" mimetype="application/x-Microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAKABY3RybENhbGVuZGFyU2lkZUJhciwgVmVyc2lvbj0xLjAuNzEy
        MS4yMTIzNCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1udWxsXV0sIG1zY29ybGliLCBW
        ZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0
        ZTA4OQwDAAAAUWN0cmxDYWxlbmRhclNpZGVCYXIsIFZlcnNpb249MS4wLjcxMjEuMjEyMzQsIEN1bHR1
        cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAT1N5c3RlbS5Db2xsZWN0aW9ucy5HZW5l
        cmljLkxpc3RgMVtbY3RybENhbGVuZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAA
        Bl9pdGVtcwVfc2l6ZQhfdmVyc2lvbgQAAC5jdHJsQ2FsZW5kYXJTaWRlQmFyLkV2ZW50QmFyK0V2ZW50
        TGVuZ3RoVHlwZVtdAwAAAAgIAgAAAAkEAAAAAAAAAAAAAAAHBAAAAAABAAAAAAAAAAQsY3RybENhbGVu
        ZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAACw==
</value>
  </data>
  <data name="EventBar1.EventSettingsSubscriptions" mimetype="application/x-Microsoft.net.object.binary.base64">
    <value>
        AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
        ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
        PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
        AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
        AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
        AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
  </data>

これを.resファイルから削除しましたが、すべて問題ありません。これを試す前にフォルダ全体をバックアップしました！

0
Ross Crooks

これは、VS2005でWindow Forms、ASP.NET、およびCompact Frameworkプロジェクトで発生するのを見てきました。私が構築しているプロジェクトは、ソリューション内の別のアセンブリに依存していますが、デザイナーファイルを生成しようとすると、ロードできないと不平を言っています。

正確な原因は定かではありませんが、アセンブリのバージョン番号を上げた後にこれが発生することがあります。何らかの理由で、Visual Studioはこのアセンブリを「新規」として認識せず、現在のプロジェクトのbin /フォルダーに新しいバージョンをドロップしません。ほとんどの場合、それはします。

設計者のエラーでプロジェクトのbin /フォルダー（および適切な測定のためのobj /フォルダー）を削除してから、再構築すると、傷がなくなるようです。

0
Carl Russmann

このスレッドの応答は多少助けになったと思いますが、カスタムユーザーコントロールで発生していることを正確に特定できませんでした。

私の特定のケースでは、コントロールのスタイリング、バックグラウンドロギングなどのことを実行する多数のヘルパークラスライブラリと、いつもの日常的なことを実行する単なる汎用ヘルパークラスがあります。

私はこれらの他のライブラリのいくつかを使用していましたstaticエラーの場合にロギングを実行するためのメソッド。以下に例を示します。

try { _InitializeStuff(); } catch (Exception ex) { Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage); }

これは、ユーザーコントロールのコンストラクター、ロード、およびプロパティセットメソッドで行いました...デザイナーは静的メソッド呼び出しへのパスを常に構築できなかったため、デザイナーは失敗しました。

DesignModeチェックを配置しようとしましたが、問題は実行時ではなく、設計時であり、リンクを構築できませんでした。私にとって唯一のオプションは、カスタムユーザーコントロールの次の場所にある静的ヘルパークラスへのすべての参照を削除することでした。

  • コンストラクタ
  • 負荷
  • プロパティアクセサー

セカンダリIDEでこれをデバッグしようとして、プロセスにアタッチすることでnotが機能しましたが、残念ながら。

0
John Kroetch

将来この問題が発生し、それを探してスクロールダウンした人には：Appdata/Local/Microsoft/VisualStudio /のComponentModelCacheを削除してください。

0
Hele

ファイルの削除、再構築、再起動などに関連する上記の提案の多くを試しました。私の問題は、ソリューション内のいくつかのプロジェクトで使用されたユーティリティアセンブリを読み込めないことでした。別のプロジェクトには共通のコントロールがありました。したがって、Form1はControlsAssembly1を参照し、UtilityAssembly1を参照しました。 .resxファイルには、UtilityAssembly1のタイプのプロパティがありました。これらのタイプを含むリソースを削除しました。フォームを再度開いて（リソースが見つからないためNull Reference例外が発生しました）、[無視して続行]をクリックすると、問題が修正されました。

0
Mike L