的SharePoint，VirtualPathProviders和应用程序重新启动 [英] SharePoint, VirtualPathProviders and Application Restarts
问题描述
由于卸载动态编译组件（回收内存）的唯一方法是卸载应用程序域，如何做的SharePoint依靠VirtualPathProviders，为母版页，并在特定的页面布局，不会撞上这个限制？
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?
（归因于它是一个更理论极限，这不是常见的出版模式，缺乏对这些信息的？你有没有亲自注意到了这些变化的速度掌握导致应用程序不稳定？如果SharePoint中配备了一个警告页面或布局？ ）
(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?)
这是利用动态的WebForms（包括默认情况下，MVC意见）任何CMS式的能力易受率的变化不稳定，是否正确？
Any CMS-esque capability that leverages dynamic WebForms (including, by default, MVC views) is susceptible to rate-of-change instability, correct?
在非编译的页面的更新：
没有编译页面
在ASP.NET 2.0中，编译模式已显著重构和扩展。网站precompilation也许是最流行的，大声要求的新功能。另外一个很有趣的特点是无编译页。他们是从来没有被编译的特殊页面。那么，什么是无编译页的最终目的，什么是他们和静态HTML页面之间的区别？
要开始了，您用切勿在@Page指令设置CompilationMode属性创建一个无编译页。当请求没有编译页面，没有页面组件被创建并保存在磁盘上。相反，页面生成器组件的实例在存储器被高速缓存，并用于创建每个请求的页面输出。页面生成器是支持在构建页面控件树页分析器一个特殊的组成部分。当编译被接通时，在控制树用于获取类进行编译。当编译为关闭时，控制树用于获取标记。不用说，如果你想给程序员附加自己的code到页面的功率等级是必要的。没有编译页面是由服务器控件和文字，但不包含code在所有。
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.
没有编译页面不是为每个应用。它们是专为与数千页非常大的网站提高了可扩展性。没有编译页面不能被绑定到code文件，不能包含一个服务器端的块。允许在无编译页的唯一可执行件code是$ -ex pressions。有没有出来，编译页面的两大好处。在像SharePoint中的安全环境，从写潜在马车code可能导致问题的托管环境，甚至撕裂下来非编译页prevent开发商。在一个大的基于内容的网站的，非编译页面避免需要编译数千页。
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.
参考文献：
[1] -
http://haacked.com/archive/2009/04/22 /scripted-db-views.aspx
推荐答案
首先要注意的是，自定义页面（可能是masterpages或页面布局）总是存储在数据库中。
First thing to note is that customized pages (Could be masterpages or page layouts) are always stored in the database.
页面请求周期不同于方式SPVirtualPathProvider路由请求香草ASP.net版本。一旦它发现请求的是一个定制的页面制作（相对于未定制的页面坐在在文件系统上，并受通常的ASP.net页面编译模式）页面的code是从数据库中抽取，移交到ASP.net运行，并在解析无编译模式。
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."
的下面是这个过程的可视化再现时的自定义页面的请求时：的
没有编译页数：
没有编译页面能够提高
扩展大型网站拥有1000
页面，窗口有号限
加载到应用程序，并PERF的DLL
降低你打这个限制。组
在＆lt;％@页CompilationMode =自动
％GT;指令编译
有条件获得的缩放
好处，而不在code限制。
您还可以设置为CompilationMode
从不，以prevent从以往的页面
正在编制。您可以设置此
页/＆gt;在在＆lt财产;部分
在Web.config中应用到的所有网页
一个应用程序。到无编译页会
抛出一个错误，当它包含用户
code。
No Compile Pages:
No Compile Pages enables improved scaling for large sites with 1000s of pages, as windows has limit on number of DLLs loaded into an app and perf degrades as you hit this limit. Set the <%@ Page CompilationMode="Auto" %> directive to compile conditionally to obtain the scaling benefits without limitations on code. You can also set CompilationMode to "Never" to prevent the page from ever being compiled. You can set this property on the <pages/> section in Web.config to apply to all pages in an application. A no-compile page will throw an error when it contains user code.
因此，这基本上解决了你的问候过量施用重置提到卸载时/加载应用程序域由于多个自定义实时发生的（问题的任何CMS建立在ASP.net运行时必须处理）这个问题。
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).
在此之上;你得到的多用户功能和SQL Server存储以这种方式定制的内容时的免费的可扩展性;而不是一个文件系统的做法，将需要额外的努力来管理锁定。
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.
这篇关于的SharePoint，VirtualPathProviders和应用程序重新启动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
