Make ExpressionBuilders Work for You

Retrieve Registry Values Using a Custom ExpressionBuilder





Make ExpressionBuilders Work for You

Retrieve Registry Values Using a Custom ExpressionBuilder


By Gregory Corbin


ASP.NET 2.0 provides many new features that make Web application development easier. We now have an entire library of new controls and a massive collection of new classes to assist us in our development efforts. One of the new features I find most useful are the built-in ExpressionBuilders, which allow you to retrieve a value from the AppSettings or the ConnectionStrings section of the web.config file and assign that value to an attribute of a control via markup. Sure, we could accomplish the same thing in ASP.NET 1.x by using the ConfigurationSettings class, then setting the attribute in the code-behind but this new feature allows us to do this using only markup.


In addition to being able to get values from the web.config file, there is another built-in ExpressionBuilder that will allow us to get values from a resource file. One note to make here is that all expressions returned by the ExpressionBuilder are evaluated to strings. This means we can t pull a binary object, such as an image from a resource file, and display it in a page. Also, the ExpressionBuilder is only able to get at resources that have been stored in the App_LocalResources and App_GlobalResources folders.


The code in Figure 1 is an example of using the AppSettings built-in ExpressionBuilder. This ExpressionBuilder can be very useful, because we are not restricted as to which attribute to which we can assign this type of builder. So long as the element has the runat= server attribute, we can use any attribute we want. As you can see in Figure 1, we assign a value to both the Text and ToolTip attributes. Figure 2 shows how the data that the expression uses is defined in the web.config file.


  ToolTip="<%$ AppSettings:BusinessSlogan %>">

Figure 1: AppSettings markup from Default.aspx.




Figure 2: Expression definition from web.config.


The code in Figure 3 shows an example of the ConnectionStrings built-in ExpressionBuilder. This can be helpful, in that we don t want to hard-code the username or password into the markup or code. This would mostly be used by an element, but, again, there are no restrictions to which attributes this can be assigned. Figure 4 shows how the data for the expression is defined in the web.config file.


Figure 3: ConnectionStrings markup from Default.aspx.


 "Server=acme_db_server;User ID=sa;Password=pass;

 Database=acme_db;" providerName="System.Data.SqlClient"/>

Figure 4: Expression definition from web.config.


The code in Figure 5 shows an example of the Resources built-in ExpressionBuilder. This can be useful when needing to localize your application. We could create a set of resource files that contain all the strings for each language needed for our application, then load the appropriate resource. The expression builder would get the string, as needed. There are no web.config settings needed for this type of ExpressionBuilder.


Figure 5: The Resources markup from Default.aspx.


Like most features provided by the .NET Framework, the ExpressionBuilder class is also extensible. In fact, the built-in Expressions we just demonstrated are derived from the ExpressionBuilder class and we can use this class to build our own custom ExpressionBuilders. To do this, we ll need to create a class that inherits from the ExpressionBuilder class and override one of its methods. The ExpressionBuilder class is located in the System.Web.Compilation namespace, so our new class will need to use this namespace. The method that needs to be overridden is the GetCodeExpression method, which is used to associate a method that you would like to execute during page evaluation of your custom expression. To demonstrate the use of this class, the sample code shown in Figure 6 creates a custom ExpressionBuilder that uses the Registry class to get the Windows product ID and display it within a page.


Figure 6: A sample custom ExpressionBuilder that uses the Registry class.


The sample shown in Figure 6 is divided into two classes. The first class, RegistryExpressionBuilder, inherits from the ExpressionBuilder class. The ExpressionBuilder class is an abstract class that has one property and three methods (for details on each of these methods and its property, see Figure 7).


Property & Methods



This is the only property in the class. It returns a Boolean value that indicates if the current ExpressionBuilder object supports no-compile. This means that during page processing, this ExpressionBuilder property will check if the current page allows processing without compilation. If this is true, then no expression evaluation will occur during compilation.


This returns an object that represents the already evaluated expression. This is useful when the current page does not support compilation. When this is true, this method will evaluate the expression at run time.


This returns code to the framework for evaluation. This is an abstract method where you would define which of your methods should be evaluated.


This returns an object that represents the parsed expression. It is called to validate that the expression s syntax is correct. It should be used to perform any custom validation for the expression.

Figure 7: The abstract ExpressionBuilder class.


The second class is called the RegistryParsingHelper. A registry key can be separated into three parts: a rootkey, a rootpath, and a key. This class was created to encapsulate the logic of parsing a registry key into its parts. This class has three properties and one method. The one method is called when needing to parse a registry key into its parts and store the values. Our RegistryExpressionBuilder class then calls on these three properties to open the registry and extract the key s value.


As mentioned earlier, there are alternative ways to implement the same functionality using the ConfigurationSettings class. The drawback to that approach is that it doesn t take advantage of the built-in infrastructure by using the methods it offers. Without using the RegistryExpressionBuilder class, you would need to implement all the code and logic to retrieve, parse, and display the data. In the code sample shown in Figure 6, we can see that the .NET Framework takes care of retrieving and parsing the expression from the ASP.NET page markup all we need to do is decide what to do with the data that is given to us.


One implementation of a custom ExpressionBuilder not yet discussed is how it can be reused in other projects. This is actually quite easy. All that needs to be done is to open a new ASP.NET Web application and add a class that will implement the ExpressionBuilder methods needed. Then build the project and take the assembly that is produced and include it in whichever project you want to use it. You ll also need to add the configuration for the custom expression to the web.config file of your project. This is a more common way of implementing custom expressions. I use the ExpressionBuilder shown in Figure 6 in many projects in this manner. I find it helpful to be able to get my database connection strings from the registry and assign it to a SqlDataSource control by using the RegistryExpressionBuilder. Another use of the RegistryExpressionBuilder is in creating administrative Web applications. In these types of applications, it is often helpful for the user to know on which version of Windows, .NET, and IIS the application is running, which easily can be retrieved from the registry. Figure 8 shows an example of the output generated by the code in Figure 6. To get more details about ExpressionBuilders, see the Microsoft MSDN documentation.


Figure 8: The output generated by the code in Figure 6.


Sample code accompanying this article is available for download.


Gregory Corbin is a Sr. Software Engineer for a top healthcare company based in Boston, MA. He has developed software for corporations such as Fidelity Investments, NASA, Quantum Computer Corporation, and In his free time, he enjoys digital photo editing, making short films, and woodcrafting. Contact Gregory at mailto:[email protected] with questions or comments.




Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.