Very often when using either a DataList or Repeater control, you will see folks using an <AlternatingItemTemplate> template section just to change the background color of every other row. While this is perfectly acceptable, it can become time-consuming , especially if the templated row contains a significant amount of HTML. When it does, you have to ensure that any changes to the HTML in either section (<ItemTemplate> or <AlternatingItemTemplage>) are duplicated except for the background color of the table row of course.

If all you are doing is changing the alternating row color but don’t want to have to keep two sets of row level HTML in sync, there is an easier way. You can just use the primary <ItemTemplate> section so you only have one set of HTML to maintain, yet still have the background color of alternating rows change. Here’s how.

For Repeater Controls

First, turn the <tr> tag of the primary ItemTemplate template into a server control by adding ID and runat=”server” attributes.

Next, add the following code to the ItemCreated event of the repeater. Note that it simply locates the row tag you modified above and adds changes the back color.

The code in the ItemCreated event fires for every row created in the Repeater. It first checks if the row is an alternating row and if it is, it then locates the HTML <tr> tag and adds the alternating bgcolor attribute for you. Presto! Instant color change and all without duplicating your HTML layout in a second section.

For DataList Controls

Since the DataList is rendered as an HTML <table>, its DataListItem instances have style-related properties where you can apply a specific style to the entire item. This this makes it easier to accomplish our goal. Simply create a CSS class that defined your new background color, then reference that class as follows in the same event at above.

You can also use the same approach as the Repeater control if you prefer.

By default, the Web.Config settings placed in a root or parent folder are inherited by child folders. This is true even for virtual directories and Application sites with their own local Web.Config.

Problem

At first, this seems helpful. But when developing with a local IIS installation on a workstation OS, you may quickly find this becomes problematic. You may have multiple sites running locally for development reasons that will be stand-alone sites once deployed. You later discover that the deployed site no longer works since it now missing the values it was inheriting from a parent Web.Config.

An example could be where a connection string was defined in the root application and was inherited to your child Web.Config. Once the child site is deployed away from the parent, it fails as the entry is missing. What we want is to have more control over other Web.Config files and exactly what they are inheriting from above, if anything.

Work-Arounds 

In your local development environment, you may want the same named attribute in the child Web.Config but with a different value. But then ASP.NET complains because that name is already defined in the parent. You can then use the Remove and Clear tags to effectively override the parent entry. Remove effectively removes the named value so you can then redefine it with an Add tag. Clear will effectively clear all of the inherited entries in that section.

A quick fix could be to use the Remove tag so you can re-add the entry with the same name but different values.

      <connectionStrings>
         <remove name="MyDBConnString" … />
         <add name=”MyDBConnString" connectionString="Blah"  />
      </connectionStrings>

You can also use the Clear tag as well but this will effectively remove all inherited entries in that section.

       <connectionStrings>
         <clear /> 
      </connectionStrings>

Stop Inheritance Completely

If you would prefer to simply stop all inheritance and know that each Web.Config stands alone and contains everything it needs when you deploy, try this next suggestion. Adding this code to your root Web.Config should prevent any values from being propagated down to to other sites. This gives you the confidence that any individual site can by deployed to a server and the Web.Config will not be missing needed entries.

Use the <location> tag with an attribute of inheritInChildApplications equal to false in your root Web.Config file.

  <location path="." inheritInChildApplications="false">
    <system.web>
    ...
    </system.web>
  </location>

You can wrap a single section of your web.config file in <location> attribute or you could enclose the entire <system.web> as shown above. This will cause ASP.NET to not inherit settings from that section to child applications or folder web.config files.

Using Separate Web Sites and Host Headers

Another approach to by-passing Web.Config inheritance is to use completely separate Web Sites for each site. To differentiate each site, you have to give each site a different IP address or designate a unique Host Header value. Since you probably don't want to create separate IP's for each, using Host Headers is the easiest approach. This is added to the site inside IIS Manager. For example, I could then call a test site as http://mytestsite/ with mytestsite being the designated Host Header name for that site. You will probably need to edit your local HOSTS file and make sure that the Host Header names are added and point back to 127.0.0.1. Otherwise, the browser will think you are looking for this site on the internet and of course not find it. Perhaps I can go into more detail in a future post.

Sometimes you may want the text from a validation control to appear below a control such as a TextBox rather than next to it. So you might find yourself adding a <BR /> tag between the TextBox control and the Validation Control. However, you later realize that the <BR /> tag causes unwanted white-space or alignment issues even when the validation text is not displayed. If so, try adding the <BR /> tag to the beginning of the Validation Control text itself.

For example rather than….

       it might be better to use…

Notice that the <br /> tag has been moved to inside the ErrorMessage attribute text. This way the tag is emitted and effects formatting only when the error text is displayed. When using client-side validation, be sure to set Display="Dynamic", otherwise the text will be marked as hidden using CSS but the break tag will still be in effect in the HTML.