問題タブ [razorgenerator]

RazorGenerator を使用して、カスタム (派生) RazorViewEngine とプリコンパイル済みビューを使用しようとしています。

いくつかのコンテキスト:

複数のクライアントの実装に使用する基本製品があります。これで、基本ビューのコア セットができました。ほとんどの場合、ほとんどのビューが機能します。現時点では、新しいソリューションごとに既存のビューをコピーし、必要に応じて変更することになります。これにより、ビューの 95% がクライアント間で同じになり、5% が変更されます。

私がやりたいことは、ビューの基本セットを取得し、それらを DLL にコンパイルして、クライアント間で再利用することです。これまでのところ、RazorGenerator を使用してうまく機能しています。

次のステップは、ビューのカスタマイズ (オーバーライド) を可能にすることです。ただし、注意点があります。このアプリケーションには、ユーザーがいる 2 つの「モード」があります。ユーザーがいるモードでは、別のビューが必要になる場合があります。

RazorGeneratorView から派生クラスを作成しました。このビューは基本的に、Autofac が解決する UserProfile オブジェクトから「OrderingMode」を検査します。モードに基づいて - パス ロケーターはビューの解像度に置き換えられます。

個々のクライアント アプリケーションであるという考え方は、最初に従来の Views フォルダーでビューを解決しようとします。Views/{OrderingMode}/{Controller}/{View}.cshtml のサブディレクトリに追加しているのは私だけです。

ビューが見つからない場合は、コンパイルされたライブラリ (コア ビュー) が検索されます。

これにより、クライアントの必要に応じて個々のビュー/パーシャルをオーバーライドできます。

以下は、RazorGenerator が ViewEngine を登録するために使用する StartUp クラスです。

問題は：

1. このコードは最後に (PosViewEngine を登録した後) 実行され、最初の位置にエンジンが挿入されます (これは、応答を提供するときに最初に解決されるエンジンであることを意味します)。これはビューを見つけることになります - それはコアビューです。

2. StartUp のコードを変更して、最初にカスタム ビュー エンジンを登録し、次に RazorGenerator エンジンを登録するとします。

   /li>

FileExists(ControllerContext controllerContext, string virtualPath) メソッドで例外が発生します-「相対仮想パス 'Views/Account/LogOn.cshtml' はここでは許可されていません。」

明らかに、物理パスと仮想パスの両方が混在していることに関係があります。

他の誰かがここで同じことをしようとしていたようですが、これに関する答えはありませんでした。

Razorengine 3.9 は、多くのテンプレートを実行するために使用されます。次のような名前のアセンブリを作成します

意味のある名前を持つアセンブリを強制的に作成する方法は? この場合、読み込まれたアセンブリ リストを使用して、どのアセンブリが読み込まれているかを判断できます。

この名前でアセンブリを作成するために、アセンブリ名の一部を RunCompile メソッドに渡す方法は?

を使用してキャッシュキーに割り当てようとしました

ただし、アセンブリ名には表示されません。アセンブリ名の作成にキャッシュ キーが使用されていないようです。

ASP.NET MVC4 、.NET 4.6 / Mono、C#、Razor 3 を使用。

I have an MVC-ish project that includes pre-compiled, reuseable views created by the RazorGenerator tool. This generates a reusable shell for other websites. I can successfully include that project in another project in the same solution.

I want to be able to reuse the shell project in other MVC projects in their own solutions. I believe packaging and distributing the shell via an internal NuGet server is the best way to go.

I created an initial NuGet package for the project following NuGet's instructions. This package has too much in it. I am working to trim it down.

Does anyone have a set of best practices for creating and reusing a generated shell like this?