Email Password Remember me?  Lost your password?

• Download source and executable - 33.6 Kb

Introduction

I know: the problem of pre-compiling an ASP.NET web site in order to avoid the classic "compilation delay" felt by the first user browsing those site's pages has been faced many times, and a lot of solutions have been proposed to solve it. But, when I was looking for these solutions to a classic problem, I didn't find the one that I liked completely. So, I decided to develop my own ASP.NET precompiler.

Of course, now you are thinking: "Uff, yet another pre-compile tool for ASP.NET web sites". And you're so right that I decided to title my article exactly with the words you have in your mind. But... before you stop reading, take a look at some peculiarities of the tool I propose.

Background

My starting point was the CodeProject article "Pre-Compile ASPX pages in .NET 1.1" by Narendra Naidu: there, the precompiling task was faced by simply adding to the web site a special ASP.NET page simulating an HttpWebRequest towards each ASPX page of the web site itself.

That was a nice and simple solution, but not suitable in my specific situation. In fact, I was looking for:

• something not implemented as a part of the web site, but as a separate application;
• something not forcing me to precompile all the pages of my web site, but capable to focus only on a specific subset of them (for example, the most frequently used ones);
• something working also with web sites protected by the ASP.NET Web Form Authentication mechanism;
• something able to simulate client web requests coming from a specific browser;
• something with the ability to keep track of compilation errors.

The ASP.NET precompiler I wrote matches all these goals, in fact:

• it's a Windows Forms application, that doesn't force you to include the precompiler logic inside the web site itself;
• it doesn't retrieve the pages to visit recursively walking on the web application folders tree, but it takes them from a user-configurable list of URLs;
• it works also with web sites protected by Web Form Authentication, supporting a specific POST of data to the Login page and correctly managing the client-side authentication cookie;
• it can "impersonate" a specific user agent, allowing you to work also with sites where some browser checks are implemented to force a navigation restriction;
• it logs any error occurring during HTTP requests, that is very useful if - for some reason (for example, to have a more flexible deploying strategy) - you are not compiling your site's code-behind pages into a DLL assembly (that is: you're taking advantage of the src attribute of the @Page directive).

How to use the tool

As stated before, the tool forces the compilation of ASPX files just invoking their URLs in a web request. The list of the URLs to be hit is stored in a user-editable text file, that we'll simply call "URL file". The format of the URL file is simple: it stores an URL on each line, separating with a TAB character the base URL part from the relative path of the ASPX page. This split URL paths make simpler to invoke the same set of pages on different web sites (this is useful, for example, if you have various copies of the same ASP.NET site on different environments).

To create the URL file, you can use ASP.NET precompiler itself: select the "Generate URLs" option from the "File" menu and specify: the physical location of your web site's files, the base URL that will precede the relative page path in the final URL, and the filename for your new URL file.

ASP.NET precompiler will walk recursively the specified path looking for ASPX files and it will generate your URL file, that can be manually edited later (for example, to refine or limit the set of pages to be precompiled).

To make the ASP.NET precompiler less "invasive" on your site, you can adopt a trick I found in Narendra Naidu's article: by adding a Response.End() inside the pre-request event handler of Global.asax, you can abort the page processing and rendering when you call your pages with a special parameter (for example, PreCompile=true). In this way, the requests coming from ASP.NET precompiler will cause the page compilation but not the complete overhead of serving a complete web request.

  Private Sub Global_PreRequestHandlerExecute(...) _
                   Handles MyBase.PreRequestHandlerExecute
    ' Prevent processing if page was called with a "PreCompile" parameter

    If Not Request("PreCompile") Is Nothing Then Response.End()
  End Sub

If you are planning to use this trick, you'll need to check the "Include PreCompile parameter" option when generating the URLs list with ASP.NET precompiler. Also, keep in mind that the Global_PreRequestHandlerExecute() handler will be invoked for each page requested on your web application, and this might cause a little impact on the web site performance.

When the URL file is ready, before starting the pre-compilation process, you need to configure some parameters on the ASP.NET precompiler's main form:

• specify the name of the URL file you are going to use;
• if you need to simulate web request from a specific browser, fill the textbox User Agent with the correct user agent string;
• if you plan to invoke the pages stored in the URL file substituting the original base URL path with another one, use the Alternative Web Root option;
• if the site you're working on is protected by Web Form Authentication, use the Web Form Authentication option, specifying the relative path for the Login page and the parameters it expects; activating this option will produce a preliminary POST request to the Login page to obtain the authentication cookie for subsequent requests (don't forget to include the __VIEWSTATE parameter with a valid value in the POST params textbox);
• if you want to log any error occurred during the compilation process, activate the Log errors option, specifying the filename for the log (that is an HTML-formatted file, for easy viewing in a browser window);
• if you need to clear the error log or the cookies collection before compiling, use the Reset cookies or the Reset error log option respectively.

The configuration settings you just set can be saved to disk for future use. The reuse of ASP.NET Precompiler settings is accomplished by the options of the "File" menu (for the storage mechanism underlying the saving/retrieval of these data, see my article about managing configuration settings persistence).

You must Sign In to use this message board.

Per page 102550

FirstPrevNext

Entering POST Params daleallenc 8:00 30 Dec '08   Hello, Alberto. "Homer" here again. I have a couple of questions about entering values into the POST Params field (and please, I'm a sysadmin, not a developer/programmer): 1. The UserName (txtUserName), Password (txtPassword), and SignIn button parameters for our demo website are not the same as the default example given in the Untitled configuration file, so I assume that I need to change them to match what's given in the login page's source code. Only I'm not sure what to change them to. For example, the source code lists a label for="PC706_txtUsername", an input name="PC706$txtUsername", and an id="PC706_txtUsername". The password parameters are essentially the same. The submit button is equally problematic for me: input type="submit", name="PC706$btnLogin", value="Login", and id="PC706_btnLogin". What do I need to enter? 2. Your article says "don't forget to include the __VIEWSTATE parameter with a valid value in the POST params textbox" How do I do that? Thanks again for your help. Even without making the authentication request, your precompiler makes our demo website extremely responsive on first request. In case you were wondering why I might be using this instead of the .NET 2.0 aspnet_compiler tool, it's because the Microsoft tool refuses to work if it finds a single error (and I don't have control or influence over the code). And there isn't any option for passing login parameters, either. Have a safe and happy New Year! Sign In·View Thread·PermaLink Re: Entering POST Params Alberto Venditti 4:41 9 Jan '09   Hi. Sorry for late reply, due to (finally!) some vacancies. About your question #1: If I'm not wrong, form POST parameters should use "name"s and not "id"s. So, you should try with: PC706$txtUsername=yourName&PC706$txtPassword=yourPassword&PC706$btnLogin=Login before trying with: PC706_txtUsername=yourName&PC706_txtUsername=yourPassword&PC706_btnLogin=Login About your question #2: To retrieve a valid value for the VIEWSTATE param, you could: a. navigate with your browser your login page b. before logging in, inspect the HTML source c. if you see inside your HTML form an INPUT hidden tag named "__VIEWSTATE", copy its "value" and supply it to the compiler tool concatenating it with other parameters: ...&PC706$btnLogin=Login&__VIEWSTATE=dDwtMzIyNjUxMzt0P... I see you already inspected your login page HTML source: if you didn't see VIEWSTATE, maybe your login form doesn't include any VIEWSTATE. --- In general: if you still have problems in providing the right POST parameters, you could "sniff" them while navigating and logging in interactively on your login page (to "sniff", you could use the "Live HTTP Headers" add-on for Mozilla Firefox, for example). Let me know if everything is okay. Cheers, AV Sign In·View Thread·PermaLink 5.00/5 Re: Entering POST Params daleallenc 8:14 12 Jan '09   That was perfect, Alberto. Many thanks. I was worried a little bit about the VIEWSTATE value because the hash value is over 3000 characters long, but your utility handled it without a problem. Sign In·View Thread·PermaLink Run from logon script or batch file daleallenc 9:12 4 Aug '08   I actually have more than one question, but this is the scenario: I have a VMware virtual machine that our company's sales people use to demonstrate our web-enabled software. We've tried just suspending the VMs to save the website state in between demos, but that seems to break down the VM files quickly and unexpectedly leading to some embarrassing moments. I stumbled across this wonderful utility, and demos now run much smoother and with more confidence. I'm normally a system administrator, not a developer, so I'm wondering: 1) Is it possible to run the utility, with the appropriately identified configuration file, from a logon script or batch file? (The less a sales person has to do, the better - and we'll both be happier) And, 2) Is it possible for the pre-compiler to make more than one Web Form Authentication request? Sign In·View Thread·PermaLink Re: Run from logon script or batch file Alberto Venditti 6:09 5 Aug '08   Hi "daleallenc". About your question number 1: The simplest solution is to make the tool capable of handling some command-line argument in order to understand which config file has to be loaded and if the execution has to fire immediately the precompile operation. Supposing you want to support these following execution variations: > ASPdotNETprecompiler.exe -autorun will automatically start the precompile operation using the default config file ("Untitled.cfg") > ASPdotNETprecompiler.exe MyConfig.cfg will automatically load the specified config file ("MyConfig.cfg") > ASPdotNETprecompiler.exe -autorun MyConfig.cfg will automatically load the specified config file ("MyConfig.cfg") and start the precompile operation all you will need is to modify the MainForm_Load() procedure in the following way: Private Sub MainForm_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load Dim ConfigFilename As String = DefaultConfigFilename Dim AutoRun As Boolean = False Dim cla As String() = Environment.GetCommandLineArgs If cla.Length > 1 Then If cla(1).ToLower = "-autorun" Or cla(1).ToLower = "/autorun" Then AutoRun = True If cla.Length > 2 Then ConfigFilename = cla(2) End If Else ConfigFilename = cla(1) End If End If ConfigOpt.Initialize(ConfigFilename) ReadConfigValues() Me.Text = Application.ProductName & " - " & ConfigFilename ConfigToBeSaved = False If AutoRun Then cmdPreCompile_Click(Nothing, Nothing) End If End Sub About your question number 2: In order to make the tool execute multiple WFA, we need to modify the current concept of "Start with this Web Form Authentication request" checkbox. Maybe the best solution is to create a special syntax for specific lines in the URLs.txt file (to be manually edited) where more [Login URL / POST parameters] combination are specified in particular point of the URLs-to-be-visited sequence. Then, a simple modification in the "Main loop for hitting web requests taken from the URLs file" procedure is needed to manage the new case. If you need just two or three WFA (followed by - I suppose - a set of child pages to be visited), my suggestion is to: - implement the solution for question 1; - prepare two or three appropriate config files, equipped with corresponding "URLs" files; - execute (in a batch) ASPdotNETprecompiler.exe more times, sequentially, with the different configurations. Hope this helps. Cheers, AV Sign In·View Thread·PermaLink 5.00/5 Re: Run from logon script or batch file daleallenc 4:25 6 Aug '08   Thank you for your excellent and timely response, Alberto. I really didn't expect one since the last post here was over two years ago. I modified the MainForm_Load() procedure as written (copy-and-pasted lines from Dim ConfigFileName... to last End If) in MainForm.vb. I wasn't sure if I should overwrite the existing procedure or append to it. At first, I overwrote the existing procedure and when I received the behavior listed below, I then tried appending the new code to the existing. I separately ran both with the different execution variations from the CLI. In both cases, the resulting behavior was the same. Behavior: 1. All execution variations opened the ASP.NET precompiler GUI but did not run the application. 2. All execution variations loaded the Untitled configuration file, even when others were named. I guess we're thinking alike as far as question number 2. Your solution is exactly what I was thinking if the tool could be made to use command-line arguments. Sign In·View Thread·PermaLink Re: Run from logon script or batch file [modified] Alberto Venditti 4:42 6 Aug '08   Hi. The code included in my preceding post is intended to "replace" the original content of MainForm_Load() procedure. Maybe you're compiling the project with a newer version of Visual Studio or of the .NET Framework? The original code was for VS2003 and .NET 1.1 (and I only tested the proposed modifications on that original target). Let me know, and we'll address the issue. Ciao, AV modified on Wednesday, August 6, 2008 11:49 AM Sign In·View Thread·PermaLink Re: Run from logon script or batch file daleallenc 4:54 7 Aug '08   Ah, I thought something like that might be the case. The specific .NET Framework version we're using is v2.0.50727. thanks Sign In·View Thread·PermaLink Re: Run from logon script or batch file Alberto Venditti 6:36 7 Aug '08   I actually converted the solution to VS2005 / .NET 2.0, I applied the modifications to Form_Load, and I found it working... Hence I find strange it is not working for you. Are you sure you're launching the EXE having set the OS default directory to the one hosting the EXE itself, so that it is able to retrieve the config and URLs files correctly? AV Sign In·View Thread·PermaLink Re: Run from logon script or batch file daleallenc 9:52 7 Aug '08   Are you familiar with "The Simpsons" in Italy? Just call me Homer. DOH! Not having programmed since college, I forgot that I needed to rebuild the executable after modifying the source code. After converting the solution, applying the modifications, and rebuilding (DOH!) the executable, it works as advertised. Is there a way to close the Main form from the command line after it's finished pre-compiling? Sign In·View Thread·PermaLink Re: Run from logon script or batch file Alberto Venditti 0:35 8 Aug '08   Homer, to automatically close the application when autorun mode finished its work, just modify these lines: If AutoRun Then cmdPreCompile_Click(Nothing, Nothing) End If in: If AutoRun Then cmdPreCompile_Click(Nothing, Nothing) Application.Exit() End If Cheers, AV Sign In·View Thread·PermaLink 5.00/5 Re: Run from logon script or batch file daleallenc 4:12 8 Aug '08   That's perfect. I've generated a simple batch file to start (from a Windows GPO) at user logon. It's set to run twice with a different WFA in each. It executes, precompiles, stops, and exits without user interaction. Perfect. Grazie mille, Alberto, for all of your time, effort, and patience. Sign In·View Thread·PermaLink How long is the precompilation valid? RC2006 14:17 7 Jul '06   Once the precompilation is performed, will i need to recompile everytime I restart IIS? Or do thecompiled images expire if the application is idle for some time? What if the application uses a number of DLLs (some APIs or such) deployed in the bin folder? Thanks in advance for a response. RC Sign In·View Thread·PermaLink Re: How long is the precompilation valid? Alberto Venditti 3:39 10 Jul '06   Q: "will i need to recompile everytime I restart IIS?" A: Sure. Any compiled code resulting from the JIT compilation is discarded when: - IIS is restarted; - the Application Pool serving your web app is stopped or restarted; - web.config is modified (-> Application Pool restarted) - bin folder is modified (-> Application Pool restarted) The assemplies DLL deployed in the bin folder contain MSIL code (resulting from the first compilation of source code by the standard language compiler), and they also need to be JIT-compiled to obtain native code. The only option I know to have native pre-compiled code already ready for execution ad any time is following these two steps: - developing a strongly-named DLL assembly to be installed in GAC; - using NGEN.EXE (.NET Framework SDK tool) to produce a native code, compiled image in the GAC. AV Sign In·View Thread·PermaLink Viewstate schmig 10:54 16 Aug '04   Any hints as to how to get the appropriate viewstate? I've tried copying and pasting from View | Source, and actually GETting the login URL and parsing out the viewstate before doing a POST -- I just keep getting invalid viewstate error messages. EDIT: Never mind. Just forgot to UrlEncode() the __VIEWSTATE value. Oops. Sign In·View Thread·PermaLink Re: Viewstate Alberto Venditti 2:26 22 Aug '04   Yes, the only trick to keep in mind is to correctly encode special chars eventually found in the VIEWSTATE. Sign In·View Thread·PermaLink 401 error Luke Geng 8:21 8 Jun '04   It's a great application! It runs well for localhost but it gives me "The remote server returned an error: (401) Unauthorized." error message for each entry in LogFile.htm, althogh I do have admin right on remote servers. Any security settings I need to take a look at? Sign In·View Thread·PermaLink Re: 401 error Anonymous 22:20 9 Jun '04   The LogFile was initially conceived in an HTML format just to be easily readable with a local browser, being ASP.NET Precompiler thought as a client application. If you need to access to LogFile.htm from a remote client, you simply need to publish it on a web site or to put in on a file share, as you would do with any static HTML file to be published. Sign In·View Thread·PermaLink Re: 401 error mdavisxx 7:28 28 Jun '04   Hi, Thanks for a great article. However, I am getting the same 401 error on localhost. It fails on line ' Retrieve the response wres = CType(wreq.GetResponse(), HttpWebResponse) I even tried adding Dim netCredential As NetworkCredential = New NetworkCredential("mark", "password") ' "CORP") wreq.Credentials = netCredential Am I missing something in the web.config? Please help. Sign In·View Thread·PermaLink Re: 401 error Anonymous 17:06 15 Mar '05   try adding this line before adding any other properties ' Set credentials to use for this request. wreq.Credentials = CredentialCache.DefaultCredentials Sign In·View Thread·PermaLink Re: 401 error Anonymous 17:07 15 Mar '05   which is straight after the HttpWebRequest is created from the current URI wreq = CType(WebRequest.Create(URI), HttpWebRequest) ' Set credentials to use for this request. wreq.Credentials = CredentialCache.DefaultCredentials Sign In·View Thread·PermaLink Can this be used for WebService anshuk123 8:20 3 Jun '04   Hi, Can the above approach be used for a webservice asmx file. The webservice is already compiled into a dll file in bin folder. Let me know if there is a gap anywhere. Anshuk Jain Sign In·View Thread·PermaLink Re: Can this be used for WebService Anonymous 10:18 3 Jun '04   Hi. I'm not 100% sure and some tests are needed, but I think the answer is: yes, you can use this approach for Web Services. Also the WebToucher described in http://weblogs.asp.net/cweyer/archive/2003/02/07/2013.aspx targets in the same way .ASXP files and .ASMX files. Of course, you'll need to edit manually the URLs list (or modify the code that produce it in the "ASP.NET precompiler") to include .ASMX files also. Let me know if it works! Sign In·View Thread·PermaLink Re: Can this be used for WebService Anshuk Jain 22:54 16 Jun '04   Hi, Thanks for your response. I got the answer myself. I increased the time out of the connection to 5 minutes. Now its working. Sign In·View Thread·PermaLink

Last Visit: 6:20 24 Nov '09     Last Update: 6:20 24 Nov '09 1