General

EntLib Validation Application Block - Subclassing PropertyProxyValidator for ValueConvert

Steve Michelotti — Mon, 16 Jun 2008 19:19:57 GMT

The Enterprise Library VAB provides the PropertyProxyValidator for ASP.NET applications so that you can attach it to a single control and it will display any validation messages for that business object property. This automatic UI validation is great because it avoids duplicating your business layer validation logic in your UI. Additionally, you can just use ONE validator control whereas using traditional ASP.NET validation controls you might need to attach 3-4 validation controls to a single UI element (e.g., RequireFieldValidator, RangeValidator, RegexValidator, etc.) which can clutter your aspx pages quickly.

However, one of the gotchas with working with the PropertyProxyValidator control is that, while it is quite elegant for strings, you have to do a little extra work for data types such as DateTime. Specifically, if you are working with a DateTime, you have to attach a ValueConvert method to your PropertyProxyValidator control in which you perform the data type conversion. The following code snippet is directly out of the VAB documentation:

   1:  protected void dateOfBirthValidator_ValueConvert(object sender, ValueConvertEventArgs e)

   2:  {

   3:          string value = e.ValueToConvert as string;

   4:          try

   5:          {

   6:              e.ConvertedValue = DateTime.Parse(value, System.Globalization.CultureInfo.CurrentCulture);

   7:          }

   8:          catch

   9:          {

  10:              e.ConversionErrorMessage = "Date Of Birth is not in the correct format.";

  11:              e.ConvertedValue = null;

  12:          }

  13:  }

This extensibility is great but if I need to perform multiple DateTime validations like this throughout my application, I don't want to have to copy/paste this code everywhere. Even if I encapsulate it in a static utility method, I still have to go through the pain of wiring up an event for any control where I need this just to make that 1-line call to the utility method.

So...a better approach is to simply subclass the PropertyProxyValidator control. In the following example, I just wire up the conversion in the contructor. This enables me to avoid having to wire up the event in the aspx code and and also enables me to avoid having to include the event in the code behind. I just specify the DateTimePropertyProxyValidator in my aspx code the normal way:

   1:  <asp:TextBox id="txtDateOfBirth" runat="server" />

   2:  <vab:DateTimePropertyProxyValidator ID="dobVal" runat="server" ControlToValidate="txtDateOfBirth" PropertyName="DateOfBirth" SourceTypeName="Person"/>

The same pattern could obviously be used for other data types. Below is the complete code for the DateTimePropertyProxyValidator:

   1:  public class DateTimePropertyProxyValidator : PropertyProxyValidator

   2:  {

   3:      public DateTimePropertyProxyValidator()

   4:      {

   5:          this.ValueConvert += OnValueConvert;

   6:      }

7:

   8:      private void OnValueConvert(object sender, ValueConvertEventArgs e)

   9:      {

  10:          DateTime result;

11:

  12:          if (DateTime.TryParse((string)e.ValueToConvert, out result))

  13:          {

  14:              e.ConvertedValue = result;

  15:          }

  16:          else

  17:          {

  18:              e.ConversionErrorMessage = "Date is not in the correct format.";

  19:              e.ConvertedValue = null;

  20:          }

  21:      }

  22:  }

EntLib Validation Application Block - Required String Validator

Steve Michelotti — Fri, 13 Jun 2008 03:23:24 GMT

In a previous post I discussed validating strings with the VAB in the context of ASP.NET applications. In summary, you must have a NotNullValidator and also a StringLengthValidator that prevents a string length of zero on the lower bound and prevents a string length above your upper bound (e.g., 50 characters). That attribute might look like this:

   1:  [StringLengthValidator(1, 50, MessageTemplate="First Name must be 1-50 characters.")]

But the problem is that the StringLengthValidator is really doing 2 jobs - one to check if the user entered a value and another to check the upper bound. Although including the NotNullValidator complete and correct, it doesn't do much in the context of asp.net applications which default to an empty string.

So from a user perspective, it would be nice to have one message if the user leaves it blank and another message if they've exceed the upper bound (or didn't follow an appropriate Regex pattern, etc., etc.). In other words, it would be nice to have a RequiredStringValidator so we could write our business object like this (notice we no longer have to care about the lower bound on the string length validator):

   1:  public class Person

   2:  {

   3:      [RequiredStringValidator(MessageTemplate = "First Name is required.")]

   4:      [StringLengthValidator(50, MessageTemplate = "First Name must be less than 50 characters.")]

   5:      public string FirstName { get; set; }

   6:  }

Also, specifiying a MessageTemplate on the RequiredStringValidator is optional.

So creating your own custom validator to do this is actually quite easy. The complete implementation follows:

   1:  public class RequiredStringValidatorAttribute : ValueValidatorAttribute

   2:  {

   3:      protected override Validator DoCreateValidator(Type targetType)

   4:      {

   5:          return new RequiredStringValidator(this.MessageTemplate, this.Negated);

   6:      }

   7:  }

8:

   9:  public class RequiredStringValidator : ValueValidator<string>

  10:  {

  11:      public RequiredStringValidator(string messageTemplate, bool negated) : base(messageTemplate, null, negated)

  12:      {

  13:      }

14:

  15:      protected override void DoValidate(string objectToValidate, object currentTarget, string key, ValidationResults validationResults)

  16:      {

  17:          if (string.IsNullOrEmpty(objectToValidate) != Negated)

  18:          {

  19:              LogValidationResult(validationResults, GetMessage(objectToValidate, key), currentTarget, key);

  20:          }

  21:      }

22:

  23:      protected override string DefaultNegatedMessageTemplate

  24:      {

  25:          get

  26:          {

  27:              return "Field cannot have a value.";

  28:          }

  29:      }

30:

  31:      protected override string DefaultNonNegatedMessageTemplate

  32:      {

  33:          get

  34:          {

  35:              return "Field is required.";

  36:          }

  37:      }

  38:  }

I've supported Negations for completeness but I can't really think of a real-world example where you'd want to use it in this context.

So overall, the RequiredStringValidator check for both null and empty string. Thus, you don't have to feel like you're kludging the StringLengthValidator into doing two different jobs.

EntLib Validation Application Block - Validate a string in ASP.NET

Steve Michelotti — Wed, 11 Jun 2008 01:27:42 GMT

You've created a class like this and all your unit tests pass just fine when you check for null strings or strings greater than 50 characters:

   1:  public class Person

   2:  {

   3:      [NotNullValidator(MessageTemplate="First Name is required.")]

   4:      [StringLengthValidator(50, MessageTemplate="First Name must be 1-50 characters.")]

   5:      public string FirstName { get; set; }

   6:  }

But then when you run it in an ASP.NET application with the PropertyProxyValidator validation control provided by VAB, your business object suddenly shows as valid even though the user left the text box blank.

   1:  <asp:TextBox ID="txtFirstName" runat="server" />

   2:  <vab:PropertyProxyValidator id="firstNameVal" runat="server" ControlToValidate="txtFirstName"

                                   PropertyName="FirstName" SourceTypeName="WebApplication1.Person"/>

Why is this happening? The reason is because the ASP.NET infrasture will put an empty string (i.e., a zero-length string) in that property rather than a null. In point of fact, the validator was not set up correctly to begin with. The intent is also to prevent an empty string. So to correct the implementation of the StringLengthValidator, you must give the lower bound of 1 as the first argument as shown here:

   1:  [StringLengthValidator(1, 50, MessageTemplate="First Name must be 1-50 characters.")]

Additionally, the VAB will allow you to specify whether you want the number specified for the lower/upper bound to be considered inclusvie/exclusive for the range.

BizTalk Web Service - SoapException: Internal SOAP Processing Failure

Steve Michelotti — Fri, 24 Nov 2006 00:07:00 GMT

When exposing a BizTalk orchestration as a web service, I ran into a basic problem that was not obvious to me at first. When try to invoke the web service I got the exception: "SoapException: Internal SOAP Processing Failure". The basic BizTalk help offered no insight into this problem. The answer can be found on MSDN however. According to MSDN:

Check the identity under which the application pool is running. Is it a member of the IIS_WPG and BizTalk Isolated Host Users groups? These two groups give the ASMX page (the proxy Web service that the BizTalk Web Service Publishing wizard generated) the appropriate rights to insert the SOAP request message into the BizTalk MessageBox in SQL Server that will then launch the orchestration. Symptom may be "SoapException: Internal SOAP Processing Failure".

This fixed the problem for me.

Consolas Font for Visual Studio 2005

Steve Michelotti — Tue, 27 Jun 2006 21:30:00 GMT

At Tech Ed this year, the presenter at one of the Windows Presentation Foundation talks was raving about the new Consolas ClearType font was was recently developed for Visual Studio 2005. I have downloaded it and I must say it is the best fixed width developer font I have ever seen. Here is an example screen shot (although my screen shot really does not do it justice):

You can download the font for free here:

http://www.microsoft.com/downloads/details.aspx?familyid=22e69ae4-7e40-4807-8a86-b3d36fab68d3&displaylang=en

You have to make sure that your system has ClearType is turned on. The first question (”How do I turn it on?”) at this link will show you how:

http://www.microsoft.com/typography/ClearTypeFAQ.mspx

SuppressMessage with FxCop and NON-Team System Visual Studio

Steve Michelotti — Wed, 11 Jan 2006 18:40:00 GMT

If you're using Visual Studio 2005 Team System then FxCop is completely integrated and when you exclude messages it automatically applies the new SuppressMessage attributes to the appropriate location in code. But if you're using Visual Studio Professional edition then you have to use the external FxCop 1.35 UI. If this is the case, you can STILL utilize the SuppressMessage attribute but have to do a couple of things first. I had to do a little digging but the steps are pretty simple.

It turns out you have to enable your project to recognize the SuppressMessage attribute by FIRST adding a condition compilation symbol.

To include this symbol do the following:
C#
1. In Solution Explorer, right-click your project and choose Properties
2. In the Properties window, choose the Build tab
3. In the Conditional compilation symbols text box enter CODE_ANALYSIS

VB
1. In Solution Explorer, right-click your project and choose Properties
2. In the Properties window, choose the Compile tab and click Advanced Compile Options
3. In the Custom constants text box enter CODE_ANALYSIS
Found these steps here:

Now for the cool part. In Team System, you can just right-click on the rule and say “Suppress” and it will automatically add the SuppressMessage attribute in the right spot. In Professional edition, we don’t have this integrated into the IDE so we have to use the normal FxCop 1.35 UI (which of course has no knowledge of Visual Studio) – and correctly specifying these attributes is not easy to do by hand. It turns out all you have to do, is to right-click the error message in FxCop UI and select “Copy As” – “SuppressMessage” (or “Module-level SupressMessage”). Then you can simply paste the attribute into your code at the appropriate location. Very slick!

Not all string comparisons created equal

Steve Michelotti — Sun, 11 Dec 2005 15:03:00 GMT

Not all string comparisons will perform the same but I was interested in seeing what exactly the differences were. Regardless of whether I was just performing 1 string comparison or 1 million, using the instance Equals() method was BY FAR the fastest. Of course the danger there is it will fail if the first string is null. Using == will always work regardless of nulls and for a million comparisons was almost as fast as Equals() and WAY faster than any other method (although it should be noted that using == is identical to using the static String.Equals() method). However, for 1 comparison it was by far the slowest. Note, for case-insensitive comparisons it is much faster to use the Compare() method with the case insensitive switch. Here are results below:

1 COMPARISON:
first == second                                                 : 0.00021175875704873100
first.Equals(second)                                          : 0.00000866031856004045
(first.CompareTo(second) == -1)                     : 0.00005531429273832290
(string.Compare(first, second) == -1)                : 0.00001396825574200070
string.Compare(first, second, true) == -1          : 0.00001145396970844060
first.ToLower() == second.ToLower()              : 0.00002458413010592130

1000000 COMPARISONS:
first == second                                                 : 0.05631637540525400000
first.Equals(second)                                          : 0.03321874707539650000
(first.CompareTo(second) == -1)                     : 0.28999719238059600000
(string.Compare(first, second) == -1)                : 0.29059363690077900000
string.Compare(first, second, true) == -1          : 0.30738375966777900000
first.ToLower() == second.ToLower()              : 0.77666714624344700000

Incidentally, a look at the instance Equals() method in Reflector:
[MethodImpl(MethodImplOptions.InternalCall)]
public extern bool Equals(string value);

Doing a million string comparisons in a loop might not be your common every day programming task and the timing difference will obviously not be perceptible to a human. But let's say you have a web page that does a single string comparison - if that page is accessed in a high volume environment (by thousands of browsers at once), then every little performance enhancement you can make is quite important.