A script starts with a header; similar to an ASPX page, the top
of the script defines the CodeTemplate header as shown below.
Listing 1
<%@ CodeTemplate Language="C#" TargetLanguage="Text" Src="" Inherits=""
Debug="False" Description="Template description here." %>
Most of the attributes are obvious in their function; I am
going to mention that templates can have code-behind files.
The script can make use of properties. Properties are not
quite like code-behind properties of server controls in ASP.NET. Instead, these
properties allow the person running the script to change some of the data that the
script will use. One of my example scripts is shown in the Property Grid (as
shown below).
Figure 2
The property definition is shown below. It uses a script
setting with the "at" sign to note the use of a property. This
property has several options that can be defined for it. Take a look at the
definition below.
Listing 2
<%@ Property Name="InheritedProviderClassName" Type="String"
Default="SomeProvider" Optional="False" Category="Class" %>
Some properties are required and some are optional, as noted
by the optional attribute. A required property will cause a build error if no
value is supplied. In addition, the category attribute breaks out these
attributes into separate logical containers. Properties can also have a default
value. The last thing I will mention is that there are various types that a
property can be defined as. In most cases, it may be a string, but more
specialized objects are available, as defined in the CodeSmith API. For
instance, the following property uses the StringCollection object to represent
a series of strings in comma-separated fashion. There is an example of this in
the screenshot above, looking at the ProviderMethodNames property in the Parameters
category.
Listing 3
<%@ Property Name="ProviderMethodNames" Type="StringCollection" Default=""
Optional="False" Category="Parameters" %>
Any assemblies and imports being referenced in the script
can be defined as below.
Listing 4
<%@ Assembly Name="System.Data" %>
<%@ Assembly Name="CodeSmith.CustomProperties" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Xml" %>
<%@ Import Namespace="CodeSmith.CustomProperties" %>
Again, this highlights the similarities to ASPX, where import
statements define the namespaces being used.