問題タブ [virtualpathprovider]

私たちは、ASP.NET の VirtualPathProviders に大きく依存するアプリケーションに取り組んできました。

実演するためにライブサーバーに物を置くようになったところですが、サイトがプリコンパイルされている場合、VirtualPathProviders は単に機能しないようです!!

http://sunali.com/2008/01/09/virtualpathprovider-in-precompiled-web-sites/に投稿されている回避策を見てきましたが、これまでのところ取得できませんでしたそれもうまくいきます！(まあ、Visual Studio の Web 開発サーバーでは正常に動作しますが、IIS ボックスでは問題ありません)。

この問題に関する詳しい情報を持っている人はいますか? .NET v3.5 (現在 v2.0 用に構築中) で修正されていますか?

this question hereと using code found hereに基づいて、別の DLL プロジェクトに埋め込まれたリソースであるビューを読み込もうとしています。元の質問の作成者は、これを行うことに成功したと言っていますが、 MVC ビュー エンジンがリクエストをインターセプトし、ビューのファイル システムをまだ調べているようです。例外：

次のように、Rob Connery の /App 構造のようなを使用してCustomViewEngineいます。

ここに私のルートがあります：

私AssemblyResourceProviderの場合、パスが開始するかどうかを確認してから~/plugin/、dllファイル名の規則を使用していますplugin.{controller}.dll

助言がありますか？

更新:たとえばルーティングされたリクエストhttp://localhost/plugin/adminが VirtualFileProvider に到達するまでには、最後にビューがアタッチされていません。したがって、の Open メソッドでは、上記のルートで定義されている必要があるときにVirtualFileProvider、 の仮想パスが渡されます。ルートを台無しにしたのでしょうか、それともこれが起こると予想するのは正しいですか?~/plugin/admin~/plugin/admin/Index.aspx

次のファイルからページを作成できます。

ストリームまたは文字列からページをインスタンス化するにはどうすればよいですか?

ありがとうございました。

私はここで本当の頭をかきむしります...そしてそれはASP.NETのより苛立たしいトピックの1つであるように見えます。

たくさんのカスタムLinqのものを実装するアセンブリがありますが、そのコアにはWeb機能がありません。このアセンブリをWeb固有の動作で拡張する追加のアセンブリがあります。

Web固有の動作には、ASCXテンプレート化されたUserControls内にマークアップされたいくつかのユーザーコントロールが付属しています。

他のアプリケーションで使用するために再デプロイするのが簡単になるように、このアセンブリをきれいに仕上げるのに問題があります。これまでに試したことを実行してみましょう。

1. ビルドイベントを使用して、ASCXファイルを消費側のWebアプリケーションにコピーしました。理想からはほど遠い、展開の悪夢です。
   • カスタムVirtualPathProviderを実装し、ASCXテンプレートを埋め込みリソースとしてアセンブリ内に埋め込みました。残念ながら、使用するアプリケーションでRegisterディレクティブを使用すると、デザイナー宣言がUserControlとして作成され、実際のコントロールタイプの宣言が必要になります。予期しない（通常）および望ましくない。
   • UserControlsをコンパイルするためのWeb配置プロジェクトを作成しましたが、コンパイルされたユーザーコントロールは別のアセンブリの一部になり、Webアセンブリのクラス定義から派生しなくなりました。アセンブリはリクエストコンテキストに応じてそれらをインスタンス化する必要があります。

つまり、1番はただのがらくたであり、2番は私が望むタイプのサポートを提供せず、3番は次のような合理的な解決策を生み出そうとしていると思います。

• すべての非制御クラスをApp_Codeフォルダーにまとめ、リフレクションを使用して目的の制御タイプのオブジェクトを構築するファクトリクラスを準備し、反映されるタイプがデプロイメント出力に存在することを期待します（ClassName属性の存在によって保証されることを願っています）Controlディレクティブ内）。

ASCXコントロールをカスタムコントロールに書き換える他のオプションも常にありますが、現時点でそれを検討するためのリソースがなく、それを行うための専門知識がなく、UserControlとして正常に機能します。

明らかなもの、おそらくもっと単純なものが欠けているのでしょうか、それとも意図的に難しいのでしょうか？ASP.NETのコンパイルプロセスの話を読んだことがありますが、このトピックを旅する際の設計は非常に残念です。

質問

プリコンパイルせずに Web デプロイメント プロジェクトを使用して Web アプリケーション プロジェクトを公開することはできますか?

ノート

Web コントロールとページを別のアセンブリに分割するために、カスタム VirtualPathProvider を使用してこれらのリソースを読み込みます。これらのプロジェクトを展開するために、コマンド ラインで Web 展開プロジェクトと msbuild を使用しています。

問題の核心は、VirtualPathProviders がプリコンパイル済みアプリケーションに対してサポートされていないことです。ここで、通常のファイルの回避策を見つけました。ascxただし、これはやaspxページなどのアプリケーション ファイルでは機能しません。「ファイルはプリコンパイルされていないため、要求できません」という行に沿って例外をスローします。

その結果、プリコンパイルを完全に放棄して、サイトのトラフィックが特に高くないため、最初のリクエストのパフォーマンス ヒットを取得することにしました。しかし、ビルド プロセスにすでに組み込まれている Web 配置プロジェクトを使用してこれを行う方法がわかりません。

これを達成するために Microsoft.WebDeployment.targets ファイルをカスタマイズすることを検討していますが、これまでのところうまくいきませんでした。

Microsoft.WebDeployment.targets ファイルを調べてみると、Web 配置プロジェクトを Web アプリケーション プリコンパイルから切り離す簡単な方法がないことがわかりました。実際、必要があるかどうかはわかりません。私が代わりに使用しているのは、次のスニペットに似たものです。デバッグビルド用にデプロイしないという条件 attr を使用してプロジェクトファイルに入れました。

プリコンパイルせずにプロジェクトをデプロイするために必要なことはこれだけのようです。より良いものを見つけたら教えてください。

シンプルな aspx ページを提供する仮想パス プロバイダー (VPP) があります。問題は、*.css、*.jpg ファイルなどの静的参照を導入するときにあります...

VPP がこれらのリクエストをキャプチャしていることに気付きました。私はこれが起こることを望んでいません。通常の System.Web.StaticFileHandler でこれらの要求を処理する必要があります。

Web構成に次を追加しました。

しかし、私の VPP は引き続きこれらの要求を処理します。何か案は？

事前に乾杯

仮想パスプロバイダーがあります。問題は、ファイルのキャッシュです。VPPが参照するaspxファイルの1つを手動で編集しても、VPPは新しいファイルをプルしませんが、サイトを再起動するまで古いファイルを再利用し続けます。

VirtualPathProviderクラスのGetCacheDependency（）を上書きしました。

アイデア？

動的にコンパイルされたアセンブリをアンロードする（メモリを再利用する）唯一の方法がアプリドメインをアンロードすることであるとすると、SharePointは、この制限にぶつかることなく、特にマスターページとページレイアウトについて、VirtualPathProvidersにどのように依存しますか？

マスターページとページレイアウトが頻繁に更新および公開される場合、再起動はさまざまな設定によって遅延する可能性がありますが、完全に回避することはできません。

（これに関する情報の欠如は、公開パターンでは一般的ではない、より理論的な制限に起因しますか？アプリの不安定性を引き起こすマスターページまたはレイアウトへの変更の割合に個人的に気づきましたか？SharePointに警告を表示する必要がありますか？）

動的Webフォーム（デフォルトではMVCビューを含む）を活用するCMS風の機能は、変化率の不安定性の影響を受けやすいですよね？

コンパイルされていないページの更新：

コンパイルなしのページASP.NET2.0では、コンパイルモデルが大幅にリファクタリングされ、拡張されています。サイトの事前コンパイルは、おそらく最も人気があり、新機能の中で大声で要求されています。もう1つの非常に興味深い機能は、ページをコンパイルしないことです。それらは決してコンパイルされない特別なページです。では、コンパイルなしのページの最終的な目的は何ですか？また、静的HTMLページとの違いは何ですか？まず、@ PageディレクティブのCompilationMode属性をNeverに設定して、コンパイルなしのページを作成します。コンパイルなしのページが要求された場合、ページアセンブリは作成されず、ディスクに保持されません。代わりに、ページビルダーコンポーネントのインスタンスがメモリにキャッシュされ、すべてのリクエストのページ出力を作成するために使用されます。ページビルダーは、ページコントロールツリーを構築する際にページパーサーをサポートする特別なコンポーネントです。コンパイルがオンになっている場合、コンパイルするクラスを取得するためにコントロールツリーが使用されます。コンパイルがオフの場合、コントロールツリーを使用してマークアップを取得します。言うまでもなく、プログラマーに独自のコードをページに添付する力を与えたい場合は、クラスが必要です。ノーコンパイルページはサーバーコントロールとリテラルで構成されていますが、コードはまったく含まれていません。

コンパイルなしのページは、すべてのアプリケーションに対応しているわけではありません。これらは、数千ページの非常に大規模なWebサイトのスケーラビリティを向上させるためにのみ設計されています。コンパイルなしのページをコードファイルにバインドしたり、サーバー側のブロックを含めることはできません。コンパイルなしのページで許可される実行可能なコードは、$式のみです。コンパイルしないページには2つの主な利点があります。SharePointのような安全な環境では、コンパイルなしのページにより、開発者は、ホスティング環境に問題を引き起こしたり、さらには破壊したりする可能性のあるバグのあるコードを記述できなくなります。大規模なコンテンツベースのWebサイトでは、コンパイルしないページを使用すると、何千ものページをコンパイルする必要がなくなります。

参照：

1 – http://haacked.com/archive/2009/04/22/scripted-db-views.aspx

ビューに動的にロードするために使用した次のクラスのセットがあります。以下のコードは、.RenderPartial で呼び出すとうまく機能します。

<%="Test"%>しかし、型付きビューの作成をに変更しようとする<%=new Model.Category()%>と、「型または名前空間名 'Model' が見つかりませんでした (using ディレクティブまたはアセンブリ参照がありませんか?)」というエラーが表示されます。ただし、同じコードを .ascx ファイルに配置するだけで機能します。

<%=AppDomain.CurrentDomain.ApplicationIdentity%>ファイル システムまたはカスタム プロバイダーのいずれかから同じ値を返すため、ストリームがファイル システムまたはカスタム VirtualPathProvider から来ているように見えます。

VirtualPathProvider現在、Asp.net MVC Web アプリケーションにカスタムがあります。

これVirtualPathProviderにより、ルートから Area がチェックされ"/{Area}/{Controller}/..."、モジュールを使用してNameSpace.{Area}.Main.dll、そのアセンブリに含まれるビューが埋め込みリソースとして返されます。

ascxこれはうまく機能し、、、、ファイルjsを展開する必要はありません。css

今私の問題はこれです：

aspxアセンブリ内のおよびファイルをプリコンパイルしascx、ビューを埋め込みリソースとして使用する代わりに、Response.Write を使用してビュー クラスを作成したいと考えています。

を使用してビューをプリコンパイルできますが、ビューを見つけようとして失敗するたびにaspnet_compilerエラーが発生し続けます。ViewEngine

私の主な目標は、特定のビュー/ユーザーコントロールを初めて使用する方法がより高速になり、コンパイルが行われるのを待たないことです。

アプリケーションをプラグインにグループ化し、このプラグインを Bin ディレクトリにデプロイできるため、これは必須です。

何かご意見は？