ASP.NET Miscellaneous Features

Besides the build-in ASP.NET objects, ASP.NET technology also provides extra features for easier of web application design in ASP.NET environment. The most common feature is the reusing of existing codes.

Server Side Include File

ASP.NET supports only the server-side include directive, #include, for inserting the content of any specified file into the ASP.NET file before processed by the IIS web server. This feature allows some common functions, e.g. headers, footer, or elements, saved as seperated files to be reused by multiple pages.

Syntax

<!-- #include file|virtual=file name -->

Attributes:

file:The "file" keyword implies the usage of a physical path, can be relative, began with the file directory that contains the including file named with the "file name" parameter. virtual:The "virtual" keyword implies the usage of a virtual path, can be relative, began with the virtual directory that contains the including file named with the "file name" parameter.

Parameters:

file nameThe parameter "file name" is the partial location of the full path that contains the including file which is either relative to folder directory or refered to the virtual folder and is enclosed by quotation marks (" ").

Remarks:

Because the #include directive is used to insert a file into the ASP.NET file before the ASP.NET engine processing it, the #include directive is placed outside the ASP.NET delimiters for easier to manage. Instead of using a new HTML tag, the #include directive is placed inside a HTML comment tag for preventing the #include directive being rendered and interpreted as literal text in the HTML document by mistake. Usually the #include directive is placed immediately after the open comment character with a preceded space although the key word "#include" can be placed anywhere within the comment tag.

Since text is inserted to the ASP.NET page before the any ASP.NET code of an ASP.NET page is being interpreted by ASP.NET engine, an #include file can any form of codes, e.g. HTML tag blocks,  ASP.NET code blocks or Script blocks. And the inserted file is immediately processed after inserted, therefore even the #include directive can also be used in the #include file. However, since the #include directive is executed before any interpretion of the ASP.NET code script can be taken place, no ASP.NET code can be used as the value of the parameter "file name"

<!-- #include directive DOES NOT WORK as expected -->
<% filename=(Day(date) & ".inc") %>
<!-- #include file="<%=filename %>" -->

The included file can be included more than one time in the same including file. Or the included file can include other files also. The only limitation on including file is that the included files do not form a closing loop which will cause a nesting error.

Although the included file is processed immediately after inserted, the included file is considered as a nested individual script block. In other words, HTML tags, <SCRIPT> blocks, or ASP.NET script blocks in an included file must be a complete unit.

As contents of these included file blocks will hold up extra resources once the file is included in the ASP.NET page, an inefficient use or waste of the limited resource may affect the overall performance and limit the scalability of web application ultimately. Therefore include file should be compact and precise. An include file with multiple functions can be broken down into smaller files with specific functions for preventing superfluous information is being included.

There is no special requirement on the file name extension. The file name extension of an included file can be .inc for easier to distinguish them from other types of files. But the file name extension of an included file can also be .asp or .aspx so that these file will be interpreted before response to the client. If sensitive data is stored in the include file with file name extension used is .inc, then the IIS script mapping for the .inc extension can changed from ssinc.dll to asp.dll for taking the advantage fo the ASP.NET engine to process the imported script. Besides , the Server.Transfer Method and Server.Execute Method are the alterenates for including file in ASP.NET applications.

In general, both the "file" and "virtual" can be used to retrieve the same file, but there is limitation. For example, a web site is located in C:\Inetpub\Wwwroot and the application file, named apps.asp  is located in C:\Inetpub\Wwwroot\apps i.e.  C:\Inetpub\Wwwroot\apps\apps.asp.

When the "file" keyword is used with the #include directive, the parameter "file name" cannot start with forward slash or back slash. Using the "file" keyword with the name of included file enclosed by quotation marks if the included file is located in the same directory, i.e.  C:\Inetpub\Wwwroot\apps\include.inc.

<!-- #include file="include.inc" -->

Using the "file" keyword with the corresponding lower-level directory and the name of included file enclosed by quotation marks if the included is located in the a lower-level directory, i.e.  C:\Inetpub\Wwwroot\apps\inc\include.inc.

<!-- #include file="inc\include.inc" -->

If the included file is located in another branch of directory tree, a double dot, ".." with syntax "..\" can be used to raise the path to the parent or one higher-level directory. However, by IIS 6.0, the parent paths are disabled to increase security by default and an "Enable Parent Paths" option should be checked to enable the parent paths property. Besides, the single dot, "." with syntax ".\" is to return the parent directory of the including file and is same as using  the name of included file as the value of the "file name" parameter.

Using the "file" keyword with the double dot syntax for raising the path of application to the common parent directory  plus the corresponding branch of directory tree and the name of included file enclosed by quotation marks if the included file is located in the another branch of directory tree, i.e.  C:\Inetpub\Wwwroot\inc\include.inc.

<!-- #include file="..\inc\include.inc" -->

When the "virtual" keyword is used with the #include directive, the parameter "file name" can be started with forward slash or back slash. Using the "virtual" keyword with the corresponding lower-level directory refered to the root of web site and the name of included file enclosed by quotation marks if the included file is located in the same directory, i.e.  C:\Inetpub\Wwwroot\apps\include.inc.

<!-- #include virtual="/apps/include.inc" -->

And, using the "virtual" keyword with the corresponding lower-level directory refered to the root of web site and the name of included file enclosed by quotation marks if the included is located in the a lower-level directory, i.e.  C:\Inetpub\Wwwroot\apps\inc\include.inc.

<!-- #include virtual="apps/inc/include.inc" -->

Similarly, using the "virtual" keyword with the corresponding lower-level directory refered to the root of web site and the name of included file enclosed by quotation marks if the included is located in the a lower-level directory, i.e.  C:\Inetpub\Wwwroot\nc\include.inc.

<!-- #include virtual="/inc/include.inc" -->

Although include files can be placed in any directory, A better practice is to store all include files within the same application or web site. And if the include files are saved in as separated directory within the application, e.g. /inc, it is much easier to appropriate permissions to a directory for better security, since the web server read permissions are applied to all files and disable the read permissions for the include directory can prevent users from viewing the contents of include file.

An ASP.NET page with included file is not a page with static scripting for the whole application or session scope because the ASP.NET engine will detect any changes to the included file when this included file, included by an ASP.NET file is being requested, before inserting the file contents to the ASP.NET page.

Source/Reference

• http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconserver-sideincludedirectivesyntax.asp?frame=true
• https://support.microsoft.com/en-us/help/306575/how-to-dynamically-include-files-in-asp-net
• https://support.microsoft.com/en-us/help/192144/how-to-dynamically-include-files-in-active-server-pages
• https://docs.microsoft.com/en-us/previous-versions/iis/6.0-sdk/ms525185(v=vs.90)

Server-Side Script Block

Another useful feature of ASP.NET technology is the server-side script <SCRIPT runat="server> element. This feature allows resembling multilines of inline script of a specific purpose into a modular base functional module as an embedded server-side function. Therefore <SCRIPT> can blocks can be reused in web design easily. To enhance the capability of server-side <SCRIPT> tag,  a new "SRC" attribute is supported as an alternative method for including another file by IIS 5.0.

Syntax:

<SCRIPT LANGUAGE=language name RUNAT="SERVER" SRC=file name ></SCRIPT>

<SCRIPT LANGUAGE=language name RUNAT="SERVER">...</SCRIPT>

Attributes:

LANGUAGE: The scripting language of the server-side script.

RUNAT="SERVER": The attribute with specified parameter "SERVER" enclosed by quotation marks (" ") is used to specify the type of script is of the server-side script runing at the server only.

SRC: The source location of the script file

...: Script statements

Parameters:

language name

The parameter "language name" is the name of the scripting language used in the script file that to be retrieved and is enclosed by quotation marks (" ").

file name

The parameter "file name" is the name of the script file that to be retrieved and is enclosed by quotation marks (" "). The parameter "file name" can be either relative or virtual paths. For example,

Relative: SRC="filename.ext"

Relative: SRC="folder\filename.ext"

 Virtual: SRC="\folder\filename.ext"

Virtual: SRC="/folder/filename.ext"

Remarks:

This feature allows the resembling of multilines of inline script of a specific purpose into a modular base functional module. For example, a <SCRIPT> block

<script language = "vbscript" runat = "server">
function strCutName(strName)
strCutName = Right(strName, 3)
end function
</script>

There is a very high flexibility in using the scripting language for <SCRIPT runat="server> element by specifying the language attribute of scripting language provided that the scripting language is supported by the ASP.NET engine. And <SCRIPT> elements of multiple scripting languages are allowed in the same file or same web page. This feature also enable higher language flexibility in ASP.NET page design when using <SCRIPT> blocks and becomes one of the obvious advantage of ASP.NET technology.

<script language = "vbscript" runat = "server">
function vbCutName(strName)
strCutName = Right(strName, 3)
end function
</script>
<script language = "jscript" runat = "server">
function jCutName(strName) { return strName.slice(2)}
</script>

However, only one specified scripting language is allowed for each <SCRIPT> block.

The new "SRC" attribute only extends the capability of importing the <SCRIPT> block from a script file instead of the using of inline scripting. The <SCRIPT> block will be injected between the <SCRIPT> tags just before processing.

Unlike the client side <SCRIPT> block, the server side include, #include directive, in a server side <SCRIPT> block is not supportted since a server side <SCRIPT> is processed after  #include directive while a client side <SCRIPT> block is treated as a static HTML tage only. And therefore the server side include, #include directive is also not support in a server side <SCRIPT>.

Besides, since a scripting language is assigned to the server-side <SCRIPT> block, only the script codes of the specified scripting language in the server-side <SCRIPT> block are supported. No HTML tags or ASP.NET code block with delimiters <%...%> are allowed since all script codes are assumed to be script statements to be processed by the specified language engine only.

And same as the #include directive, no script command can be used for the value of the "SRC" parameter also.

Although both the response.write command and other supported script statement can be placed in the <SCRIPT> element, these processing statements are usually not  to be existed as some inline processing statement by mixing <SCRIPT> blocks with ASP.NET code blocks (<% ... %>) in the same page, becasue the result of the page respone might be unexpected as the order of statement blocks processing is controlled by the mechanism of the processing procedure of the ASP.NET engine, not the sequence of the statement blocks.  Because of the unexpected sequence of processing the server side <SCRIPT> element due to the complexity of the script arranged by the ASP.NET engine, the server side <SCRIPT> element is usually used for containing procedures and functions only and the sequence of the result of the server side <SCRIPT> element is injected to the page accordig to the sequence of the ASP.NET code blocks (<% ... %>). Therefore, only in some case, the <SCRIPT> element can be used as a server side include directive.