Orchestra Technology

1. Requirements

Windows 7 Enterprise Edition (32-Bit OS)
.Net Framework 3.5 SP1
Compiler Version 3.5.30729.4918
Visual Studio 2008 Version 9.0.30729.1

2. Purpose

Sometimes it can be cumbersome to debug multi-thread applications, trying to use very simple features such as “Step Into” (F11), “Step Over” (F10) and “Step Out” (Shift + F11) can easily mess your mind up. Most developers that use Visual Studio as their primary IDE, are not aware of its multi-thread debugging features. So, I decided to post several tips and tricks that can be very handy while debugging this kind of applications.

3. Demo

Before we begin, a sample multi-thread application will be necessary to apply the techniques throughout this post. It is a simple Console Application that creates two threads, Thread A and Thread B, which will count from 0 to 100, printing “Thread A - 0”, “Thread A - 1”, and so forth. Take a look at the following illustrations:

using System;
using System.Threading;

namespace MultiThreadDebugging
{
    class Program
    {
        static void Main(string[] args)
        {
            Thread threadA = new Thread(Execute);
            threadA.Name = "Thread A";
            threadA.Start(threadA.Name);

            Thread threadB = new Thread(Execute);
            threadB.Name = "Thread B2";
            threadB.Start(threadB.Name);

            Console.ReadLine();
        }

        static void Execute(object threadName)
        {
            for (int i = 0; i < 100; i++)
            {
                Console.WriteLine(threadName + " - " + i);
            }
        }
    }
}

The following illustration shows the expected output from the application:

Set up a break point on line 25 and hit F5 to run the console application.

After the execution stop on the breakpoint, click on menu Debug > Windows > Threads or press CRTL + D + T to exhibit the Threads window. Below, you will find an illustration of this window:

As you can see in the above picture, the Main Thread is differentiated with a green square and the current thread is marked with a yellow arrow. Also, other threads appear on the list, which are loaded by Visual Studio and CLR. Thread B does not appear in the thread list because it is waiting to execute. However, there is an easy way to show where are all the threads hanging around. I order to do that, click on menu

Click on the Show Threads in Source button located on Debug toolbar:

Next, you will see that an icon composed of two waves appear on the left side of the row numbers indicating where the Main Thread execution is hanging. Also, the line is highlited, in this case, with a gray background color. That is why Thread B does not appear on the list, it did not started yet.

Now, that the basics are covered, let’s see how can tell the Debbugger to stop only when the executing thread is Thread B, which is very handy while executing very common features such as Step Into, Step Over and Step Out.

Stop running the console application and right click the breakpoint and choose Filter option:

Using the ThreadName instead of ThreadId is most of the time better, because the thread id is provided by the operational system kernel and changes among. Hit F5 run the console application again and notice that while debugging the breakpoint will stop only for Thread B.

Another feature that I would like to point here is breakingponts acting like trace. Let’s suppose that you would like to trace your application, a very powerful and common way is to instrument your with the trace mechanisms of the .NET platform. However, sometimes, you only need a simple information, so it’s possible to achieve the desired result without having to change your code.

Rick click the breakpoint, choose When Hit option and set the “Print a message” with $TNAME = {i}, where $TNAME will print the thread name (Thread A or Thread B) and {i} will print the i variable value. Take a look at following illustration:

Last tip, if want to save the Output Windows content on a text file just press CTRL + S.

4. Resources

There is more content regarding breakpoint and tracepoints on MSDN http://msdn.microsoft.com/en-us/library/ktf38f66.aspx.

1 Requirements

• Windows 7 Enterprise Edition (32-Bit OS)
• .Net Framework 3.5 SP1
• C# Compiler Version 3.5.30729.4918
• Visual Studio 2008 Version 9.0.30729.1

2 Problem

Recently, I have been seeing people developing N-layer applications coding all classes from all layers with the public access modifier. The motivation for that is because functionalities that reside on an assembly needs be accessed from the previous assembly in the call stack, for example, a class on the business logic layer needs to access another in the data access layer. Depending on the size of your team, the application complexity, project milestones and deadlines, etc., this design decision can lead to undesired results, such as:

• Inexperienced developers can accidentally make a mess with the calls, for example, coding the presentation layer to access directly the data access layer.
• Developers pressured by a tight milestone/deadline can be tempted to do exact the same of previous item.
• Suddenly, you realize that the robust exception handling mechanism implemented on the façades in the business logic layer is not working for several features. Moreover, the integration with third-party applications won’t be that easy because several features do not have a business logic entry.

Before getting the hands dirty, I do think is important to state several concepts regarding layers.
Dividing the application in layers allows you to create logical divisions to group code that have similar purpose. On one hand, this can help developers to understand how the application is organized, where they should put their code, etc. However, on the other hand, keep in mind that a logical architecture is not required to make your application work. Also, try not to confuse the term layer with tier, which is more related to physical division (process and/or machine). Below, there is an illustration of a simple N-layer application:

3 Workaround

There are several workarounds that can be applied to solve the encapsulation problems presented on the previous section.

One possibility it to create the layers on only one logical unit (assembly) coding all BLL, DAL and DTO classes and/or structs, which should be exposed with the internal access modifier, for example:

I have been hearing several people discussing about this approach not being efficient, because the project would always be checked out to another developer, becoming a contention point during coding phase. Presonaly, I think this can be true on several scenarios, such as:

• Project has more than least 20 developers and coding phase is soaring with people are adding objects to the Visual Studio project like crazy.
• Project has 5 developers and a couple of them constantly forget to check-in the project after adding an object, preventing others to do their jobs. This can be a consequence of: lack of a simple check-in/check-out process; or inexperience of a team member, who does not know the trouble his making to others or he is to focus to get the job done and just forget to check-in the project.

Tip: after adding an object to a project, for example, a class, make the check-in without starting coding, this way you avoid breaking the code. After that, check the file out and start getting your hands dirty.

Another approach would be having the layers separated in different assemblies, coding all classes with the internal access modifier and configuring which assemblies would be able to make calls to these internal functionalities.
To better exemplify this approach, the following steps will describe how it is possible to exposed functionalities from the Data Access Layer (DAL) only to the Business Logic Layer (BLL), supposing that DAL classes have the internal access modifier specified:

• Sign both Application.BLL.dll and Application.DAL.dll with a strong name (through VS IDE or sn.exe);
• Get the public key from the Application.BLL.dll assembly with sn –Tp Application.BLL.dll;
• Configure Application.DAL.dll to expose internal classes to Application.BLL.dll. This can be achieved through adding the [assembly: System.Runtime.CompilerServices.InternalsVisibleTo(”Application.BLL, PublicKey=002400000480000094000000060200000024000052
  53413100040000010001003396ebc2b7199d23b73c40982b891fb3eb
  ecaa93deceaf189f12b38b252d7e144991ad1736ab900945e5b3d0e0
  15e833631cadb239c8325baa3f7662c7b1208456173cc8b233485bee
  32e4c8b5292b0d26703585737de948af9d95318751df369896a76cfb
  561ec1cad90a324a131bfeb7ecb54c9f35f262c2851234749ec8c9″)] in the AssemblyInfo.cs in Application.DAL project. Caution: your public key will be different from the one in this example;
• Compile your solution and go for it.