Added StyleCop and fixed braking styles.

First of all, StyleCop is not FxCop. I always like to precise this as people tend to make confusion. StyleCop enforces rules about the coding style and is used to maintain coding style uniform across projects and between developers.
I have chosen to add the StyleCop as a NuGet package dependency. This has several advantages. First of all, upgrade to the newer versions is trivial, and adding new projects is way more straight forward. With the package I have chosen are shipped all the necessary tools to run StyleCop, both local and on build server, with no need to install any additional tool on developers PC or the build server. Package contains StyleCop dlls, a GUI app that allows us to modify the rules, and other configuration files. Once the package is added, your project file will also be modified. You will find a pointer to .Targets file which is the essential piece in this game. It contains the necessary configuration in order to put the StyleCop analyzes in place.
This is a good start, still we need some fine tuning. However, right away you can compile you project/s and you will be able to notice the big amount of warning starting wit SA. Now this means that we are breaking several StyleCop rules? Wait a minute, what rules, I haven't chose anything! Well that's right, however once added all the rules are considered valid or active. If the default set of rules doesn't fit your coding guideline or you do not share the same opinion about certain rules with the guys who created StyleCop, you will need to disable this rules. We will disable rules per solution as we do want all of our projects to use the same rules so that we can have consistent style across all our projects. In order to do so, on the project level we will add a configuration file in our solution root. A template for this file can be found in the packages tolls file. All we need is to copy that file from the original path to the root of our solution. Once added, link it in your solution from Visual Studio by adding an existing file to our " Solution Items" solution folder.
Before we start changing the rules we need to explain to StyleCop that this is the file that should be used as the valid settings file. This operation is done locally from the every single project on which StyleCop is enabled. Add in the root folder of your project a file called Settings.StyleCop and add the following in it. The important thing is that StringProperty LinkedSettingsFile is pointing to the setting files in our solution root. Once this is done for every project we enabled Style Cop on we can start modifying the rules.
In order to modify the rules, open the command prompt and position yourself inside the packages directory of your project, more precisely in StyleCop.MSBuild.4.7.49.0\tools folder. Now execute the settings editor passing as the parameter the lionk to your settings file. In my case the command will look like this, StyleCopSettingsEditor "C:\Users\MaiO\Code\dache\Settings.StyleCop". This will open the editor, you can track the rules easly by theire description. Each rule name in your warnings do start wit the code that identifies that rule in the unique way. Right after the code there is the group name of which that rule is part of. This will help you to locate the rule in the editor. Once found the rule you do not want to be applied on your project, deselect it and click apply. If you now recompile your project, no more warnings for that rule should be visible.
At a certain point you will notice SA1650: CSharp.Documentation warning appearing. This is used to indicate an incorrectly spelled word. A dictionary that you can find in the packages folder is use to perform spell checking. In case a ward that is valid is not recognized, you can add the exception in your solution level Settings.StyleCop file. The only thing you will need to do is add the following to that file and then list all of your words one by one inside of value elements. The same thing is achievable also through settings editor, however it is I think quicker to directly modify the settings file. Still, if the editor is opened, do not modify the underlying file, as any further change in the editor will make you lose the manually edited file changes.
This should be enough to start using it. There is still one option that I will not activate at this point. It is about treating the warnings as errors. Braking StyleCop rules will prevent to have a successful build.