確認された問題の原因
最初に指摘したいのは、参照されている dll の名前空間を追跡できなくなる問題は、その dll にカスタム UI エディター/デザイナーが存在することが原因であったということです。
修正
カスタム エディター/デザイナーを「プライマリ」クラス ライブラリから分離する一般的なプロセスは次のとおりです。
1.)プロジェクト内のすべてのカスタム エディター/デザイナーを検索します。プロジェクトにある程度の知識しかない場合は、ソリューション全体で「UITypeEditor」を検索(Ctrl + F)することをお勧めします。あなたがそれを設計した人なら、問題はないはずです。
2.)カスタム エディター/デザイナー クラス全体を削除またはコメント アウトします。ドキュメントを簡単にするためにコメントアウトすることを好みます (戻る必要がある場合に備えて)。
3.)ソリューションで新しいプロジェクトを作成します。ソリューションが表示されない場合 (つまり、プロジェクトしか表示されない場合)、[ツール] --> [オプション] --> [プロジェクトとソリューション] に移動します。「常にソリューションを表示する」というチェックボックスが表示されます。解決策を明らかにした後、右クリックして追加を選択します - >新しいプロジェクト... 名前は何でもかまいませんが、コードにはほとんどまたはまったく影響しません。
4.)新しいプロジェクト内で、Class1 を便利な名前に変更します。カスタム エディター/デザイナー クラスを最初に保持していたファイルの先頭にあるすべての「using」ステートメントを転送します。 編集: プライマリ プロジェクトから必要な型にアクセスできる名前空間に using ステートメントを追加します。各クラスに適切な名前空間を宣言します。カスタム クラスをコピーして正しい名前空間に貼り付けます (必要に応じて、すべてのカスタム エディター/デザイナーをこの 1 つのファイルに配置できます)。'internal' として宣言されているすべてのクラスを 'public' に変更します (internal はアセンブリのスコープのみです)。
5.)新しいプロジェクトに参照が必要な場合は、ここで追加します。カスタム エディターでカスタム タイプを編集している場合は、それらのタイプを定義するプロジェクトへの参照が必要になる可能性があります。これらのタイプが「プライマリ」アセンブリで定義されている場合、循環参照の問題が発生する可能性があるため、少し扱いにくい場合があります。これを回避する 1 つの方法 (おそらく正しい方法) は、これらの型の宣言をプライマリ アセンブリから削除し、その宣言のためだけに新しいプロジェクト/アセンブリを作成することです。何らかの理由でプライマリ アセンブリから分離できない場合は、以前にプライマリ アセンブリで作成された成功したビルド (dll) を脇に置き、それを参照します。これにより、これらのタイプのコードの将来の持続可能性が低下する可能性がありますが、それが必要な場合は今すぐ作業を完了できます。
6.)カスタム エディター/デザイナー プロジェクトをデバッグした後、それをビルドし、そのプロジェクトのビルド (dll) を参照としてプライマリ プロジェクト/アセンブリに追加します。
7.)内部でデバッグし、ソリューションで新しいプロジェクトを作成し、両方の dll (プライマリおよびカスタム エディター) を参照に追加します。設計時と実行時の両方で、コントロール/プロパティが想定どおりに動作することを確認します。
8.) 最後に、外部でデバッグします。新しいソリューションを作成し、両方の dll を参照して、機能を確認します。ネイティブ ソリューションと外部の両方でデバッグするのはやり過ぎに思えるかもしれませんが、環境間で動作に多くの違いがあることがわかりました。徹底してください。
重要な注意:両方のdllを追加する必要があることを理解するのに長い時間 を費やしました。プライマリ dll だけをテスト プロジェクトに追加すると、両方が追加されたかのように動作します。プライマリアセンブリが他のアセンブリを参照しているため、これは合理的でした（そして非常にダンディでした）。ただし、Visual Studio を閉じて開くと機能しません。簡単に言えば、両方のdllを追加します。
TreeViewAdv 仕様
1.) 2 つのカスタム UIEditor がありました。1 つ目は、標準の .NET CollectionEditor を継承する NodeControlCollectionEditor と呼ばれる NodeControlsCollection.cs にあります。追加された唯一の機能は、エディターが使用できるコントロールの種類を明示的に割り当てることでした。これは主に、すべての NodeControl タイプをコレクションに追加できるようにするための回避策として行われたようです (これにはタイプ NodeControl を渡す必要がありました) が、抽象タイプをインスタンス化できないため、NodeControl タイプを渡すとエラーが発生するという事実を回避します。 . 2 つ目は、StringCollectionEditor.cs の StringCollectionEditor です。これも標準の .NET CollectionEditor を継承し、少し機能を追加します (目的は不明)。
2 - 4.)一般的なプロセスと同じです。
5.) 現在、後者の方法を使用する必要がありました (カスタム UIEditor が参照できるように、Aga.Controls の dll を取っておきます)。後で、オブジェクト宣言の一部をプライマリ アセンブリから分離して、ソリューションの信頼性を高めたいと考えています。
6 - 8.) 元のバグ (aga 名前空間の喪失) は、テスト アプリケーションを同じソリューション内で実行した場合 (プロジェクトが異なっていても) 発生しませんでした。さらに、外部で機能する一部の修正が内部で正しく実行されず、その逆も同様でした。したがって、両方の環境でテストするための私のアドバイスです。
最後のリクエスト
私の質問の一般的な内容と詳細の両方がここで回答されていますが、Plutonix の助けは私が解決策にたどり着くのに不可欠でした。これを答えとしてマークしている間。私が答えを見つけるのを助けるために彼が費やした努力を考慮して、人々がPlutonixの答えにも賛成票を投じてくれることを望みます（具体的でない場合でも彼の答えも正しいという事実に加えて）。
編集:上記のプロセスは、元の TVA C# コードを変更したときに機能しました。結果の DLL を参照して、VB.net プロジェクトで正常に使用することさえできました。VB.net に変換した TVA コード行に同じプロセスを適用しようとすると、最初と同じ問題が発生しました。アプリケーションを実行するまではすべてが機能し、その後 aga 名前空間が見えなくなります。
解決策の編集: (参照を失うプロジェクトの) プロパティに移動します-> [コンパイル] タブ --> [高度なコンパイル オプション] ボタン。ターゲット フレームワークで、まだ「.NET Framework 4」に変更していない場合は変更します。その値がすでに選択されている場合は、別の原因を調べている可能性があります。