Mad about .NET

NDepend

jfbonnin.nospam@nospam.baleareson.net (jose) — Sun, 14 Jun 2009 13:09:46 -0300

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.

Presenting at large events such as TechEd

jfbonnin.nospam@nospam.baleareson.net (jose) — Wed, 29 Apr 2009 15:10:00 -0300

INETA APAC is organizing a series of best practices webcasts of interest to the community. The webcasts apply to all members of the community, leaders, user group members and MVP’s, who might not yet be at the stage where they speak at large events. The topic would be of interest to all, and would help more people to aspire to be speakers, and get an understanding of what is involved in being a good speaker.

Here are the details of the first webcast:

Best Practices Webcast: Presenting at large events such as TechEd

Session abstract: Presenting at large events such as TechEd involves a lot of preparation. Too many speakers leave far too much to chance. Doing a good job does not happen by accident. In this session, Greg will share experience and tips related to the process of getting selected, preparing content and delivering that content. Many of the tips can also be applied to improving the delivery of technical material in classroom or user group situations.

Presenter Bio: Greg Low is an internationally recognized consultant, developer and trainer. He is the country lead for Solid Quality, a SQL Server MVP and one of only three Microsoft Regional Directors for Australia. Greg also hosts the popular SQL Down Under podcast (www.sqldownunder.com), is a board member of PASS (the Professional Association for SQL Server) and an author with Microsoft Press and Rational Press. He regularly speaks at large events around the world.

INETA APAC invites you to select a convenient time of your choice for this webcast, fill the survey(takes less than 3 minutes) and we will notify you of the final survey results and the exact webcast timing.
http://www.surveymonkey.com/s.aspx?sm=AdhgSxdrRqvyUP9KZQRWpA_3d_3d
Please note that Survey closing date is : May 4, 2009

Static Code Analysis

jfbonnin.nospam@nospam.baleareson.net (Jose) — Thu, 23 Apr 2009 15:45:06 -0300

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.

Signing with Certificates

jfbonnin.nospam@nospam.baleareson.net (Jose) — Tue, 21 Apr 2009 14:22:32 -0300

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.

Singleton Pattern

jfbonnin.nospam@nospam.baleareson.net (jose) — Mon, 13 Apr 2009 14:13:00 -0300

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:  }

User Group Support Services

jfbonnin.nospam@nospam.baleareson.net (jose) — Sat, 04 Apr 2009 14:56:49 -0300

I have recently started to volunteer as UGSS Regional Lead for EMEA.

For those who know UGSS and the RL, you will know that this is a position covered by Microsoft personnel, my case is a bit different because I agreed to volunteer during this FY to help out Sanjay Shetty who is the official responsible for EMEA and APAC.

If you do not know the UGSS I highly suggest you visit http://ugss.codezone.com, where you will be able to find more information about what UGSS does for the community.

As our manager Graham Jones already mentioned in this post, the role of a regional lead is to help user group leaders to be as successful as possible independently to which organization, if any, their user groups belong. So, if you have any question or suggestion we all will be extremely glad to help you.

In this short period as RL, I have had the possibility to be amazed for the huge amount of projects, initiatives my colleagues are involved.

I'm still landing but I'm pretty sure the community will be also amazed about the good things that are coming out of the work the UGSS does.

Docking as Windows 7 in Vista and XP

jfbonnin.nospam@nospam.baleareson.net (Jose) — Sat, 31 Jan 2009 16:32:00 -0300

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)

Xml Documentation Comments - Exceptions II

jfbonnin.nospam@nospam.baleareson.net (jose) — Thu, 15 Jan 2009 16:12:45 -0300

People who has been working with me knows that I'm a big fan of FxCop (or Code Analysis), I think static code analysis tools are very useful and a must-have in any development team, since ensure developers follow the company's guidelines and write correct code (at least it helps a lot). In addition, I see them also as a great ally to improve the learning curve of new developers.

While FxCop analyzes managed code assemblies checking for improvements about design, localization, performance, security, interoperability, etc. StyleCop focuses mainly in code style guidelines.

In the previous post we saw how to document exceptions using the Xml Documentation features. Here we will see how to take profit of StyleCop SDK to create a custom rule that validates we are documenting those exceptions.

To create our rule we just need to create a class library project, add references to the assemblies Microsoft.StyleCop.dll and Microsoft.StyleCop.CSharp.dll, create a class that inherits from SourceAnalyzer, add an attribute and embed an Xml file with the necessary Metatada for our rules. All these steps are entirely documented in the StyleCop SDK documentation, so I do not waste too much time explaining it.

Before we start we need to know that the StyleCop engine incorporates a custom C# language service that is used to create a rich model representing the original C# code. What our rule will do is to use that model to visit the different elements that can throw exceptions, analyze the element's body to find the throw statements and extract the type of that exceptions, it will extract the exceptions documented using the Xml comments, finally it will compare the thrown exceptions with the documented ones and will add a violation for all the discrepancies found.

We know that we can use throw statements inside methods (including constructors), indexers and properties. So, taking profit of the Visitor implementation that the API provide us we will visit all the CsElement of a CsDocument looking for the declared methods, indexers and properties. Below you can see the callback method we have passed to the WalkDocument method.

   1:  private bool VisitElements(

   2:      CsElement element,

   3:      CsElement parentElement,

   4:      List<string> usingDirectives)

   5:  {

   6:      if (this.Cancel)

   7:      {

   8:          return false;

   9:      }

10:

  11:      // We store the using directives for future use

  12:      if (element.ElementType == ElementType.UsingDirective)

  13:      {

  14:          usingDirectives.Add(

  15:              ((UsingDirective)element).NamespaceType);

  16:      }

17:

  18:      // There are severeal element types that can throw exceptions:

  19:      // Methods, Constructors, Indexers and Properties

  20:      if (!element.Generated &&

  21:          (element.ElementType == ElementType.Method ||

  22:           element.ElementType == ElementType.Constructor ||

  23:           element.ElementType == ElementType.Indexer ||

  24:           element.ElementType == ElementType.Property))

  25:      {

  26:          this.CheckExceptionDocumentation(element,

  27:              usingDirectives);

  28:      }

29:

  30:      return true;

  31:  }

Lines 17 to 24 allow us filtering the elements for which we are going to check the documentation. You can see also from line 10 to 13 that we store the using directives defined in the document, later on I will explain why.

The next is to analyze more in detail each element we have filtered, what we will do is first look for the exception tags added in the Xml comments and then compare them with the type of the exceptions thrown in the given element. The first step is as easy as perform a Linq Xml query over a property called Header the CsElement has. For the second one we will create a CodeWalkerStatementVisitor that we will pass to the WalkElement method, this callback will be used to iterate the element's statements looking for all the the throw statements defined.

To do it we only need to check the StatementType property belogning to the class Statement and make sure its type is StatementType.Throw. Once we have the ThrowStatement we can investigate the type of the exception that will be thrown. The demo rule can analyze the next scenarios:

New expressions. i.e. throw new System.Exception();
Literal expressions. i.e. var ex = new Exception(); throw ex;
Method invocation expressions. i.e. throw GetMyExceptionInstance();

The ThrowStatement class has a property called ThrownExpression that allow us identifying the expression used to throw the exception.

For the first scenario, we need to iterate the different tokens of the NewExpression and extract the exception type. This is done in the code using the next method.

   1:  private static string ExtractExceptionType(NewExpression expression)

   2:  {

   3:      for (Node<CsToken> node = expression.Tokens.First; node != null;

   4:          node = node.Next)

   5:      {

   6:          CsToken token = node.Value;

   7:          if (token.CsTokenType == CsTokenType.Other)

   8:          {

   9:              return token.Text;

  10:          }

  11:      }

12:

  13:      return string.Empty;

  14:  }

For the second scenario we have a small handicap, the literal represents a variable that is not defined in the throw statement, instead it is defined in upper statements or even in elements different than the one where the exception is thrown i.e.

   1:  ArgumentNullException ex = new ArgumentNullException();

   2:  public void DoSomething(string value)

   3:  {

   4:      if (value == null)

   5:      {

   6:          throw new ex;

   7:      }

   8:  }

In the code above the element containing the throw statement is the method DoSomething, but the variable ex is defined in a class element.

For this reason before we can obtain the type of the exception, we first need to retrieve the variables defined by the parent statements of the throw statement. After that we just need to find the variable among the retrieved ones to determine its type and return it for further analysis.

The third scenario is the MethodInvocationExpression, here we have the biggest handicaps because there are many possibilities in which we can obtain an exception from a method. The easiest case is a direct method call, we will have MethodInvocationExpression containing the LiteralExpression with the name of the method, but imagine the next situation:

throw new MyClass().GetException();

In this case, the expression is a member access and we need to go to the right side to find the literal with the name of the method.

Once we have the obtained the name of the method, we can perform a search in the Document looking for that Method element in order to retrieve its return type that, of course, will be our exception type. We do not need to worry about overloads with different return types, because even if the CLR supports it C# does not and we are analyzing C# code.

At this point we have been able to retrieve all the exception types thrown by the throw statements and we can compare with the ones we have documented. Unfortunately we are not done yet and there is another point to solve.

The problem we have is that the object model representing the code we analyze, does not stores the type of the variables , return types of methods, etc. as the .NET type "Type". Instead they are represented in best case as a TokenType with a text representation. This has sense for many reasons, one is because StyleCop analyzes code that doesn't necessarily compiles therefore it's possible the type does not exists yet.

So, how this affects to the rule? Since we do not have the real types for the Exceptions we want to verify but string representations of them, the next code will cause a false positive:

   1:  /// <exception cref="System.Exception"></exception>

   2:  public void DoSomething()

   3:  {

   4:      throw new Exception();

   5:  }

The false positive appears because at the time we compare the type throw with the type documented we will compare "System.Exception" with "Exception". That's the reason why we have stored the using directives in a previous step, because before to compare we will try to obtain the full type name doing a Type.GetType() concatenating the different namespaces imported into the document. In case, that we are still not able to get the type (i.e. exception defined in a different assembly not accessible from StyleCop) we will compare both texts without the namespace, this is using Exception instead of System.Exception.

I'm really curious to see if StyleCop will be benefited when the new managed C# compiler is there, part of the project to offer the C# compiler as a service will include a complete language object model. I suppose it will be a natural step to use that new model, but this is way far from today since, regardless the C# team is already working on it, it is supposed to come after C# 4.0.

With this rule we are covering the most common scenarios where exceptions are thrown, but there are cases that will fail. i.e. If the exception thrown is obtained from a method declared in a different document, the rule will not be able to find that method and consequently the type of the exception.

StyleCopRule.zip (21.66 kb)

Xml Documentation Comments - Exceptions I

jfbonnin.nospam@nospam.baleareson.net (jose) — Sun, 11 Jan 2009 08:55:52 -0300

Long time ago my team was investigating about a new beta technology called .NET, we needed to compare it against Java and decide what would be our new development platform (I guess it's clear which one we successfully decided to use). One of the things I liked about Java were Checked Exceptions, I thought it was handy to have this enforced by the compiler. Nowadays I'm 100% convinced I wouldn't like to have them in .NET and it seems I'm not the only one. If you are curious to know why checked exceptions where not added to .NET you can read the interview done to Anders Hejlsberg some years after the beta release.

In any case, it's clear that even if we do not want the compiler forces us to handle exceptions, there is no doubt that the information about the exceptions that can be thrown by a method are very useful for developers. In order to help us with this we can make use of the Xml Documentation Comments, to do it we have the exception tag that allow us introducing the information regarding the exceptions thrown by our Constructors, Methods, Properties and Indexers, this information will then be listed not only in the documentation we generate with tools like Sandcastle or NDoc but also when we use Intellisense.

Below you can see an example about how to make use of it.

   1:  /// <summary>

   2:  /// Does something

   3:  /// </summary>

   4:  /// <param name="value">A string value</param>

   5:  /// <exception cref="System.ArgumentNullException">

   6:  /// Thrown when value is null

   7:  /// </exception>

   8:  public void DoSomething(string value)

   9:  {

  10:      if (value == null)

  11:      {

  12:          throw new System.ArgumentNullException("value");

  13:      }

  14:  }

The compiler gives us some help to make sure we write the Xml comments, but unfortunately it is not enabled by default. To do it we need to go to the build properties of our project and configure it to generate the documentation files.

After we configure it the compiler will generate errors (warnings if you do not work with "Treat warnings as errors", but I like to think nobody has this option disabled in professional software) for the public or visible elements that do not have the Xml comments. This is a good start point, the compiler validates the Xml comments exist, but does not check the validity of them. i.e. somebody can add the tags and let the values empty. Therefore if we want to check our documentation is properly formatted we need to look for static analysis tools that do this work.

In the next part of this post we will see how to create a custom rule for StyleCop that checks the exceptions thrown by our code are documented.

Visual Studio 2010 Extensibility

jfbonnin.nospam@nospam.baleareson.net (jose) — Tue, 25 Nov 2008 18:08:29 -0300

If you open Visual Studio 2010 the first thing you probably will notice is that the Start Page has been completely redesigned. The Start Page is now created with WPF, yes you have read it correctly, and it is not the only thing that uses WPF, the code editor is also WPF based.

As you can imagine the page can be customized (which by the way was already possible in Visual Studio 2003), to do it you only need to modify the template found in the directory "%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\StartPages\<culture>", place your modified version in the folder "%UserProfile%\Documents\Visual Studio 10\StartPages" and that's all, your customized StartPage will be loaded immediately without needing restart Visual Studio.

The screenshot above shows an easy customization that I've done. I've just added a new TrayItem on the left side and took profit of the dll Microsoft.VisualStudio.Shell.UI to run some Visual Studio commands to open an IE window, view Visual Studio as full screen and open the Team Explorer window. Below you can see the necessary XAML to do it.

   1:  <!-- Customized tray-->

   2:  <!-- Mad About .NET group -->

   3:  <vs:TrayItem Header="Mad about .NET" x:Uid="Custom_Header">

   4:      <vs:TrayGroup>

   5:          <vs:TrayGroupItem Content="Mad about .NET Blog"

   6:              ImageSource="pack://application:,,,/Microsoft.VisualStudio.Shell.UI;

   7:                            Component/Packages/StartPage/Images/12_settings.png"

   8:              Command="{x:Static vs:VSCommands.Browse}"

   9:              CommandParameter="{StaticResource Links.MadAboutNET}"

  10:              x:Uid="MadaboutNET_Item"

  11:          />

  12:          <vs:TrayGroupItem Content="Go Full Screen"

  13:              ImageSource="pack://application:,,,/Microsoft.VisualStudio.Shell.UI;

  14:                            Component/Packages/StartPage/Images/12_settings.png"

  15:              Command="{x:Static vs:VSCommands.ExecuteCommand}"

  16:              CommandParameter="View.FullScreen"

  17:              x:Uid="TeamExplorer_Item"

  18:          />

  19:          <vs:TrayGroupItem Content="Open Team Explorer"

  20:              ImageSource="pack://application:,,,/Microsoft.VisualStudio.Shell.UI;

  21:                            Component/Packages/StartPage/Images/12_settings.png"

  22:              Command="{x:Static vs:VSCommands.ExecuteCommand}"

  23:              CommandParameter="View.TeamExplorer"

  24:              x:Uid="TeamExplorer_Item"

  25:          />

  26:      </vs:TrayGroup>

  27:  </vs:TrayItem>

Regardless the utility or futility of customizing the StartPage, we need to look further. We must look the new extensibility options that Visual Studio 2010 will bring, incorporating WPF opens a new world of options to extend our favorite development tool. But this is just a small piece of the cake, if you want to know more you should check the Managed Extensibility Framework and don't forget to visit the blog of the VSX Team.

PDC & TechEd 2008 Hangover

jfbonnin.nospam@nospam.baleareson.net (Jose) — Sun, 23 Nov 2008 06:13:00 -0300

These last weeks have been quite frenetic for me. I've moved to a new house and before notice I was sleeping in a different house I woke up in a plane going to LA for the PDC, 3 days after I was back from the PDC I went to Amsterdam for the quarterly meetings of my company. Again after 3 days, I was in Barcelona for the TechEd. I guess you imagine how has been coming back to the office.

I must confess I'm not used to travel that much in a short time, I normally do it once a month and is more than enough for me.

The thing is now that I'm back at home and up to date with the work, at least as much up to date as I can be, I start feeling the hangover of the PDC & TechEd. They look already very far away, but I have not been able yet to digest all the cool things I've seen at both events.

I hardly believe I was able to talk in person with people I usually follow like Anders Heljsberg, Maoni Stephens or Joe Duffy.

I really don't know where to start Windows Azure, Windows 7, Windows 2008 R2, Visual Studio 2010, Oslo, Geneva, .NET Framework 4.0, C# 4.0 ...

I'm so excited about most of the things that were announced that I would like to have more hours to check all of them.

Post Event: Re-descubriendo LINQ

jfbonnin.nospam@nospam.baleareson.net (jose) — Sun, 26 Oct 2008 11:25:41 -0300

23rd, October I did a session about LINQ for the .NET User Group Madriddotnet.

Re Descubriendo A Linq

View SlideShare presentation or Upload your own. (tags: linq)

During the event we tried to know more in deep how LINQ works, from C-Omega to LINQ to SQL, doing an attempt to solve many of the questions that normally arise when you want to obtain the most of LINQ.

We found Visual Studio 2008 comes with a nice bunch of samples to helps us including visualizers like the Expression Tree Visualizer, which allows you to see the expression tree created from our queries and the LINQ Query Visualizer to see the translation done to Transact/SQL. We knew that it is possible to create queries on the fly using the Dynamic Query Library

We also talked about the benefits of the expression trees and the visitor pattern. You have some sample implementations like the one done by Matt Warren

In the last part of the event we focused on tips for LINQ to SQL to move to a multi-tier architecture. We explained how easy is to serialize LINQ entities to be used over WCF on both directions, this is from Master to Detail and from Detail to Master. How to workaround the fact that circular references are not supported by default by the DataContractSerializer. We gave some ideas about how to do local change tracking of entities when we are disconnected from the DataContext, providing some examples of complete implementations like the one done at MSDN Video (Spanish).

As you can see we talked about many different things and we verified how LINQ can help us during our day to day work making our life much easier if we apply some good practices.

If you attended to the event I hope you enjoyed as much as I did.

Post Event: Descubriendo el CLR

jfbonnin.nospam@nospam.baleareson.net (Jose) — Thu, 09 Oct 2008 14:58:26 -0300

On Tuesday I did an online webcast about the CLR. I hope the people who joined us enjoyed the event and found the contents interesting.

The event was recorded and you can download it from the Microsoft Events website (Spanish).

During the presentation I did a demo in which I was showing how we can see with WinDBG when a method has been jitted or not. We saw it for the constructor but I stopped before show it for other methods to avoid wasting too much time on the same thing.

One of the attendees has asked me today why the method was shown as not jitted even after it was clearly executed. The problem was simply that I attached WinDGB to the release version of my demo application and the JIT optimized the method replacing it by an inlined version. If I had attached the debug version this would not happen and the method would be shown as jitted. If you want to have more information about it I widely explained in a previous post about Inline methods where I used the same demo application as in the webcast.

Culminis Changes

jfbonnin.nospam@nospam.baleareson.net (Jose) — Mon, 06 Oct 2008 13:49:48 -0300

Around a week ago Culminis announced the next phase of the Culminis transformation has started.

As you probably know Culminis has become a volunteer organization similar to Ineta. This change started long time ago, something that Graham Watson explained with a post describing the key changes about how Microsoft would support the User Groups from now.

I must confess my first reaction was not very positive, I loved how Culminis was working until that day and I was afraid how the new volunteer structure would affect all the services provided.

In any case, I'm sure all the people we are volunteering at Culminis will do our best to satisfy the demands of the user groups. So, now it's time to give our maximum support to the board of directors. If you want to know more about them you can check it here.

Static Fields

jfbonnin.nospam@nospam.baleareson.net (jose) — Sat, 20 Sep 2008 07:52:32 -0300

"Types may declare locations that are associated with the type rather than any particular value of the type. Such locations are static fields of the type. As such, static fields declare a location that is shared by all values of the type. Just like non-static (instance) fields, a static field is typed and that type never changes. Static fields are always restricted to a single application domain basis, but they may also be allocated on a per-thread basis."

The paragraph above is the definition of static field extracted from the CLI specification. The text means that when we create a static field "f" inside a class "C", the value will not belong to any of the instances we create of C, instead its value is shared across all the instances and therefore "belongs" to the type C itself.

I've created a very simple class with one static and two instance fields, which you can see below.

        1: public class BusinessLogic

       2: {

       3:     public int instanceField1;

       4:     public int instanceField2;

       5:  

       6:     public static int staticField3 = 3;

       7:  

       8:     public BusinessLogic()

       9:     {

      10:         instanceField1 = 1;

      11:         instanceField2 = 2;

      12:     }

      13: }

I've run the code and I've created 5 instances of the class above, which we will check with WinDBG. To do it we can execute the next command:

!DumpHeap -type BusinessLogic

That will show something similar to the next:

Address               MT     Size
01dfa98c      006668c4      16
01dfe898     006668c4       16
01e027a4     006668c4       16
01e0668c     006668c4       16
01e13104     006668c4       16
total 5 objects
Statistics:
      MT    Count    TotalSize   Class Name
006668c4        5           80        BusinessLogic
Total 5 objects

Once we have the address of the 5 instances we created we can dump the objects one by one by using the command !DumpObj [Address]. If we take the first one it will display something similar to:

Name: BusinessLogic
MethodTable: 001c68bc
EEClass: 00281abc
Size: 16(0x10) bytes
Fields:
          MT      Field   Offset   Type                VT   Attr         Value    Name
6f642b38 4000001        4      System.Int32     1    instance 1           instanceField1
6f642b38 4000002        8      System.Int32     1    instance 2           instanceField2
6f642b38 4000003       1c     System.Int32     1    static       3           staticField3

What we have done with this command is to examine the fields of one of the instances in memory of BusinessLogic. We can see that the object has the fields instanceField1, instanceField2 and staticField3 and its values are 1,2 and 3 respectively. So, all is as expected.

Lets focus now on the cool thing of static fields. We can see how "staticField3" is shared across al the instances we create of BusinessLogic by examing the EEClass of the objects. The 5 instances we created before have the same EEClass: "00281abc". If we examine it with the command !DumpClass 00281abc we will see that "staticField3" is present at EEClass level and its value is already initialized.

Class Name: BusinessLogic
mdToken: 02000002
Parent Class: 6f3d3ef0
Module: 001c64f0
Method Table: 001c68bc
Vtable Slots: 4
Total Method Slots: 6
Class Attributes: 100001
NumInstanceFields: 2
NumStaticFields: 1
      MT          Field Offset   Type                 VT    Attr         Value   Name
6f642b38    4000001        4      System.Int32   1     instance              instanceField1
6f642b38    4000002        8      System.Int32   1     instance              instanceField2
6f642b38 4000003      1c    System.Int32   1     static           3     staticField3

At this point we have demonstrated how the static fields and their values are shared across all the instances we create of a class.

In this sample we have used value types for the static field, but this also applies for reference types. This is very cool, because it allow us creating class designs where objects with a heavy load construction can be instantiated just once i.e.

static object staticField;
....
if (staticField == null)
staticField = new object();

This simple code will allow sharing the same instance of staticField across the entire application domain helping with the performance if staticField is hard to construct.

This does not mean that from now you must create all your "hard to construct" fields as static, because like always the gold hammer does not exist and static fields have a downside.

As we have seen the static field values are related to the EEClass, which are allocated on the loader heaps that are AppDomain specific, so this means they will be in memory until the AppDomain is unloaded.