People who knows me also knows that I'm a big fan of static analysis tools. Thanks to Patrick Smacchia I had the chance to test NDepend, probably the most complete tool for static code analysis. It is not worthy to enumerate all the features the tool offers, because the documentation and the web site already do a wonderful job with it. Just to mention some of them with NDepend you will be able to measure up to 82 predefined metrics to manage things like coupling, instability, abstractness, dependencies, naming conventions ...

Aside all the different, some of them unique, metrics the tool incorporates there are many features that make of NDepend a great tool like:

• Possibility to incorporate new custom rules or modify the existing ones via the Code Query Language, a language with a syntax similar to any SQL language that allows you writing queries against your code structure. CQL makes so easy to create custom rules that there is no fair comparison with FxCop or StyleCop.
• Possibility to introduce CQL constraints in the code that will allow you building really creative rules embedded in your code.
• MSBuild and NAnt tasks to integrate with your TFS or CruiseControl.
• Integration with Visual Studio and Reflector.
• Different graphs that allow you seeing your code in a visual manner.

It is also remarkable the job Patrick has done by creating several demos on how to perform different operations with NDepend to take more profit of it. You can find them online, together with the description of the different metrics and links to technical articles to his blog. It is just pity that you cannot link easier to it from the tool itself. It would be fantastic if in next versions you could just right click in the failing rule and provide an option to reach the help.

Regardless I think the tool is great I must say that I didn't like some of the naming conventions rules do not follow the guidelines provided by MSDN and one of the greatest books about the subject: Framework Design Guidelines. I also found some of the metrics a little bit arbitrary, like code should have more than 20% of comments, I completely understand you need to put a value to break a rule, but I would love to see more detailed information on how he arrived to the conclusion that some rules should have a specific value instead of another one. Of course, this is part of his .NET knowledge and programming experience. Anyway, this shouldn't be a limitation because if for any reason you do not agree with a rule, just modify it, disable it ... you can do it if you have good reasons for it!!

I like to see the tool not only as a bunch of rules, but as the infrastructure that will allow to build and manage your corporate standards.

I want to finish the post saying that I like NDepend, I think this is one of the must-have developer tools, so if you haven't tried yet go the website and get an evaluation copy to check it.

These days I've been updating the CA settings on some old projects, I wanted to modify the configuration of certain rules that were removed with the shipping of Visual Studio 2008. You can obtain detailed information about what rules are shipped with each version of CA in this post of the FxCop blog.

As you can see in the post, some of the rules were removed because they do not apply anymore or because they were too noisy compared with the benefit introduced. One of the rules that make feel more upset when I knew it was removed was "CA1818 - Do not concatenate strings inside loops". This rule threw an error (I will continue in my imaginary world where everybody sets warnings as errors in production code) with code like:

   1:  string s = string.Empty;

   2:  for (int i = 0; i < 5; i++)

   3:  {

   4:      s += i.ToString();

   5:  }

One of the first things you learn in .NET is about the immutability of the strings, you can find lot of literature talking about how to handle properly strings. Even Improving .NET Application Performance and Scalability, one of the best papers I've seen about .NET performance, makes an explicit reference to do not concatenate strings when the number of concatenations is unknown.

So, today that I've been working again with the rule, I had the curiosity (hope) to verify the rule was not removed because it was too noisy but because the CLR was improved to avoid the issue. I know this is again living in my imaginary world, but I'm a bit stubborn...what I've done is to compile a console project with the code above with 2.0 (VS 2005) and 3.5 (VS 2008), first one fires the error, second one doesn't. First step has been to look for differences in the IL generated, both cases have:

   1:  .entrypoint

   2:  // Code size       39 (0x27)

   3:  .maxstack  2

   4:  .locals init ([0] string s,

   5:         [1] int32 i)

   6:  IL_0000:  ldsfld   string [mscorlib]System.String::Empty

   7:  IL_0005:  stloc.0

   8:  IL_0006:  ldc.i4.0

   9:  IL_0007:  stloc.1

  10:  IL_0008:  br.s     IL_001c

  11:  IL_000a:  ldloc.0

  12:  IL_000b:  ldloca.s i

  13:  IL_000d:  call     instance string 

  14:                     [mscorlib]System.Int32::ToString()

  15:  IL_0012:  call     string [mscorlib]System.String::Concat(string,

  16:                                                            string)

  17:  IL_0017:  stloc.0

  18:  IL_0018:  ldloc.1

  19:  IL_0019:  ldc.i4.1

  20:  IL_001a:  add

  21:  IL_001b:  stloc.1

  22:  IL_001c:  ldloc.1

  23:  IL_001d:  ldc.i4.5

  24:  IL_001e:  blt.s    IL_000a

  25:  IL_0020:  call     valuetype [mscorlib]System.ConsoleKeyInfo 

  26:                     [mscorlib]System.Console::ReadKey()

  27:  IL_0025:  pop

  28:  IL_0026:  ret

No improvements on the compiler side. Next step has been to verify the native code generated, for that I used the command !u at WinDbg (in this previous post you can see how to obtain the native code after the method is jitted). The code for both projects looks like (note that some memory addresses will be different):

   1:  CA1818.Program.Main(System.String[])

   2:  Begin 009d0070, size 55

   3:  009d0070 55           push ebp

   4:  009d0071 8bec         mov  ebp,esp

   5:  009d0073 57           push edi

   6:  009d0074 56           push esi

   7:  009d0075 83ec10       sub  esp,10h

   8:  009d0078 33c0         xor  eax,eax

   9:  009d007a 8945f4       mov  dword ptr [ebp-0Ch],eax

  10:  009d007d 8b3d2c10d602 mov  edi,dword ptr ds:[2D6102Ch] ("")

  11:  009d0083 33d2         xor  edx,edx

  12:  009d0085 8955f4       mov  dword ptr [ebp-0Ch],edx

  13:  009d0088 837df405     cmp  dword ptr [ebp-0Ch],5

  14:  009d008c 7d26         jge  009d00b4

  15:  009d008e 8b75f4       mov  esi,dword ptr [ebp-0Ch]

  16:  009d0091 e80a0cca6f   call mscorlib_ni+0x220ca0 (70670ca0) 

  17:  009d0096 50           push eax

  18:  009d0097 8bce         mov  ecx,esi

  19:  009d0099 33d2         xor  edx,edx

  20:  009d009b e8bad00971   call 

  21:                        mscorwks!LogHelp_TerminateOnAssert+0xb82 

  22:                        (71a6d15a) 

  23:  009d00a0 8bd0         mov  edx,eax

  24:  009d00a2 8bcf         mov  ecx,edi

  25:  009d00a4 e8a7ebc36f   call mscorlib_ni+0x1bec50 (7060ec50)

  26:  009d00a9 8bf8         mov  edi,eax

  27:  009d00ab ff45f4       inc  dword ptr [ebp-0Ch]

  28:  009d00ae 837df405     cmp  dword ptr [ebp-0Ch],5

  29:  009d00b2 7cda         jl   009d008e

  30:  009d00b4 8d4de8       lea  ecx,[ebp-18h]

  31:  009d00b7 33d2         xor  edx,edx

  32:  009d00b9 e8f6381570   call mscorlib_ni+0x6d39b4 (70b239b4)

  33:  009d00be 8d65f8       lea  esp,[ebp-8]

  34:  009d00c1 5e           pop  esi

  35:  009d00c2 5f           pop  edi

  36:  009d00c3 5d           pop  ebp

  37:  009d00c4 c3           ret

We see there are no improvements either on the jitter side. The next to verify is if the strings are being discarded on each iteration creating a new one or not. To do that I used some good profilers that are on the market but in the end I decided to show how I did it with WinDbg because anybody can download it for free.

With !DumpHeap -type System.String we can see all the string instances of our application. This returns a list with the memory address of the string instances, to view the contents of the object we just need to do a !do (dump object) of the address we want to check. So, just taking some samples from the instances with higher memory addresses we can already see the next:

   1:  0:003> !do 01c83ae0 

   2:  Name: System.String

   3:  MethodTable: 706c0a00

   4:  EEClass: 7047d64c

   5:  Size: 24(0x18) bytes

   6:  String: 012

   7:   

   8:  0:003> !do 01c83af8 

   9:  Name: System.String

  10:  MethodTable: 706c0a00

  11:  EEClass: 7047d64c

  12:  Size: 20(0x14) bytes

  13:  String: 3

  14:   

  15:  0:003> !do 01c83b0c

  16:  Name: System.String

  17:  MethodTable: 706c0a00

  18:  EEClass: 7047d64c

  19:  Size: 26(0x1a) bytes

  20:  String: 0123

  21:   

  22:  0:003> !do 01c83b28

  23:  Name: System.String

  24:  MethodTable: 706c0a00

  25:  EEClass: 7047d64c

  26:  Size: 20(0x14) bytes

  27:  String: 4

  28:   

  29:  0:003> !do 01c83b3c 

  30:  Name: System.String

  31:  MethodTable: 706c0a00

  32:  EEClass: 7047d64c

  33:  Size: 28(0x1c) bytes

  34:  String: 01234

From the results above we can see how on each iteration we have two strings, the resulting of i.ToString() and the resulting of concatenation.

Conclusion, we still creating new strings and discarding the previous version for GC on each manipulation of the string. Therefore, I suppose the rule was removed just because it was too noisy.

Once I stopped playing with WinDbg I come back to the earth to say what I wanted to say from the beginning. It's pity to see that a performance issue that has been repeated so many times, now is ignored just because the rule is too noisy. I know lot of people could argue that using the StringBuilder we also discard old versions of strings when the size of the string becomes bigger than the buffer, but still better than discarding all modifications.

I don't understand why a good string handling was that important before and now is just ignored by the main CA tool used by .NET developers.

Recently, I recorded a Spanish video about how to encrypt/sign information using certificates and I thought it would be nice to write also a post about it. The thing is that when I tried to post it I received an alert about having a post with the same title, I already wrote this post more than two years ago :(, so while I try to figure out why I have this memory leak in my brain I will write only the missed part: how sign data using X509 certificates.

Since we already have in the previous post the code to load certificates we will focus on two methods Sign and VerifyHash.

   1:  public static byte[] Sign(byte[] hash, 

   2:      X509Certificate2 certificate)

   3:  {

   4:      if (hash == null)

   5:      {

   6:          throw new ArgumentNullException("hash");

   7:      }

   8:      if (certificate == null)

   9:      {

  10:          throw new ArgumentNullException("certificate");

  11:      }

  12:   

  13:      using (RSACryptoServiceProvider provider = 

  14:          new RSACryptoServiceProvider())

  15:      { 

  16:          provider.FromXmlString(

  17:              certificate.PrivateKey.ToXmlString(true));

  18:          return provider.SignHash(

  19:              hash,

  20:              CryptoConfig.MapNameToOID("SHA1"));

  21:      }  

  22:  }

  23:   

  24:  public static bool VerifyHash(byte[] hash, byte[] signature, 

  25:      X509Certificate2 certificate)

  26:  {

  27:      if (hash == null)

  28:      {

  29:          throw new ArgumentNullException("hash");

  30:      }

  31:      if (signature == null)

  32:      {

  33:          throw new ArgumentNullException("signature");

  34:      }

  35:      if (certificate == null)

  36:      {

  37:          throw new ArgumentNullException("certificate");

  38:      }

  39:   

  40:      using (RSACryptoServiceProvider provider = 

  41:          new RSACryptoServiceProvider())

  42:      {

  43:          provider.FromXmlString(

  44:              certificate.PublicKey.Key.ToXmlString(false));

  45:          return provider.VerifyHash(

  46:              hash, 

  47:              CryptoConfig.MapNameToOID("SHA1"), 

  48:              signature);

  49:      }

  50:  }

The idea behind these two methods is the next:

We have one party A who needs to send a message to B. B wants to be sure that the messaged received has not been modified by a third party C. To do that, A will create a digital signature that will be sent together with the message. To generate the signature A needs to compute a hash of the message, this hash is then used with method "Sign". Once A has the signature he can transmit the message and the signature to B.

When B receives the message and the signature, B needs to verify the hash. So, B computes again a hash of the received message and uses the method VerifyHash, which will return true if the message has not been modified. The next code shows you an example on how to call both methods.

   1:  static void Main(string[] args)

   2:  {

   3:      string certificateName = "Test";

   4:   

   5:      X509Certificate2 cert = LoadCertificate(

   6:          StoreName.My, 

   7:          StoreLocation.LocalMachine, 

   8:          certificateName);  

   9:      

  10:      byte[] messageSent = 

  11:          UTF8Encoding.UTF8.GetBytes("Message sent from A to B");

  12:   

  13:      // A generates the signature before send to B

  14:      SHA1Managed sha1 = new SHA1Managed();

  15:      byte[] hashA = sha1.ComputeHash(messageSent);

  16:      byte[] signature = Sign(hashA, cert);

  17:   

  18:      // B receives the message and the digital signature

  19:      byte[] messageReceived = 

  20:          UTF8Encoding.UTF8.GetBytes("Message sent from A to B");

  21:      //byte[] messageReceived = 

  22:      //  UTF8Encoding.UTF8.GetBytes("Message hacked by C");

  23:   

  24:      byte[] hashB = sha1.ComputeHash(messageReceived);

  25:   

  26:      if (VerifyHash(hashB, signature, cert))

  27:      {

  28:          Console.WriteLine("Verified");

  29:      }

  30:      else

  31:      {

  32:          Console.WriteLine("Not verified");

  33:      }

  34:   

  35:      Console.ReadKey();

  36:  }

This piece of code using the rest of methods mentioned shows you how we can verify a message has not been altered during the transmission. If you comment lines 19,20 and uncomment 21,22 you will see that after message has been altered the hash cannot be validated anymore. These short methods are one the basis of security when we try to guarantee information is not being altered from origin to destine. We have used a very basic message, but imagine you have an online shop and you don´t want people can alter from the message the number of items that will be delivered after you have authorized a payment.

Checking similar methods like SignData and VerifyData will be left as an exercise for the reader.

Yesterday I was viewing a video (Spanish) that explains about how to implement the Singleton pattern in .NET. After some implementations the video ends up showing the best way to have a thread safe implementation of the singleton pattern.

The problem is the video ends saying that the next two implementations are exactly the same on a functional level, which is not completely true.

Implementation 1

   1:  public sealed class Singleton1

   2:  {

   3:      private DateTime creationTime;

   4:      private static Singleton1 instance = null;

   5:      private static object synchro = new object();

   6:   

   7:      private Singleton1()

   8:      {

   9:          creationTime = System.DateTime.Now;

  10:      }

  11:   

  12:      public static Singleton1 Instance

  13:      {

  14:          get

  15:          {

  16:              if (instance == null)

  17:              {

  18:                  lock (synchro)

  19:                  {

  20:                      if (instance == null)

  21:                      {

  22:                          instance = new Singleton1();

  23:                      }

  24:                  }

  25:              }

  26:   

  27:              return instance;

  28:          }

  29:      }

  30:   

  31:      public string CreationTime

  32:      {

  33:          get

  34:          {

  35:              return creationTime.ToString("hh:mm:ss.ffffff");

  36:          }

  37:      }

  38:  }

Implementation 2

   1:  public sealed class Singleton2

   2:  {

   3:      private DateTime creationTime;

   4:      private static Singleton2 instance = new Singleton2();

   5:      

   6:   

   7:      private Singleton2()

   8:      {

   9:          creationTime = System.DateTime.Now;

  10:      }

  11:   

  12:      public static Singleton2 Instance

  13:      {

  14:          get

  15:          {

  16:              return instance;

  17:          }

  18:      }

  19:   

  20:      public string CreationTime

  21:      {

  22:          get

  23:          {

  24:              return creationTime.ToString("hh:mm:ss.ffffff");

  25:          }

  26:      }

  27:  }

The second implementation is correct, since it shows how you can avoid the lock while creating the object instance of the Singleton class. The reason why this is thread safe is because .NET guarantees that the Type Constructor (or Type Initializer on the ECMA standard) is executed only once per AppDomain and is thread-safe.

Regardless both of them are thread-safe, the difference is that the first one is lazy loaded while the second one is eager loaded. In order to implement the singleton pattern using a lazy loaded version and still take profit of the Type Constructors, you need to add a container for the object instance of Singleton2. Doing this the Type Constructor will only be initialized when you access the property (or any other member making reference to it). Below you can see the correct implementation for it.

   1:  public sealed class LazyLoading

   2:  {

   3:      private DateTime creationTime;

   4:   

   5:      private LazyLoading()

   6:      {

   7:          creationTime = DateTime.Now;

   8:      }

   9:   

  10:      public static LazyLoading Instance

  11:      {

  12:          get

  13:          {

  14:              return SingletonContainer.instance;

  15:          }

  16:      }

  17:   

  18:      public string CreationTime

  19:      {

  20:          get

  21:          {

  22:              return creationTime.ToString("hh:mm:ss.ffffff");

  23:          }

  24:      }

  25:   

  26:      class SingletonContainer

  27:      {

  28:          internal static readonly LazyLoading instance = 

  29:              new LazyLoading();

  30:      }

  31:  }

I was one of those lucky guys who got the Windows 7 virtual machine at the PDC for the first time and I already liked. When the new beta was released I decided to install it on my old laptop and I love it, I really mean it. I think it's great, there are a lot of small features that you immediately like with almost not noticing them. One of them is the cool docking feature that allows you drag a window over the limits of the screen to change it's size and position.

When I saw I immediately wondered how this could be done using C#. The idea would be to detect when a window is being dragged to the limits of our screen, when it reaches them display a frame and finally change the size and position of the window being dragged. 

At a first view, using some Windows Hook and capturing a couple of messages can do the trick. The problem is that we can only install global hooks for WH_KEYBOARD_LL and WH_MOUSE_LL, the other global hooks require a native DLL export to inject itself in another process. This is already a problem because discards the possibility to monitor messages before and after they are processed by a window,  in addition we cannot use either the MouseProc that gives us information about the mouse and more important the value of the HitTest, which is necessary to know what part of the window the user is clicking. What we will do is to try to use the WH_MOUSE_LL with some work around. I already wrote about hooks more than one year ago, you can read it here if you are not familiarized with them.

With that hook we will obtain information about mouse events, we will focus on the messages WM_LBUTTONDOWN, WM_MOUSEMOVE and WM_LBUTTONUP. In the attached code I created a hook helper that captures the hook callbacks and generates .NET events to facilitate its use. You can see below the event handler:

   1:  void hookHelper_HookMouseEvent(object sender, 

   2:      HookMouseEventArgs e)

   3:  {

   4:      switch(e.Message)

   5:      {

   6:          case NativeConstants.WM_LBUTTONDOWN:

   7:              CheckWindow(e.Point);

   8:              break;

   9:    

  10:          case NativeConstants.WM_MOUSEMOVE:

  11:              CheckPosition(e.Point);

  12:              break;

  13:    

  14:          case NativeConstants.WM_LBUTTONUP:

  15:              ResizeWindow(e.Point);

  16:              break;

  17:      }

  18:  }

In the method CheckWindow we decide if we Window where the user has clicked is a window we are interested to monitor, to do it we retrieve the window handle using the API WindowFromPoint and doing a Hit test over the window. The Hit test can be done by sending the message WM_NCHITTEST specifying the handle of the window and the coordinates of the point, this will return us a value indicating what part of the window has been clicked, in our case we are interested only if the user clicks the Title of the window, which value is HTCAPTION.

   1:  private void CheckWindow(Point point)

   2:  {

   3:      Win32.NativeStructs.Point p = 

   4:          new Win32.NativeStructs.Point();

   5:      p.x = point.X;

   6:      p.y = point.Y;

   7:    

   8:      windowHandle = NativeMethods.WindowFromPoint(p);

   9:      if (windowHandle != IntPtr.Zero)

  10:      {

  11:          IntPtr lParam = new IntPtr(65536 * p.y + p.x);

  12:          IntPtr hitTestPtr = NativeMethods.SendMessage(windowHandle, 

  13:              (uint)NativeConstants.WM_NCHITTEST, (uint)0, lParam);

  14:          if ((int)hitTestPtr == NativeConstants.HTCAPTION)

  15:          {

  16:              dragging = true;

  17:          }

  18:      }

  19:  }

The messages, return values and functions are declared in the header Winuser.h, the easier to have all the information about the windows API is to go to MSDN, of course, but also to download the Windows SDK.

Next step is to give to the user the visual clue that something will happen with the window, to do it Windows 7 shows an animation below the pointer and a frame simulating where the window will be placed. To do it we will not code any fancy thing, we can simulate it by just opening a standard .NET form setting its properties ControlBox, ShowInTaskBar and TransparencyKey to our desired values. To know the size we need to give to our frame we just need to check the property WorkingArea from the .NET class System.Windows.Forms.SystemInformation. The only trick we will do is to display the form with the function SetWindowPos, because it allow us controlling the Z-Order of the window and to open the form without activate it, this is handy to avoid our fake frame is placed on top of the window we are actually moving. To do it we use the function SetWindowPos including the handle of the window to insert after and the parameter SWP_NOACTIVATE.

   1:  NativeMethods.SetWindowPos(frame.Handle,

   2:      windowHandle,

   3:      0, 0, 

   4:      SystemInformation.WorkingArea.Width / 2, 

   5:      SystemInformation.WorkingArea.Height,

   6:      NativeConstants.SWP_SHOWWINDOW | 

   7:      NativeConstants.SWP_NOACTIVATE);

We are near to the end, we just need to complete the last step, change the size and position of the window to the desired the values using again the function SetWindowPos for the left and right placement. To maximize we just use the function ShowWindow passing as parameter SW_SHOWMAXIMIZED.

Windows 7 also restores the original size of the window after you drag away from the docked position, this could be done by capturing first the size and position of the window using the functions GetWindowPlacement and SetWindowPlacement, if you use them do not forget to set the length of your WindowPlacement structure using Marshal.SizeOf().

If you are not familiarized with P/Invoke in .NET you can make use of tools like PInvoke Interop Assistant from Microsoft CLR Interop Team or the P/Invoke wiki.

Now that all seems to be under control, if you download the code you will see that we have a big problem. When we release the button the size doesn't seem to change, but it actually changes to the size and position we have given.  The problem is that the window is in the moving state and when we release the button after set our size, it comes back to the last size the window had before releasing the mouse button. If we make use of Microsoft Spy++ we can see that after set the position the window still receives the messages like WM_WINDOWPOSCHANGED or WM_EXITSIZEMOVE.

I've tried with some of the messages captured previously using the function SendMessage to see if I could exit the moving/sizing state but without success. So, at the end I couldn't resolve it using C#, if you have ideas on how this can be solved they will be welcome. As I was joking with a friend a couple of days ago I feel I've lost my "mojo".

It is curious to see how our mind works, when I completely stopped thinking about what message send in order to make it work, I thought I could try the last trick by setting the size after the resize was completed. The way to do that is pretty simply, we just need to enable a timer that starts after we capture the WM_LBUTTONUP.

MadAboutNet.WindowsDocker.zip (404.63 kb)