就地使用ClientBuildManager.CompileFile编译 [英] In-Place Compilation using ClientBuildManager.CompileFile

查看:194
本文介绍了就地使用ClientBuildManager.CompileFile编译的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我工作的一个网站,我想为了使第一次打快使用就地编辑上。我想使用的<一个href="http://msdn.microsoft.com/en-us/library/system.web.compilation.clientbuildmanager.aspx"><$c$c>ClientBuildManager. CompileFile 方法来做就地编译让我有编译过程的控制。由于各种原因,这是编译本网站的理想方式。

I'm working on a website that I'd like to use in-place compilation on in order to make the first hit faster. I'd like to use the ClientBuildManager.CompileFile method to do the in-place compilation so that I have control of the compiling process. For a variety of reasons, this is the ideal way to compile this website.

当我通过<一编译按文件网站文件href="http://msdn.microsoft.com/en-us/library/system.web.compilation.clientbuildmanager.aspx"><$c$c>ClientBuildManager. CompileFile 内置用于此目的的exe文件的方法,输出去的临时ASP.NET文件的子目录。但是,当网站被打到后来,IIS重建下的临时ASP.NET文件不同的子目录渲染previous就地编译毫无价值的控制。

When I compile a website file by file via ClientBuildManager.CompileFile method in an exe built for this purpose, the output goes to a Subdirectory under "Temporary ASP.NET Files". However, when the website is hit later, IIS rebuilds the controls under a different subdirectory under "Temporary ASP.NET Files" rendering the previous in-place compilation worthless.

注意:ASP.NET临时文件下,在就地编辑创建的组件被单独留在家中(仍然存在)

Note: The assemblies created during in-place compilation under "Temporary ASP.NET Files" are left alone (still exist).

注意:无论是就地编辑组件文件夹和IIS生成的程序集文件夹也按相同的临时ASP.NET文件目录

Note: Both the in-place compilation assemblies folder and IIS generated assemblies folder are under the same "Temporary ASP.NET Files" dir.

例如:

  • C:\ WINDOWS \ Microsoft.NET \ Framework64 \ v4.0.30319 \临时ASP.NET文件\ ROOT \ 2ba591b9 \ [就地编辑文件夹名称]
  • C:\ WINDOWS \ Microsoft.NET \ Framework64 \ v4.0.30319 \临时ASP.NET文件\ ROOT \ 2ba591b9 \ [ IIS生成的程序集的网站] \
  • C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\2ba591b9\[in-place compilation folder name]
  • C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\2ba591b9\[IIS generated assemblies for website]\
var buildParameter = new ClientBuildManagerParameter
   {
      PrecompilationFlags = PrecompilationFlags.Default,
   };
var clientBuildManager = new ClientBuildManager(
   RootVirtualPath, RootPhysicalPath, null, buildParameter);
...
clientBuildManager.CompileFile(relativeVirtualPath, callback);

其中, RootVirtualPath 简直是默认网站。 RootPhysicalPath 指向磁盘上的网站的位置<$ C C $>。 relativeVirtualPath 的形式为〜/ myFile.aspx的。回调是用来跟踪进展情况。

Where RootVirtualPath is simply "" for the default website. RootPhysicalPath points to the location on disk of the website. relativeVirtualPath is of the form "~/myFile.aspx". The callback is used to track progress.

推荐答案

我认为你看到的其实是无关的使用 CompileFile VS precompileApplication 。也就是说,如果你是做同样的事情,但叫 precompileApplication(),你仍然会得到一个文件夹不匹配。

I think that what you're seeing is actually unrelated to the use of CompileFile vs PrecompileApplication. i.e. if you were to do the same thing but call PrecompileApplication(), you still would get a folder mismatch.

请注意,从技术上说,你是不是正确创建煤层气对象。调用它的正确的方法是依赖于IIS的信息来定位文件。要做到这一点:

Note that technically, you are not creating the CBM object correctly. The correct way of calling it is to rely on IIS information to locate the files. To do this:

  • 在传递类似 / LM / W 3 SVC / 7 / ROOT / appVirtualDir
  • null传递 appPhysicalSourceDir
  • Pass something like /LM/W3SVC/7/ROOT/ for appVirtualDir
  • Pass null for appPhysicalSourceDir

请注意,该7仅仅是一个例子。为了得到正确的数字:

Note that the '7' is just an example. To get the correct number:

  • 运行INETMGR
  • 进入高级设置的网站
  • 找到该网站的ID。这就是你要在 / LM / W 3 SVC / ID / ROOT /
  • Run inetmgr
  • Go to the advanced settings for the site
  • Find the site ID. That's the number you want in /LM/W3SVC/ID/ROOT/

我解释这个备案,因为不幸的是,我是不是能够得到这些文件夹来匹配,即使在这种方式。这是可能的,这种情况是刚刚打破在ASP.NET(它使用的工作!)。

I'm explaining this for the record, because unfortunately, I was not able to get the folders to match even in this way. It's possible that this scenario is just broken in ASP.NET (it used to work!).

另一种可能性是做服务器端。例如,

An alternate possibility is to do it server side. e.g.

  • 在包括网页在你的网站,你会用它来触发选择性precompilation。
  • 在那里,呼叫 BuildManager.GetCompiledType(〜/ myfile.aspx),并要类似的呼吁每个页面(或用户控制等) precompile。
  • 当你想要触发您的自定义precompilation,只是请求页
  • include a page in your site that you'll use to trigger selective precompilation.
  • In there, call BuildManager.GetCompiledType("~/myfile.aspx"), and similar calls for each page (or user control, etc) that you want to precompile.
  • When you want to trigger your custom precompilation, just request that page

当然,也有简单地要求你想要编译时间来温暖你的网站未来的网页的低技术替代。

Of course, there is also the low tech alternative of simply requesting the pages you want compiled ahead of time to warm up your site.

这篇关于就地使用ClientBuildManager.CompileFile编译的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆