In-Place Compilation using ClientBuildManager.Comp

问题:

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.

Why Does IIS Build to a Different Subdirectory under "Temporary ASP.NET Files"?

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.

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

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

Example:

• 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]\

ClientBuildManager.CompileFile Configuration

var buildParameter = new ClientBuildManagerParameter
   {
      PrecompilationFlags = PrecompilationFlags.Default,
   };
var clientBuildManager = new ClientBuildManager(
   RootVirtualPath, RootPhysicalPath, null, buildParameter);
...
clientBuildManager.CompileFile(relativeVirtualPath, callback);

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.

回答1:

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.

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:

• Pass something like /LM/W3SVC/7/ROOT/ for appVirtualDir
• Pass null for appPhysicalSourceDir

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

• 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/

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.

• 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.

回答2:

Sam, the answer is a cross between David Ebbo's answer, and your original code.

var buildParameter = new ClientBuildManagerParameter
   {
      PrecompilationFlags = PrecompilationFlags.Default,
   };
var clientBuildManager = new ClientBuildManager(
   RootVirtualPath, RootPhysicalPath, null, buildParameter);
...
clientBuildManager.CompileFile(relativeVirtualPath, callback);

If you do what David Ebbo said and use this for the RootVirtualPath when constructing the ClientBuildManager:

/LM/W3SVC/7/ROOT/

you then have to pass in null for the RootPhysicalPath.

That should get rid of the rest of the issues, and it should build to the same directory that IIS is looking for.