私はここで本当の頭をかきむしります...そしてそれはASP.NETのより苛立たしいトピックの1つであるように見えます。
たくさんのカスタムLinqのものを実装するアセンブリがありますが、そのコアにはWeb機能がありません。このアセンブリをWeb固有の動作で拡張する追加のアセンブリがあります。
Web固有の動作には、ASCXテンプレート化されたUserControls内にマークアップされたいくつかのユーザーコントロールが付属しています。
他のアプリケーションで使用するために再デプロイするのが簡単になるように、このアセンブリをきれいに仕上げるのに問題があります。これまでに試したことを実行してみましょう。
- ビルドイベントを使用して、ASCXファイルを消費側のWebアプリケーションにコピーしました。理想からはほど遠い、展開の悪夢です。
- カスタムVirtualPathProviderを実装し、ASCXテンプレートを埋め込みリソースとしてアセンブリ内に埋め込みました。残念ながら、使用するアプリケーションでRegisterディレクティブを使用すると、デザイナー宣言がUserControlとして作成され、実際のコントロールタイプの宣言が必要になります。予期しない（通常）および望ましくない。
- UserControlsをコンパイルするためのWeb配置プロジェクトを作成しましたが、コンパイルされたユーザーコントロールは別のアセンブリの一部になり、Webアセンブリのクラス定義から派生しなくなりました。アセンブリはリクエストコンテキストに応じてそれらをインスタンス化する必要があります。
つまり、1番はただのがらくたであり、2番は私が望むタイプのサポートを提供せず、3番は次のような合理的な解決策を生み出そうとしていると思います。
- すべての非制御クラスを
App_Codeフォルダーにまとめ、リフレクションを使用して目的の制御タイプのオブジェクトを構築するファクトリクラスを準備し、反映されるタイプがデプロイメント出力に存在することを期待します（ClassName属性の存在によって保証されることを願っています）Controlディレクティブ内）。
ASCXコントロールをカスタムコントロールに書き換える他のオプションも常にありますが、現時点でそれを検討するためのリソースがなく、それを行うための専門知識がなく、UserControlとして正常に機能します。
明らかなもの、おそらくもっと単純なものが欠けているのでしょうか、それとも意図的に難しいのでしょうか？ASP.NETのコンパイルプロセスの話を読んだことがありますが、このトピックを旅する際の設計は非常に残念です。