I mentioned that v1.1 of ASP.NET by default validates input received from QueryString, Form and Cookie scope. You can turn off this validation site wide by tweaking the web.config:

<configuration>
  <system.web>
    <pages validateRequest=”false” />
  </system.web>
</configuration>

But then you’re left with no validation right? Wrong. You can use the ValidateInput() method of the HttpRequest object programmatically in any code that has access to the HttpRequest instance. Very useful stuff.

One question though: What is potentially dangerous data according to Microsoft? And can you modify that definition? I’m guessing the answers are: a) we’ll never know and b) no. Given their track record, does it make sense to trust Microsoft to validate the input you receive from client browsers when the browser they created can’t be trusted?

I’m sure this is boring for about 99% of you, but I’m writing for my own benefit anyway. I mentioned the ‘out method parameter’ yesterday because I saw it used in a custom library I’m using and then today I found out that the Double class uses it as well. I think it’s a great example of how it should be used. It’s used in the TryParse method:

public static bool TryParse(
   string s,
   NumberStyles style,
   IFormatProvider provider,
   out double result
);

“The TryParse method is like the Parse method, except this method does not throw an exception if the conversion fails. If the conversion succeeds, the return value is true and the result parameter is set to the outcome of the conversion. If the conversion fails, the return value is false and the result parameter is set to zero.”

I like it because throwing an exception (ie: what the Parse() method does) violates rule #39 of Effective Java Programming which says to “… Use exceptions only for exceptional conditions.” Using an out parameter feels cleaner and simpler. Anyone else think so?

Just discovered this C# tidbit called the out method parameter. Let’s say you have a method:

public String ReplaceAll(String toReplace, String replaceWith)

and you want to know how many replacements were actually made. With a regular method you can only return the modified string. The out method parameter gives you the ability to return another variable. The modified method would look like this:

public String ReplaceAll(String toReplace, String replaceWith, out int numReplaced)

and then concretely:

String myString = “aaron”;
int replaced;
myString.ReplaceAll(“a”, “k”, out replaced);
Console.WriteLine(“The method ReplaceAll() replaced ” + replaced + ” characters.”);

Similar idea in the ref method parameter, but you have to initialize the variable before sending it to the method.

Last March I wrote about how handy it is that ASP.NET enables you to add your own custom settings to the web.config file using syntax like this:

<appSettings>
<add key=”connString” value=”user id=sa;password=mypassword;” />
</appSettings>

This is nice, but can quickly get unwieldy if you have alot application settings to maintain. Back in March I failed to mentioned (because I didn’t know about it) that you can extend your web.config even further by creating your own custom configuration sections. You can read more about the ConfigurationSettingsSchema on msdn, but here’s a quick example. First you define the custom application settings:

<configSections>
   <sectionGroup name=”myapplication”>
      <section name=”types” type=”System.Configuration.NameValueSectionHandler”/>
      <section name=”security” type=”System.Configuration.NameValueSectionHandler”/>
    </sectionGroup>
</configSections>

and then you add the actual settings:

<myapplication>
   <types>
      <add key=”section” value=”com.ignitionlabs.Section” />
      <add key=”template” value=”com.ignitionlabs.Template” />
   </types>
   <security>
      <add key=”/controlpanel/” value=”Systems Administrators,Project Managers” />
      <add key=”/members/” value=”members” />   
   </security>
</myapplication>

Finally, you can use the exact same XPATH syntax that you use when retrieving other application settings. In the above example, there are multiple ‘type’ elements, so I’d first get a NameValueCollection object:

NameValueCollection config = (NameValueCollection)System.Configuration.ConfigurationSettings.GetConfig(“myapplication/types”);

and then retrieve the value of the “section” key using the name:

string section = config[“section”];

Enjoy!