SharePoint、VirtualPathProviders 和应用程序重新启动
鉴于卸载动态编译的程序集（以回收内存）的唯一方法是卸载应用程序域，那么 SharePoint 如何依赖 VirtualPathProviders（尤其是母版页和页面布局）而不会遇到此限制？
可以通过各种设置延迟重启，但当母版页和页面布局频繁更新和发布时并不能完全避免，对吗？
（缺乏这方面的信息是否归因于它是一个在发布模式中不常见的更理论的限制？您个人是否注意到母版页或布局的更改率导致应用程序不稳定？SharePoint 是否应该发出警告？）
任何 CMS -利用动态 WebForms（默认情况下包括 MVC 视图）的能力很容易受到变化率不稳定的影响，对吗？
关于非编译页面的更新：
非编译页面 在ASP.NET 2.0中，编译模型得到了显着的重构和扩展。站点预编译可能是最流行且呼声最高的新功能。另一个非常有趣的功能是无编译页面。它们是特殊的页面，永远不会被编译。那么免编译页面的最终目的是什么，它和静态HTML页面有什么区别呢？ 首先，通过将 @Page 指令上的 CompilationMode 属性设置为 Never 来创建一个非编译页面。当请求非编译页面时，不会创建页面程序集并将其保留到磁盘。相反，页面构建器组件的实例缓存在内存中，并用于为每个请求创建页面输出。页面构建器是一个特殊的组件，它支持页面解析器构建页面控制树。当编译打开时，控制树用于获取要编译的类。当编译关闭时，控制树用于获取标记。不用说，如果您想赋予程序员将自己的代码附加到页面的能力，那么类是必要的。非编译页面由服务器控件和文字组成，但根本不包含任何代码。
非编译页面并不适合所有应用程序。它们专门为提高具有数千个页面的大型网站的可扩展性而设计。非编译页面不能绑定到代码文件，也不能包含服务器端块。非编译页面中允许的唯一可执行代码是 $ 表达式。无编译页面有两个主要好处。在像 SharePoint 这样的安全环境中，非编译页面可以防止开发人员编写可能存在错误的代码，这些代码可能会给托管环境带来问题，甚至将其破坏。在大型基于内容的网站中，免编译页面避免了编译数千个页面的需要。
参考文献：
1 – http://haacked.com/archive/2009/04/ 22/scripted-db-views.aspx
Given that the only way to unload dynamically compiled assemblies (to reclaim memory) is to unload the app domain, how does SharePoint rely on VirtualPathProviders, for master pages and page layouts in particular, without bumping into this limitation?
The restart can be delayed through various settings but not avoided completely when master pages and page layouts are updated and published frequently, correct?
(Is the lack of info on this attributed to it being a more theoretical limit that's not common in publishing patterns? Have you personally noticed the rate of changes to master pages or layouts causing app instability? Should SharePoint come with a warning?)
Any CMS-esque capability that leverages dynamic WebForms (including, by default, MVC views) is susceptible to rate-of-change instability, correct?
Update on No-Compile Pages:
No-compile pages
In ASP.NET 2.0, the compilation model has been significantly refactored and extended. Site precompilation is perhaps the most popular and loudly requested of the new features. Another quite interesting feature is no-compile pages. They are special pages that just never get compiled. So what’s the ultimate purpose of no-compile pages, and what’s the difference between them and static HTML pages?
To start off, you create a no-compile page by setting the CompilationMode attribute on the @Page directive to Never. When a no-compile page is requested, no page assembly is created and persisted to disk. Instead, an instance of the page builder component is cached in memory and used to create the page output for each and every request. The page builder is a special component that supports the page parser in building the page control tree. When compilation is turned on, the control tree is used to obtain a class to compile. When compilation is off, the control tree is used to obtain markup. Needless to say, classes are necessary if you want to give programmers the power of attaching their own code to the page. No-compile pages are made of server controls and literals but contain no code at all.
No-compile pages are not for every application. They are exclusively designed for improving the scalability on very large web sites with thousands of pages. No-compile pages can’t be bound to a code file and can’t contain a server-side block. The only executable piece of code allowed in a no-compile page are $-expressions. There are two main benefits out of no-compile pages. In a secure environment like SharePoint, no-compile pages prevent developers from writing potentially buggy code that can cause problems to the hosting environment and even tear it down. In a large content-based web site, no-compile pages avoid the need to compile thousands of pages.
References:
1 –
http://haacked.com/archive/2009/04/22/scripted-db-views.aspx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先要注意的是，自定义页面（可能是母版页或页面布局）始终存储在数据库中。
页面请求周期与普通 ASP.net 版本的不同之处在于 SPVirtualPathProvider 路由请求的方式。一旦找到，就会发出对自定义页面的请求（与文件系统上的未自定义页面相反，并受通常的 ASP.net 页面编译模式的约束），页面的代码将从数据库中提取，并传递给 ASP .net 运行时，并以“无编译模式”进行解析。
以下是发出自定义页面请求时的流程的可视化呈现：
赞美 Shivprasad Koirala
这里也很好地描述了 ASP.net 的无编译模式< /a>
因此，这基本上解决了您提到的关于由于实时发生的多个自定义而卸载/加载应用程序域时过多的应用程序重置的问题（任何构建在 ASP.net 运行时上的 CMS 都必须解决的问题）。
除此之外；当以这种方式存储自定义内容时，您可以“免费”获得 SQL Server 的多用户功能和可扩展性；与文件系统方法相反，文件系统方法需要额外的努力来管理锁定。
First thing to note is that customized pages (Could be masterpages or page layouts) are always stored in the database.
The page request cycle differs from the vanilla ASP.net version in the way SPVirtualPathProvider routes requests. Once it's found the request is made for a customized page (as opposed to an uncustomized page sitting on the file system, and subject to the usual ASP.net page compilation mode) the page's code is pulled from the database, handed off to the ASP.net runtime, and parsed in "no-compile mode."
Here's a visual rendition of the process when a request for a customized page is made:
Compliments Shivprasad Koirala
Here is also good description of ASP.net's no compile mode
So this basically addresses the issue you mentioned with regards to excessive application resets when unloading/loading an app domain due to multiple customizations happening in real-time (an issue any CMS built on the ASP.net runtime would have to address).
On top of this; you get the multiuser capabilities and scalability of SQL Server "for free" when storing customized content in this way; as opposed to a file system approach which would necessitate extra effort to manage locking.
找到了对此的一个很好的解释1:
他们的关键要点很简单，可以卸载未编译的页面（可以卸载关联的页面构建器），而这对于已编译的页面来说是不可能的。但从本质上讲，这是一种可扩展性措施（在此模型下可以处理更多页面），而不是性能增强（在初始设置后，已编译页面的性能应该比未编译页面的性能更好）。
1 -
http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/
Found a nice explanation of this 1:
They key takeway is simply that no-compile pages can be unloaded (the associated page builder can be unloaded), which isn't possible with compiled pages. At its core though, this is a scalability measure (more pages can be handled under this model) and not a performance enhancement (after initial setup, compiled pages should perform better than their non-compiled counterparts).
1 -
http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/