The (Unofficial) ITWorx Technical Architecture Blog

Archive for June, 2007

Testing Private Methods

Posted by archworx on June 21, 2007

Test Driven Development a practice that is becoming very popular due to the quality assurance that it adds. While it is easy to test public methods, How do I test private methods?

There are 2 ways:

  1. Using Helper Class discussed on The Code Project
  2. Using Microsoft’s build in Testing Tools


using Microsoft.VisualStudio.TestTools.UnitTesting;
PrivateObject po = new PrivateObject(new TestClass());
po.Invoke('PrivateMethodName'); /*This will invoke the private method*/
po.GetField('PrivateFieldName'); /*This will get the value of a private variable*/


Posted in Unit Testing, YShahin | Leave a Comment »

Nunit vs MsTest

Posted by archworx on June 10, 2007

After doing a lot some investigations and trying it for ourselves, we came to the conclusion that its better for us to use Nunit instead of using Mstest (the automated unit tests generated by Visual Studio 2005). Of coarse that’s not a general rule, depends of the project and your environment, but in most of our projects, we prefer Nunit for the following reasons

  1. It’s an open standard
  2. Works on all versions of Visual Studio, whereas MsTest only works with Team system or VSTS
  3. Much easier to integrate with Cruise Control (our continuous integration server)
  4. More suited for test driven development cause it allows you to start by coding the tests, whereas the main benefit of MsTest is that it can generates test stubs from your code.

Decide based on your project.

Posted in Continuous Integration, Extreme Programming, Nader | Leave a Comment »

Developing Reusable .NET Components

Posted by archworx on June 10, 2007

Hello All,

I have been developing Custom ASP.NET Server Controls for a while now and I think it is worthwhile to write a series of blog posts about how to develop them. So here we go with the first introductory blog. First, let us think why developing .NET components is important. Well, first of all Microsoft has developed a decent set of components and controls for the .NET framework, but surely these preexisting components don’t fit every scenario that you might need when you are developing your application, so this is why creating new components (or extending existing ones) is needed. More importantly it is the concept of reusability that particularly makes developing such components useful. Identifying certain recurring scenarios and common functionalities and developing a certain component that can be reused by yourself and others without having to re-write the same code again is very valuable. A friend of mine has recently told me that “A good developer only writes code once”. This proverb, albeit an oversimplification, captures the essence of reusability. Great, so what implications does this have on you as a developer? Well, being able to capture repetitive scenarios into reusable code is very important. So next time you write code try to think if you have written this code before (or if you are going to write it again in the future) and if so then you can try to encapsulate it into a component that can be reused (even if this means creating a simple code snippet). This doesn’t only apply to code that you write, but if you are smart enough you can identify recurring patterns inside applications that your organization is developing and hence suggest how reusable components can be used within the company to improve the development process. So, with this introduction over we will turn to talking about Custom Controls in .NET and how they differ from User Controls. But alas, this will have to wait till the next blog.

Posted in .NET 2.0, AFathalla, Programming, Reusable Components | Leave a Comment »

MsTest working in CruiseControl.Net

Posted by archworx on June 6, 2007

I’ve trying to get MsTest, the unit tests generated by Visual Studio 2005, to work with cruise control for a while now. So finally I was able to get it to work following these steps below 

Let’s say we have a solution called ITT in the following path c:/ITT, first we’ll look at the ccnet config file, after you compile using the msbuild task, you have to call an exec task to execute the MsTests, but before that you have to delete the test results file because MsTest won’t run if the file is already there, we are doing this by calling a batch file to delete this test results file and also delete the temp folders created by MsTest. After that you have to merge the results file with build output so I can be displayed in the dashbaord.

 <project name=”ITT”>
      <intervalTrigger seconds=”100″ />

    <!– here you do the task to get the project from the source control –>
    <!–sourcecontrol type=”vss” autoGetSource=”true” applyLabel=”false”>

      <!– task to build the solution–> 
        <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>

        <!– call a batch file that deletes results.trx –>
        <!– this is required as MsTest will not create the file if it exists–>
        <!– the batch file also deletes the temp folders created by MsTest –> 
        <!– the exec task to execute the MsTest task –>
        <executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe</executable>
        <buildArgs>/testcontainer:\ITT\AnalysisLibTests\bin\Debug\AnalysisLibTests.dll /runconfig:localtestrun.testrunconfig /resultsfile:results.trx</buildArgs>

      <!–to get the test results in the dashboard we have to merge the results XML file –>
      <xmllogger />
      <email from=”CruiseControl” mailhost=”mail” includeDetails=”TRUE”>


The next step is to modify the dashboard config file to display the test results, first we update the dashboard.config file to include the MsTests details menu item and then we add the MsTest results summary to the main build page. The required xsl files are already included with ccnet, you can customize the xsl to fit your needs

    <xslFile>xsl\MsTestSummary.xsl</xslFile> <!– MsTest results summary in main page–>
    <xslFile>xsl\unittests.xsl</xslFile> <!– Nunit test results, can be removed if not required any more –>
 <buildLogBuildPlugin />
   <xslReportBuildPlugin description=”NUnit Details” actionName=”NUnitDetailsBuildReport” xslFileName=”xsl\tests.xsl” />
   <xslReportBuildPlugin description=”NUnit Timings” actionName=”NUnitTimingsBuildReport” xslFileName=”xsl\timing.xsl” />
   <xslReportBuildPlugin description=”MSTest Report” actionName=”MSTESTReport” xslFileName=”xsl\MsTestReport.xsl”/> <!– menu item –>
   <xslReportBuildPlugin description=”NAnt Output” actionName=”NAntOutputBuildReport” xslFileName=”xsl\NAnt.xsl” />
   <xslReportBuildPlugin description=”NAnt Timings” actionName=”NAntTimingsBuildReport” xslFileName=”xsl\NAntTiming.xsl” />
   <xslReportBuildPlugin description=”FxCop Report” actionName=”FxCopBuildReport” xslFileName=”xsl\FxCopReport.xsl” />
   <xslReportBuildPlugin description=”NCover Report” actionName=”NCoverBuildReport” xslFileName=”xsl\NCover.xsl” />
   <xslReportBuildPlugin description=”Simian Report” actionName=”SimianBuildReport” xslFileName=”xsl\SimianReport.xsl”/> 

 That’s all

Posted in Continuous Integration, Nader, VS 2005 | 3 Comments »

Visual Studio Team System Adventures – Architect Edition Designers

Posted by archworx on June 5, 2007

I got this question from someone about the Visual Designers in VSTS Enterprise Architect Edition, basically the person was confused with all the designers available and what each one does.

I decided to do a little explanation here, but first I would like to discuss the concept of VSTS Arch Edition. Basically the whole idea behind VSTS is to have Architects (Enterprise, Solution, Infrastructure), Developers, Quality Engineers, Configuration Managers, Project Managers all working together from the same IDE and to have the output of each role saved to a central server so that the whole team can collaborate and communicate easily.

Using VSTS the whole idea of the Architect who walks in, draws fancy diagrams, and lets the developers and project implementers handle the details is over. This type of collaboration helps verify that designs are implementable and keeps the architect in the picture as the design evolves towards implementation requirements.

VSTS Architects Edition:

This edition of Visual Studio is used by Architects to design the system, and communicate those designs with the other members of the team. The word Architect here is very generic, because in reality you can have lots of different types of Architects, each looking at the system from a different perspective.

The main roles and perspectives that are found in almost every software project are as follows:

  1. The Enterprise Architect:This person makes sure that the system being design acts as part of a bigger larger system that benefits the organization as a whole and that conforms to the organization’s standards. The main focus here would be integration with other systems and standards compliance including performance and messaging.
  2. The Infrastructure Architect:This person focuses mainly on the system Physical Architecture, so the diagrams produced would contain information like the number of servers, server configuration, locations, communication lines.
  3. The Solution Architect:The main focus here is the solution at hand; this person takes the input from the Enterprise and Infrastructure Architect and creates a solution that would fit in the Physical and Logical requirements of the entire system. The diagram produced would contain information like the Logical Architecture, the distinct system layers, and the communication points with other systems.


The Designers and how they fit in:

VSTS Architects Edition has a lot of designers that can be used to represent different views of the system. As mentioned above it is possible for each of the above roles to be performed by a different person which makes consolidating and validating these designs all the lot harder. VSTS makes this task so much easier by validating the diagrams against each other, hence allowing the Architects to work together and not to break each other’s designs.

I will mention the most important designers:

  1. Distributed System Designer
  2. Application Designer
  3. Class Designer
  4. Deployment Designer
  5. Logical Datacenter designer

In this posting I will basically answer the question about the Application Designer, I will post on each of the designers I mentioned here in coming posts.

Application Designer is used to design applications that can provide or use services within the scope of a Visual Studio solution. It is a designer mainly used for high level tasks.

I will explain some common scenarios for this tool :

1. If you have a visual studio solution and would like to reverse engineer it so you could see the different components and how they communicated Application Designer would be the tool to use.

2. You could also specify settings and constraints for my application like which protocol it would use to communicate with other services, and connection strings in the web.config.

3. You could define the databases and web services that communicate with my application.

4. You could specify a custom communication protocol that my application will use with windows communication foundation.

After designing your application, you would need to perform the following tasks:

1. Evaluate the application for deployment on the deployment production environment using the development configurations, this would help determine whether or not your logical design is compatible with your physical design.

2. Design parts of your system for reusability.

These are the main features of Application Designer, please post your comments if you there is anything that needs clarification and I will address them in my coming posts.

Posted in MSamy, Visual Studio Team System | Leave a Comment »

Generating Documentation for .NET assemblies using SandCastle

Posted by archworx on June 4, 2007

I was developing a Control Library for .NET 2.0 and wanted to generate neat looking documentation from XML tags that I had written in code. So I googled around for a bit until I found that you can use a tool called SandCastle to generate HTML documentation that could be transformed into CHM and HxS formats. Here are the steps you have to do:

1- Inside VS2005 right click your project in the Solution Explorer and choose ”Properties”.

2- Click “Build” tab, under “Ouput” make sure that you check the “XML documentation file” checkbox. Once you do so, you can fill in a textbox that specifies the path of where the XML file (that contains the tags you put in code) will be generated.

3- Download and Install HTML Help Workshop .

3- Download and Install SandCastle March 2007 CTP .

4- Download and Install SandCastle Help File Builder (A really cool project on CodePlex that provides a UI that utilizes Sandcastle to generate Help Files)

5- Use SandCastle Help file Builder to generate your documentation .

Voila, you’ve got a cool professional documentation for your .NET project

Posted in .NET 2.0, AFathalla, Documentation, VS 2005 | 5 Comments »