The following steps will help check the uniqueness of a user ID that is chosen by the user:

The core of the validation logic lies in the IsUsernameUnique method of the MockRespository class. The reason to place the logic in a different class rather than in the attribute itself was to decouple the attribute from the logic to be validated. It is also an attempt to make it future-proof. In other words, tomorrow, if we want to test the username against a list generated from an XML file, we don't have to modify the attribute. We will just change how IsUsernameUnique works and it will be reflected in the attribute. Also, creating a Plain Old CLR Object (POCO) to hold values entered by the user stops the validation logic code from directly accessing the source of input, that is, the Windows application.

Coming back to the IsUsernameUnique method, it makes use of the predicate feature provided by .NET. Predicate allows us to loop over a collection and find a particular item. Predicate can be a static function, a delegate, or a lambda. In our case it is a lambda.

bool exists = _users.Exists(u=>u.UserName==userName);

In the previous statement, .NET loops over _users and passes the current item to u. We then make use of the item held by u to check whether its username is equal to the username entered by the user. The Exists method returns true if the username is already present. However, we want to know whether the username is unique. So we flip the value returned by Exists in the return statement, as follows:

return !exists;

The following steps will help you create a custom validation attribute to meet your specific requirements:

To understand how UniqueUserValidator works, we have to understand how it is implemented and how it is used/called. Let's start with how it is implemented. It extends ValidationAttribute. The ValidationAttribute class is the base class for all the validation-related attributes provided by data annotations. So the declaration is as follows:

public class UniqueUserValidator:ValidationAttribute

This allowed us to make use of the public and protected methods/attribute arguments of ValidationAttribute as if it is a part of our attribute. Next, we have a property of type IRepository, which gets initialized to an instance of MockRepository. We have used the interface-based approach so that the attribute will only need a minor change if we decide to test the username against a database table or list generated from a file. In such a scenario, we will just change the following statement:

this.Repository = new MockRepository();

The previous statement will be changed to something such as the following:

this.Repository = new DBRepository();

Next, we overrode the IsValid method. This is the method that gets called when we use UniqueUserValidator. The parameter of the IsValid method is an object. So we have to typecast it to string and call the IsUniqueUsername method of the Repository property. That is what the following statements accomplish:

string valueToTest = Convert.ToString(value);
return this.Repository.IsUsernameUnique(valueToTest); 

Now let us see how we used the validator. We did it by decorating the UserName property of the User class:

[UniqueUserValidator(ErrorMessage="User name already exists")]
public string UserName {get; set;}

As I already mentioned, deriving from ValidatorAttribute helps us in using its properties as well. That's why we can use ErrorMessage even if we have not implemented it.

Next, we have to tell .NET to use the attribute to validate the username that has been set. That is done by the following statements in the OK button's Click handler in the Register class:

ValidationContext context = new ValidationContext(user, null, null);
//holds the validation errors
IList<ValidationResult> errors = new List<ValidationResult>();
if (!Validator.TryValidateObject(user, context, errors, true))

First, we instantiate an object of ValidationContext. Its main purpose is to set up the context in which validation will be performed. In our case the context is the User object. Next, we call the TryValidateObject method of the Validator class with the User object, the ValidationContext object, and a list to hold the errors. We also tell the method that we need to validate all properties of the User object by setting the last argument to true. That's how we invoke the validation routine provided by .NET.

The following steps will help you generate a localized validation message using XML:

Next let us see how to modify UniqueUserValidator so that it can localize the error message.

The Messages.xml file and the GetMessages method of XmlMessageRespository form the core of the logic to generate a locale-specific message. Message.xml contains the key to the message within the locale tag. We have created the locale tag using the two-letter ISO name of a locale. So, for English it is <en></en> and for French it is <fr></fr>.

Each locale tag contains a message tag. The key attribute of the tag will have the key that will tell us which message tag contains the error message. So our code will be as follows:

<message key="not_unique_user">User name is not unique</message>

not_unique_user is the key to the User is not unique error message. In the GetMessages method, we first load the XML file. Since the file has been set as an embedded resource, we read it as a resource. To do so, we first got the executing assembly, that is, CustomValidation. Then we called GetManifestResourceAsStream and passed the qualified name of the resource, which in this case is CustomValidation.Messages.xml. That is what we achieved in the following statement:

xDoc.Load(Assembly.GetExecutingAssembly().GetManifestResourceStream("CustomValidation.Messages.xml"));

Then we constructed an XPath to the message tag using the locale passed as the parameter. Using the XPath query/expression we got the following message nodes:

XmlNodeList resources = xDoc.SelectNodes("messages/"+locale+"/message");

After getting the node list, we looped over it to construct a dictionary. The value of the key attribute of the node became the key of the dictionary. And the value of the node became the corresponding value in the dictionary, as is evident from the following code:

SortedDictionary<string, string> dictionary = new SortedDictionary<string, string>();
foreach (XmlNode node in resources)
{
  dictionary.Add(node.Attributes["key"].Value, node.InnerText);
}

The dictionary was then returned by the method. Next, let's understand how this dictionary is used by UniqueUs rValidator.

The following steps will guide you as you generate locale-based custom messages:

The main change we did to the attribute is overriding the FormatErrorMessage method of ValidationAttribute. The validation framework / data annotation library calls the FormatErrorMessage method when it needs to output a message corresponding to a property. In short, by overriding it, we can provide a customized message.

To do so, we first need to find the two-letter ISO name of the current locale. Using the CurrentCulture property of CurrentThread, which is a static property of the Thread class, we can find the locale name. The following code did that and provided us with the two-letter ISO name of the current locale:

string locale = Thread.CurrentThread.CurrentCulture.TwoLetterISOLanguageName;    

Next, we passed the locale to the GetMessages method of IMessageRepository. From the returned dictionary, we found the message we wanted using the ErrorMessage property/named parameter and returned it. The value in ErrorMessageacted as the key:

return this.MessageRepo.GetMessages(locale)[this.ErrorMessage];

CustomValidationApp performs two roles. First of all, it makes use of the UserName property of the User class decorated with UniqueUserValidator to pass the key of the message we want, as shown:

[UniqueUserValidator(ErrorMessage = "not_unique_user")]
public string UserName { get; set; }

The value we passed to ErrorMessage acted as the key in FormatErrorMessage. The other role the application performs is to provide us with a test platform for testing locales, in this case, English and French. This was done by the following code in the SelectedIndexChanged event handler of cmbLocale in the Register class:

Thread.CurrentThread.CurrentCulture = new CultureInfo(cmbLocale.SelectedItem.ToString());

What we did in the preceding code is to set the current culture of the application to the culture selected in the locale combobox. When we set the CurrentCulture property of CurrentThred of the Thread class to a particular culture, the culture of the application is changed until the application is closed. Use this only for testing purposes.

As I mentioned earlier, a custom attribute is really a class that is inherited from System.Attribute. Our DefectTrackerAttribute class is no different. So, we inherit it from Attribute:

public class DefectTrackerAttribute:Attribute
{
}

Now, we have to pass information to the attribute. This can be done in two ways:

Using a constructor to pass the parameter is similar to what we do for classes. However, for the constructor parameters to be used as named parameters, we will need properties. So we added properties and the constructor:

public class DefectTrackerAttribute:Attribute
    {
        #region Public Properties
        public int DefectID {get;set;}
        public string ResolvedBy {get;set;}
        public string ResolvedOn {get;set;}
        public string Comments {get;set;}
        #endregion
        public DefectTrackerAttribute()
        {
        }
        public DefectTrackerAttribute(int defectID, string resolvedBy, string resolvedOn, string Comments = "")
        {
            this.DefectID = defectID;
            this.ResolvedBy = resolvedBy;
            this.ResolvedOn = resolvedOn;
            this.Comments = Comments;
        }
    }

The members of the class to which we can apply the attribute is the most important aspect of that attribute. To specify this, we can use the AttributeUsage attribute. Since we want to apply our attribute to classes, constructors, methods, fields, and properties, we specify it as follows:

  [AttributeUsage(AttributeTargets.Class |
    AttributeTargets.Constructor |
    AttributeTargets.Field |
    AttributeTargets.Method |
    AttributeTargets.Property,
    AllowMultiple = true)]
   public class DefectTrackerAttribute:Attribute
    {
        #region Public Properties
        public int DefectID {get;set;}
        public string ResolvedBy {get;set;}
        public string ResolvedOn {get;set;}
        public string Comments {get;set;}
        #endregion
        public DefectTrackerAttribute(int defectID, string resolvedBy, string resolvedOn, string Comments = "")
        {
            this.DefectID = defectID;
            this.ResolvedBy = resolvedBy;
            this.ResolvedOn = resolvedOn;
            this.Comments = Comments;
        }
    }

The AllowMultiple argument specifies whether the attribute can be used more than once on a class or its members. As the same member may be modified multiple times for different defects, we will be using our attribute multiple times on that member. Hence, we passed AllowMultiple as true. With that we come to the end of this recipe.

In DefectTrackerTest, we have just one class, CurrencyConverter. We tagged its constructor and ToRupee with DefectTrackerAttribute:

public CurrencyConverter(double value)
{
   _value = value;
}

[DefectTrackerAttribute(DefectID = 1042, ResolvedBy = "AP", ResolvedOn = "2012/02/11")]public double ToRupee()
{
            return _value * 50;
}

In the next recipe we will see how to create a processor for our attribute and how to use them both.

That completes the steps for creating a processor for the custom attribute and using it. Next, let us dive more into the code to understand what is happening.

The core of the DefectTrackerProcessor class is the GetDetails method that uses reflection to find out whether the class whose name has been sent as the parameter contains DefectTrackerAttribute. The first step is to load the assembly containing the class using the LoadFrom static method of the Assembly class. The next step is to retrieve the class from the assembly and set it to the Type class variable. These two steps are achieved in the following statements:

Assembly assembly = Assembly.LoadFrom(assemblyPath);
Type type = assembly.GetType(className, true, true); 

The Type class is the root of the functionality provided by .NET for reflection. It is the entry point to gain details regarding the members of a class or structure. In the preceding code, the GetType method looks into the assembly and returns the Type instance containing details of the class whose name has been passed via the className variable. The second parameter of GetType is set to true so that, if the class is not found, an exception is thrown and we can know that something is wrong. We want to find the class regardless of whether the class name is passed in upper- or lowercase. Hence, the last parameter is set to true to tell GetType to ignore the case of the class name.

Now that we have the Type instance containing the details of the class, we can check whether the members of the class are decorated with DefectTrackerAttribute or not. The first class member that we check is the constructor. The following statement provides the details of the constructors within a class:

//check whether the constructors have the custom attribute
ConstructorInfo[] constructorInfo = type.GetConstructors();

The GetConstructors method of Type returns an array of ConstructorInfo. Each instance of ConstructorInfo in the array contains details such as the name and attributes decorating that constructor, for each constructor of the class that Type represents. Next, we iterate through the array and get the list for DefectTrackerAttribute for the current constructor as shown in the following statements:

foreach (var item in constructorInfo)
{
 IEnumerable<DefectTrackerAttribute> attributes = 
                   item.GetCustomAttributes<DefectTrackerAttribute>();
 details.Append(GetMemberDetails(item.Name, attributes));
}

Then, we passed the list to the GetMemberDetails method along with the name. In the GetMemberDetails method, we iterate over the list to get the defect details using the properties of DefectTrackerAttribute as shown:

foreach (var attribute in attributes)
{
  sb.Append("ID-");
  sb.Append(attribute.DefectID);
  sb.Append("\t");
  sb.Append("Resolved By-");
  sb.Append(attribute.ResolvedBy);
  sb.Append("\t");
  sb.Append("Resolved On-");
  sb.Append(attribute.ResolvedOn);
               
}

Similar to the constructor, we can get details of methods tagged with DefectTrackerAttribute using the GetMethodInfo method of the Type class. That is what we have done in the following statements:

//check whether the methods have custom attribute
MethodInfo[] methodInfo = type.GetMethods();

foreach (var item in methodInfo)
{
  IEnumerable<DefectTrackerAttribute> attributes = 
             item.GetCustomAttributes<DefectTrackerAttribute>()
  if (attributes.Count() > 0)
  {
       details.Append(GetMemberDetails(item.Name, attributes));
  }
}

The MethodInfo class contains the details of a method of the class represented by Type. The array returned by GetMethods() contains details of all the methods within the class. We iterated over the array and determined whether the method is tagged with the attribute or not. If it is tagged, that is, the attribute list contains one or more elements, we fetched the details, just like we did for the constructor(s). Once we got the details of the constructor and the methods, we returned the details as a string value.

In the TrackDefect class of DefectTrackerApp, we called the instantiated DefectTrackerProcessor and called the GetDetails method with the assembly path and the class name that was entered via the UI. This is done in the Click event handler of the Load button.

private void btnLoad_Click(object sender, EventArgs e)
{
if (!String.IsNullOrEmpty(txtPath.Text) && 
             !String.IsNullOrEmpty(txtClassName.Text))
 {
   txtDetails.Text = new DefectTrackerProcessor().GetDetails(txtPath.Text, txtClassName.Text);
 }
}

We saw how Type helps us to get details of constructors and methods of a class. Similarly, we can get details of the properties of a class using the GetProperties method. It returns an array of PropertyInfo. Each PropertyInfo holds the details of a specific property of the class. If you want details of only a specific property, call the GetProperty() method and pass the property name as argument.

The following steps will help you perform directory-to-directory copy using asynchronous file I/O:

That completes the steps to create directory-to-directory copy functionality, which does the copying asynchronously.

The whole logic of asynchronous copy is implemented within one method: the CopyDirectoryAsync method of the Utils class. As you have already seen, both the class and the method are public as well as static. The reason for making the method static is that we have implemented it as a utility method. Utility methods are always implemented as public and static methods. In .NET itself, all the methods of the Math class are static methods, and the class itself is static.

Now let us look at how the logic works. If you observe the signature of the method, there are two things that make it different from other methods (or synchronous methods).

public static async Task<int> CopyDirectoryAsync(string sourceDir, string targetDir)

First is the async keyword. It means that somewhere in the method an asynchronous task is going to be executed. Next is the return type. If you want to return any value from a method that has async in its signature, you will have to do it using the Task object. In our case, we wanted to return the number of files copied. So we have used Task<int> as our return type.

As we wanted to return the number of files copied, we will have to know the current number of files in the target directory. With the following statement we can achieve this:

int count = Directory.EnumerateFiles(targetDir).Count();

In the preceding statement, we have used the EnumerateFiles method of the Directory class to get a list of all the filenames within the target directory and then got the number of elements in that list. Next, we have to get the files we want to copy. For that, we iterate over the filenames returned by Directory.EnumerateFiles. To EnumerateFiles, we passed the path of the source directory as shown:

 foreach (string filename in Directory.EnumerateFiles(sourceDir))
{
}

Then, we open each file for reading as a stream:

foreach (string filename in Directory.EnumerateFiles(sourceDir))
{
  using (FileStream sourceStream = File.Open(filename, FileMode.Open))
  {
  }
}

Once we have opened the file to be copied, we have to open another stream to the location where the file will be copied. To do that we created a file of the same name and then connected a new stream to it, as shown in the following highlighted code:

foreach (string filename in Directory.EnumerateFiles(sourceDir))
{
  using (FileStream sourceStream = File.Open(filename, FileMode.Open))
  {
   using (FileStream DestinationStream = File.Create(targetDir + 
                 filename.Substring(filename.LastIndexOf('\\'))))
    {
    }

  }
}

Now comes the most important part of our code, the statement that makes asynchronous copy work. Once we open a stream to a file in the destination directory, we can transfer the contents. To do so, we used the CopyToAsync method of the FileStream class. However, what makes the content transfer statement important is the await keyword before it, as in:

await sourceStream.CopyToAsync(DestinationStream);

The await keyword in the preceding statement tells the framework that the execution of this method is suspended until the CopyToAsync method is done. Apart from that, the await keyword also tells the framework to return the control of the execution to the code that called this method, that is, CopyDirectoryAsync. In other words, until the current file is copied, the application can resume its normal operation and would not appear to the user as if the application is frozen.

In our case, the FileUtils class calls the CopyDirectoryAsync method when Copy is clicked. When the execution reaches the await statement, the control is returned back to the FileUtils class until the current file, as per the loop, is copied. Till the file is copied, the user can make use of any feature of the application. Once the file is copied, the file in the source directory is opened and the process continues. If the size of the files are huge, say 500 MB, you will be able to see the effect of the asynchronous transfer.

The following steps will help you access JSON using dynamic programming:

The core work of accessing JSON happens in the event handler for the Parse button. We had assigned a string containing JSON. The data within the JSON string is about a particular order. The product contained in the order and the type of delivery is as shown:

{
    'order':{
             'name':'testOrder',
              'value':'1000',
              'products':[
                          {'name': 'testProduct',
                           'expiry': '12 months'
                           }]
              },
     'delivery':'at home'
 }

In the JSON above, delivery is a normal data element. However, the name of a product is a complex data element since name is a part of the products array (note the square bracket), which itself is part of order element. For data of this type, if we go for the traditional approach to access the values, we will have to either create multiple classes or perform complex string manipulations. That is where having dynamic helps.

In the event handler for the Parse button, we first parsed the JSON using JavaScriptSerializer as shown:

var serializer = new JavaScriptSerializer();
var dictionary = serializer.Deserialize<Dictionary<string, 
                                        dynamic>>(txtJson.Text);

The JSON data is deserialized or parsed into a dictionary having a string value as key and a dynamic object as value. If we look at the dictionary as a table of Key and Value, it will look something like the following:

{
        'name':'testOrder',
         'value':'1000',
           'products':[
                      {'name': 'testProduct',
                         'expiry': '12 months'
                         }]
   }

From the preceding table it is clear that the value for delivery is at home. So the following statement is nothing special, just a simple way of getting the value via the key:

lblValue.Text = dictionary["delivery"];

However, if we have to find the name of the product, simply using the key won't work. If we pass the order as the key, we will get a complete piece of complex JSON data. However, this data is of type dynamic. So, if we write statements like the ones written as follows, the compiler won't complain, and will leave it to the runtime check to assign the values:

dynamic order = dictionary["order"];
dynamic products = order["products"];
dynamic product = products[0];
dynamic name = product["name"];

The first statement assigns the value of the order to the order variable. The order variable will now contain an array of products. The first element of the product array is assigned to the product variable. Then, from the product variable, the name key is used to access the product name. On combining all four steps, we get:

lblComplexValue.Text = dictionary["order"]["products"][0]["name"];

So, by using dynamic programming, we were able to access the parsed JSON data without having to create the class hierarchies and without having to use string manipulation.