问题标签 [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并使用此处找到的代码，我正在尝试将嵌入资源的视图加载到单独的DLL项目中，而原始问题的作者说他已经成功地做到了这一点 - 但我无法让它发挥作用似乎 MVC 视图引擎正在拦截请求并仍在查看文件系统的视图。例外：

我正在使用CustomViewEngine类似 Rob Connery 的 /App 结构之一，如下所示：

这是我的路线：

在我的AssemblyResourceProvider我正在检查路径是否开始~/plugin/，然后使用 dll 文件名约定plugin.{controller}.dll

有什么建议么？

更新：当路由请求http://localhost/plugin/admin到达 VirtualFileProvider 时，它最后没有附加任何视图。因此，在VirtualFileProvider's Open 方法~/plugin/admin中，当它应该~/plugin/admin/Index.aspx在我上面的路线中定义时，它被传入。我是否搞砸了我的路线，或者我期望这种情况发生是正确的？

我可以从一个文件创建一个页面：

如何从流或字符串中实例化页面？

谢谢你。

我在这里遇到了一个真正令人头疼的问题……它似乎是 ASP.NET 中更令人沮丧的话题之一。

我有一个程序集，它实现了很多自定义的 Linq 东西，它的核心是零网络功能。我有一个额外的程序集，它使用特定于 Web 的行为扩展了这个程序集。

Web 特定行为带有在 ASCX 模板化的用户控件中标记的几个用户控件。

我无法很好地完成此程序集，以便重新部署以用于其他应用程序。让我来看看我到目前为止所尝试的：

1. 使用构建事件将 ASCX 文件复制到使用 Web 应用程序；远非理想，而且是一场部署噩梦。
   • 实现了一个自定义 VirtualPathProvider 并将 ASCX 模板作为嵌入式资源嵌入到程序集中。不幸的是，当在消费应用程序中使用 Register 指令时，它会将设计器声明创建为 UserControl，我需要在其中声明实际控件类型；不可预见的（通常）和不受欢迎的。
   • 创建了一个 Web 部署项目来编译 UserControls，但是编译的用户控件然后成为另一个程序集的一部分，并且不再来自我的 Web 程序集中的类定义——程序集需要根据请求上下文实例化它们。

所以第 1 号只是废话，第 2 号并没有给我我想要的类型支持，第 3 号我想我将提出一个合理的解决方案：

• 将所有非控制类集中到App_Code文件夹中，准备一个工厂类，该类将使用反射构造所需控制类型的对象，并期望被反射的类型将出现在部署输出中（希望通过ClassName属性的存在来保证在Control指令中）。

还有将 ASCX 控件重写为自定义控件的另一种选择，但目前没有资源来考虑它，而且我们没有这样做的专业知识，它们作为 UserControls 可以正常工作。

我是否遗漏了一些明显的东西，可能更简单的东西，或者这只是故意困难？我读过关于 ASP.NET 编译过程的故事，在我穿越这个主题的过程中，它的设计非常不幸。

问题

是否可以使用没有预编译的 Web 部署项目发布 Web 应用程序项目？

笔记

为了将 Web 控件和页面拆分为单独的程序集，我使用自定义 VirtualPathProvider 来加载这些资源。我在 cmd 行使用 web 部署项目和 msbuild 来部署这些项目。

问题的症结在于预编译的应用程序不支持 VirtualPathProviders。我在这里找到了常规文件的解决方法。但是，这不适用于ascx和aspx页面等应用程序文件。它会抛出“文件尚未预编译，无法请求”的异常。

因此，我决定尝试完全放弃预编译，因为我们的网站流量并不是特别高，所以最初的请求性能受到了影响。但是，我不知道如何使用 Web 部署项目来做到这一点，这些项目已经非常融入我们的构建过程。

我正在考虑自定义 Microsoft.WebDeployment.targets 文件以完成此操作，但到目前为止我还没有运气。

在挖掘 Microsoft.WebDeployment.targets 文件时，我发现没有直接的方法可以将 Web 部署项目与 Web 应用程序预编译分离。事实上，我不确定有没有必要。我现在使用的是类似于以下代码段的东西。我只是将其放入项目文件中，并带有一个条件 attr 以不部署用于调试构建。

似乎这就是在没有预编译的情况下部署项目所需要的一切。如果你发现更好的东西，请告诉我。

我有一个提供简单 aspx 页面的虚拟路径提供程序 (VPP)。问题出在我引入静态引用（例如 *.css、*.jpg 文件等）时......

我注意到我的 VPP 正在捕获这些请求。我不希望这种情况发生。我希望普通的 System.Web.StaticFileHandler 来处理这些请求。

我在我的网络配置中添加了以下内容：

但我的 VPP 仍然处理这些请求。有任何想法吗？

提前欢呼

我有一个虚拟路径提供程序。问题是它缓存我的文件。每当我手动编辑它引用的其中一个 aspx 文件时，VPP 不会拉入新文件，它会继续重用旧文件，直到我重新启动站点。

我什至在我的 VirtualPathProvider 类中过度使用了 GetCacheDependency()：

想法？

鉴于卸载动态编译的程序集（以回收内存）的唯一方法是卸载应用程序域，SharePoint 如何依赖 VirtualPathProviders，尤其是母版页和页面布局，而不会遇到此限制？

当母版页和页面布局频繁更新和发布时，可以通过各种设置延迟重启，但不能完全避免，对吗？

（缺乏这方面的信息是否归因于它是一个在发布模式中不常见的理论限制？您个人是否注意到母版页或布局的更改率导致应用程序不稳定？SharePoint 是否应该发出警告？）

任何利用动态 WebForms（默认情况下包括 MVC 视图）的 CMS 式功能都容易受到变化率不稳定性的影响，对吗？

非编译页面的更新：

无编译页面 在 ASP.NET 2.0 中，编译模型进行了重大重构和扩展。站点预编译可能是新功能中最受欢迎和要求最高的。另一个非常有趣的特性是无编译页面。它们是永远不会编译的特殊页面。那么无编译页面的最终目的是什么，它们与静态 HTML 页面有什么区别呢？首先，通过将 @Page 指令上的 CompilationMode 属性设置为 Never 来创建一个非编译页面。当请求非编译页面时，不会创建页面程序集并将其保存到磁盘。相反，页面构建器组件的一个实例被缓存在内存中，并用于为每个请求创建页面输出。页面构建器是一个特殊的组件，它支持页面解析器构建页面控制树。打开编译时，控制树用于获取要编译的类。当编译关闭时，控制树用于获取标记。不用说，如果你想让程序员有能力将自己的代码附加到页面上，类是必要的。非编译页面由服务器控件和文字组成，但根本不包含任何代码。

非编译页面并不适用于每个应用程序。它们专为提高具有数千页页面的大型网站的可扩展性而设计。非编译页面不能绑定到代码文件，也不能包含服务器端块。非编译页面中唯一允许的可执行代码是 $ 表达式。免编译页面有两个主要好处。在像 SharePoint 这样的安全环境中，无编译页面可防止开发人员编写可能导致托管环境出现问题甚至将其拆除的潜在错误代码。在基于内容的大型网站中，免编译页面避免了编译数千个页面的需要。

参考：

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

我有以下一组用于在视图中动态加载的类。下面的代码在使用 .RenderPartial 调用时效果很好。

但是，如果我尝试将创建类型化视图的 、 更改<%="Test"%>为<%=new Model.Category()%>，我会收到一条错误消息，指出“找不到类型或命名空间名称‘模型’（您是否缺少 using 指令或程序集引用？）”。但是，如果将其简单地放在 .ascx 文件中，则相同的代码也可以工作。

我是否遗漏了什么，似乎流来自文件系统或自定义 VirtualPathProvider 它应该具有相同的加载程序集，因为<%=AppDomain.CurrentDomain.ApplicationIdentity%>从文件系统或自定义提供程序返回相同的值。

目前我VirtualPathProvider在 Asp.net MVC web 应用程序中有一个自定义。

这将VirtualPathProvider检查路线中的区域"/{Area}/{Controller}/..."并使用NameSpace.{Area}.Main.dll模块将包含在该程序集中的视图作为嵌入式资源返回。

这很好用，我不必部署任何ascx, js,css文件。

现在我的问题是这样的：

我想在程序集中预编译aspx和ascx文件，而不是将视图作为嵌入式资源，我将拥有带有 Response.Write 的视图类。

我可以使用 预编译视图，但是当尝试查找视图并失败aspnet_compiler时，我会不断收到错误消息。ViewEngine

我的主要目标是第一次使用某个视图/用户控件会更快，并且不要等待编译发生。

这是一个要求，因为可以将应用程序分组到插件中，并且此插件可以部署到 Bin 目录中。

有什么想法吗？