Day 2- Continued

Routed Events

Routed events are events which navigate up or down the visual tree acording to their RoutingStrategy. The routing strategy can be bubble, tunnel or direct. You can hook up event handlers on the element that raises the event or also on other elements above or below it by using the attached event syntax: Button.Click="Button_Click".

Routed events normally appear as pair. The first is a tunneling event called PreviewMouseDown and the second is the bubbling called MouseDown. They don't stop routing if the reach an event handler. To stop routing then you have to set e.Handled = true;

Tunneling The event is raised on the root element and navigates down to the visual tree until it reaches the source element or until the tunneling is stopped by marking the event as handeld. By naming convention it is called Preview... and appears before corresponding bubbling event.

Bubbling The event is raised on the source element and navigates up to the visual tree until it reaches the root element or until the bubbling is stopped by marking the event as handled. The bubbling event is raised after the tunneling event.

Direct The event is raised on the source element and must be handled on the source element itself. This behavior is the same as normal .NET events.

How to Create a Custom Routed Event

// Register the routed event

public static readonly RoutedEvent SelectedEvent = 

    EventManager.RegisterRoutedEvent( "Selected", RoutingStrategy.Bubble, 

    typeof(RoutedEventHandler), typeof(MyCustomControl));

// .NET wrapper

public event RoutedEventHandler Selected

{

    add { AddHandler(SelectedEvent, value); } 

    remove { RemoveHandler(SelectedEvent, value); }

}

// Raise the routed event "selected"

RaiseEvent(new RoutedEventArgs(MyCustomControl.SelectedEvent));

 Day 2 Over

Day 2- Continued

Dependency Properties:

When you begin to develop appliations with WPF, you will soon stumble across DependencyProperties. They look quite similar to normal .NET properties, but the concept behind is much more complex and powerful.

The main difference is, that the value of a normal .NET property is read directly from a private member in your class, whereas the value of a DependencyProperty is resolved dynamically when calling the GetValue() method that is inherited from DependencyObject.

When you set a value of a dependency property it is not stored in a field of your object, but in a dictionary of keys and values provided by the base class DependencyObject. The key of an entry is the name of the property and the value is the value you want to set.

The advantages of dependency properties are

• Reduced memory footprint
  It's a huge dissipation to store a field for each property when you think that over 90% of the properties of a UI control typically stay at its initial values. Dependency properties solve these problems by only store modified properties in the instance. The default values are stored once within the dependency property.
  
• Value inheritance
  When you access a dependency property the value is resolved by using a value resolution strategy. If no local value is set, the dependency property navigates up the logical tree until it finds a value. When you set the FontSize on the root element it applies to all textblocks below except you override the value.
  
• Change notification
  Dependency properties have a built-in change notification mechanism. By registering a callback in the property metadata you get notified, when the value of the property has been changed. This is also used by the databinding.

Day 2- Continued

Logical- and Visual Tree


Introduction

Elements of a WPF user interface are hierarchically related. This relation is called the LogicalTree. The template of one element consists of multiple visual elements. This tree is called the VisualTree. WPF differs between those two trees, because for some problems you only need the logical elements and for other problems you want all elements.


<Window>
    <Grid>
        <Label Content="Label" />
        <Button Content="Button" />
    </Grid>
</Window>


Why do we need two different kind of trees?

A WPF control consists of multiple, more primitive controls. A button - for example - consists of a border, a rectangle and a content presenter. These controls are visual children of the button.
When WPF renders the button, the element itself has no appearance, but it iterates through the visual tree and renders the visual children of it. This hierarchical relation can also be used to do hit-testing, layout etc.
But sometimes you are not interested in the borders and rectangles of a controls' template. Particulary because the template can be replaced, and so you should not relate on the visual tree structure! Because of that you want a more robust tree that only contains the "real" controls - and not all the template parts. And that is the eligibility for the logical tree.

The Logical Tree

The logical tree describes the relations between elements of the user interface. The logical tree is responsible for:

Inherit DependencyProperty values
Resolving DynamicResources references
Looking up element names for bindings
Forwaring RoutedEvents
The Visual Tree

The visual tree contains all logical elements including all visual elements of the template of each element. The visual tree is responsible for:
Rendering visual elements
Propagate element opacity
Propagate Layout- and RenderTransforms
Propagate the IsEnabled property.
Do Hit-Testing
RelativeSource (FindAncestor)
Programmatically Find an Ancestor in the Visual Tree

If you are a child element of a user interface and you want to access data from a parent element, but you don't know how many levels up that elemens is, it's the best solution to navigate up the tree until it finds an element of the requested type.

This helper does excactly this. You can use almost the same code to navigate through the logical tree.


public static class VisualTreeHelperExtensions
{
    public static T FindAncestor<T>(DependencyObject dependencyObject)
        where T : class
    {
        DependencyObject target = dependencyObject;
        do
        {
            target = VisualTreeHelper.GetParent(target);
        }
        while (target != null && !(target is T));
        return target as T;
    }
}


The following example shows how to use the helper. It starts at this and navigates up the visual tree until it finds an element of type Grid. If the helper reaches the root element of the tree, it returns null.


var grid = VisualTreeHelperExtensions.FindAncestor<Grid>(this);

Day 2 - Concepts of WPF

Introduction to XAML

XAML stands for Extensible Application Markup Language. Its a simple language based on XML to create and initialize .NET objects with hierarchical relations. Altough it was originally invented for WPF it can by used to create any kind of object trees.

Today XAML is used to create user interfaces in WPF, Silverlight, declare workflows in WF and for electronic paper in the XPS standard.

All classes in WPF have parameterless constructors and make excessive usage of properties. That is done to make it perfectly fit for XML languages like XAML.

Advantages of XAML

All you can do in XAML can also be done in code. XAML ist just another way to create and initialize objects. You can use WPF without using XAML. It's up to you if you want to declare it in XAML or write it in code. Declare your UI in XAML has some advantages:

XAML code is short and clear to read

Separation of designer code and logic

Graphical design tools like Expression Blend require XAML as source.

The separation of XAML and UI logic allows it to clearly separate the roles of designer and developer.

XAML vs. Code

As an example we build a simple StackPanel with a textblock and a button in XAML and compare it to the same code in C#.

 

<StackPanel>

    <TextBlock Margin="20">Welcome to the World of XAML</TextBlock>

    <Button Margin="10" HorizontalAlignment="Right">OK</Button>

</StackPanel>

 

The same expressed in C# will look like this:

 // Create the StackPanel

StackPanel stackPanel = new StackPanel();

this.Content = stackPanel;

 

// Create the TextBlock

TextBlock textBlock = new TextBlock();

textBlock.Margin = new Thickness(10);

textBlock.Text = "Welcome to the World of XAML";

stackPanel.Children.Add(textBlock);

 

// Create the Button

Button button = new Button();

button.Margin= new Thickness(20);

button.Content = "OK";

stackPanel.Children.Add(button);

 

 

As you can see is the XAML version much shorter and clearer to read. And that's the power of XAMLs expressiveness.

Properties as Elements

Properties are normally written inline as known from XML <Button Content="OK" />. But what if we want to put a more complex object as content like an image that has properties itself or maybe a whole grid panel? To do that we can use the property element syntax. This allows us to extract the property as an own chlild element.

 

<Button>

  <Button.Content>

     <Image Source="Images/OK.png" Width="50" Height="50" />

  </Button.Content>

</Button>

 

 

Implicit Type conversion

A very powerful construct of WPF are implicit type converters. They do their work silently in the background. When you declare a BorderBrush, the word "Blue" is only a string. The implicit BrushConverter makes aSystem.Windows.Media.Brushes.Blue out of it. The same regards to the border thickness that is beeing converted implicit into a Thickness object. WPF includes a lot of type converters for built-in classes, but you can also write type converters for your own classses.

 

<Border BorderBrush="Blue" BorderThickness="0,10">

</Border>

 

Markup Extensions

Markup extensions are dynamic placeholders for attribute values in XAML. They resolve the value of a property at runtime. Markup extensions are surrouded by curly braces (Example: Background="{StaticResource NormalBackgroundBrush}"). WPF has some built-in markup extensions, but you can write your own, by deriving fromMarkupExtension. These are the built-in markup extensions:

Binding

To bind the values of two properties together.

StaticResource

One time lookup of a resource entry

DynamicResource

Auto updating lookup of a resource entry

TemplateBinding

To bind a property of a control template to a dependency property of the control

x:Static

Resolve the value of a static property.

x:Null

Return null

The first identifier within a pair of curly braces is the name of the extension. All preciding identifiers are named parameters in the form of Property=Value. The following example shows a label whose Content is bound to the Text of the textbox. When you type a text into the text box, the text property changes and the binding markup extension automatically updates the content of the label.

 

<TextBox x:Name="textBox"/>

<Label Content="{Binding Text, ElementName=textBox}"/>

 Namespaces

At the beginning of every XAML file you need to include two namespaces.

The first is http://schemas.microsoft.com/winfx/2006/xaml/presentation. It is mapped to all wpf controls inSystem.Windows.Controls.

The second is http://schemas.microsoft.com/winfx/2006/xaml it is mapped to System.Windows.Markup that defines the XAML keywords.

The mapping between an XML namespace and a CLR namespace is done by the XmlnsDefinition attribute at assembly level. You can also directly include a CLR namespace in XAML by using the clr-namespace: prefix.

 <Window xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”

        xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”>

</Window>

 

 

Learn WPF in one Week

First Day: 


Before start learning WPF first we should know about OOPS ,XMLand C# 

Topic 1: WPF Development Tools

Microsoft provides two development tools for WPF applications. One is Visual Studio, made for developers and the other isExpression Blend made for designers. While Visual Studio is good in code and XAML editing, it has a rare support for all the graphical stuff like gradients, template editing, animation, etc. This is the point where Expression Blend comes in. Blend covers the graphical part very well but it has (still) rare support for code and XAML editing.So the conclusion is that you will need both of them.

Microsoft Visual Studio 2010

Visual Studio is the tool for developers to develop WPF applications. It includes a graphical designer for WPF since version 2008. If you're using Visual Studio 2005 you can install an add-on that enables you to develop WPF applications

Topic 2: Introduction to Windows Presentation Foundation

Overview

The Windows Presentation Foundation is Microsofts next generation UI framework to create applications with a rich user experience. It is part of the .NET framework 3.0 and higher.

WPF combines application UIs, 2D graphics, 3D graphics, documents and multimedia into one single framework. Its vector based rendering engine uses hardware acceleration of modern graphic cards. This makes the UI faster, scalable and resolution independent.

The followinig illustration gives you an overview of the main new features of WPF

Separation of Appearance and Behavior

WPF separates the appearance of an user interface from its behavior. The appearance is generally specified in the Extensible Application Markup Language (XAML), the behavior is implemented in a managed programming language like C# or Visual Basic. The two parts are tied together by databinding, events and commands. The separation of appearance and behavior brings the following benefits:

Appearance and behaviour are loosely coupled

Designers and developers can work on separate models.

Graphical design tools can work on simple XML documents instead of parsing code.

Rich composition

Controls in WPF are extremely composable. You can define almost any type of controls as content of another. Although these flexibility sounds horrible to designers, its a very powerful feature if you use it appropriate. Put an image into a button to create an image button, or put a list of videos into a combobox to choose a video file.

<Button>

    <StackPanel Orientation="Horizontal">

        <Image Source="speaker.png" Stretch="Uniform"/>

        <TextBlock Text="Play Sound" />

    </StackPanel>

</Button>

Highly customizable

Because of the strict separation of appearance and behavior you can easily change the look of a control. The concept of styles let you skin controls almost like CSS in HTML. Templates let you replace the entire appearance of a control.

Resolution independence

All measures in WPF are logical units - not pixels. A logical unit is a 1/96 of an inch. If you increase the resolution of your screen, the user interface stays the same size - if just gets crispier. Since WPF builds on a vector based rendering engine it's incredibly easy to build scaleable user interfaces.

How to create a simple WPF application

Topic 3:How to create a simple WPF application

In Visual Studio 2008

1) Open Visual Studio 2008 and choose "File", "New", "Project..." in the main menu. Choose "WPF Application" as project type.

Choose a folder for your project and give it a name. Then press "OK"

2) Visual Studio creates the project and automatically adds some files to the solution. A Window1.xaml and an App.xaml. The structure looks quite similar to WinForms, except that the Window1.designer.cs file is no longer code but it's now declared in XAML as Window1.xaml




3)Open the Window1.xaml file in the WPF designer and drag a Button and a TextBox from the toolbox to the Window

4)Select the Button and switch to the event view in the properties window (click on the little yellow lightning icon). Doubleclick on the "Click" event to create a method in the codebehind that is called, when the user clicks on the button.

Note: If you do not find a yellow lightning icon, you need to install the Service Pack 1 for VisualStudio on your machine. Alternatively you can doubleclick on the button in the designer to achieve the same result.

5)The textbox has automatically become assigned the name textBox1 by the WPF designer. Set text Text to "Hello WPF!" when the button gets clicked and we are done! Start the application by hit [F5] on your keyboard

I hope First Day Over 

Cruce Control.Net(CC.NET) for Visual Studio 2008/2010 or SVN

Introduction to CC.NET:

CruiseControl.NET (CCNet) consists of a suite of applications, but at its core is the CruiseControl.NET Server which is an automated integration server.
The Server automates the integration process by monitoring the team's source control repository directly. Every time a developer commits a new set of modifications, the server will automatically launch an integration build to validate the changes. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not.
Effectively, integration becomes as easy as checking in code. Using an automated integration server not only makes integration easy, it also guarantees that an integration build will happen. There is no danger of developers forgetting to validate their changes after checking in.
The CCNet Server offers several key features:

• Integration with a variety of Source Control systems
• Integration with other external tools, such as NAnt and Visual Studio
• Can build multiple projects on one server

Installation Prerequisites:

To get CruiseControl.NET server up and running, you need to have the following environments set up and installed:

• Microsoft.NET Framework Version 2.

Installation Instruction:

1. CC.NET 1.4.2 can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=71179&package_id=83198
2. By default CC.NET gets installed in {Program Files}\ CruiseControl.NET which in turn contains 3 subfolders i.e. Examples, server and webdashboard.

1) Copy the ccnet.vsts.plugin.dll assembly into the server directory for CCNET. 

2) Configure ccnet.config to referece VSTS for source control.  You will need something like this:-     However, for full details on configuring the plug-in see

                  <sourcecontrol type="vsts">

                    <server>my_team_foundation_server</server>

                    <project>$/Foobar</project>

                    <workingDirectory>c:\projects\Foobar</workingDirectory>

                  </sourcecontrol>

http://confluence.public.thoughtworks.org/display/CCNET/Visual+Studio+Team+Foundation+Server+Plugin

3) Restart ccnet and enjoy.

NOTE:

To get the source to compile / run you need the following assemblies installed on the machine (If you have Team Explorer

installed on that machine then they will already be present).

Microsoft.TeamFoundation.Client.dll

Microsoft.TeamFoundation.Common.dll

Microsoft.TeamFoundation.Common.Library.dll

Microsoft.TeamFoundation.dll

Microsoft.TeamFoundation.VersionControl.Client.dll

Microsoft.TeamFoundation.VersionControl.Common.dll

Microsoft.TeamFoundation.VersionControl.Common.Integration.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.Provision.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.QueryLanguage.dll

Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine.dll

Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll

These will be in your GAC if you have the Visual Studio 2005 Team Explorer client installed on your machine

 - otherwise you'll need to copy them from one that does.  If you don't want to install the

Team Foundation Client on your build machine then you must copy the assemblies above into

the CCNET server directory along with the ccnet.vsts.plugin.dll

Good luck.

Configuration settings:

Instead of writing build scripts to support Continuous Integration, main configuration task in getting an instance of CruiseControl.NET running for your project is editing the Server's configuration file. This is defined in an XML file which by default is called ccnet.config in the same directory as the server application. By default, the server watches this file for updates and reloads it if the file changes.

ccnet.config example:

<cruisecontrol>

<project name="RiskModel4">

   

   

    <sourcecontrol type="svn">

<server>my_team_foundation_server</server>

<project>$/Foobar</project>

      <workingDirectory>{RM working Dir}</workingDirectory>

      <executable>{Program Files}\VisualSVN\bin\svn.exe</executable>

      <username>username</username>

      <password>password</password>

    </sourcecontrol>

   

    <triggers>

      <intervalTrigger name="Subversion" buildCondition="IfModificationExists" />

    </triggers>

    <tasks>

     

      <msbuild>

        <executable>{WINDOWS}\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe

        </executable>

        <workingDirectory>{AppTier working Dir}</workingDirectory>

        <projectFile>{ AppTier working Dir}\.sln</projectFile>

        <buildArgs>/noconsolelogger /v:quiet /p:Configuration=Debug</buildArgs>

        <targets>Build</targets>

        <logger>{CC.NET Path}\server\ThoughtWorks.CruiseControl.MSBuild.dll</logger>

      </msbuild>

     

       <exec>

        <executable>{ AppTier working Dir}\RunTests.bat</executable>

        <baseDirectory>{ AppTier working Dir}</baseDirectory>

       </exec>

     </tasks>

   <publishers>

      <merge>

        <files>

          <file>C:\testResults.trx</file>

        </files>

      </merge>

 <email from="buildmaster@mycompany.com" mailhost="smtp.mycompany.com" mailport="25>

<includeDetails>True</includeDetails>

    <users>

        <user name="BuildGuru" group="buildmaster" address="buildguru@mycompany.com"/>

        <user name="Developer" group="developers" address="edeveloper@thoughtworks.com"/>

    </users>

    <groups>

        <group name="developers" notification="Failed"/>

        <group name="buildmaster" notification="always"/>

    </groups>

    </publishers>

  </project>

</cruisecontrol>

1 The root tag in the Server Configuration file is the <cruisecontrol> tag

2. A <project> block defines the entire configuration for one project running in a CruiseControl.NET server.

3. name attribute defines the name of the project - this must be unique for any given CruiseControl.NET server

4 <workingDirectory> defines the Working Directory for the project (this is used by other blocks). Relative paths are relative to a directory called the project Name in the directory where the CruiseControl.NET server was launched from. The Working Directory is meant to contain the checked out version of the project under integration. This folder is unique per project to prevent problems with the build.

5 <artifactDirectory> defines the Artifact Directory for the project (this is used by other blocks). Relative paths are relative to a directory called the project Name in the directory where the CruiseControl.NET server was launched from. The Artifact Directory is meant to be a persistence location for anything you want saved from the results of the build, e.g. build logs, distributable, etc. Make sure this folder us unique per project to prevent problems with reporting about a build.

6. type attribute specifies the type of Source Control E.g. - SVN

<trunkUrl> specifies the location of the SVN home directory. The pathname can be either absolute or relative to the project artifact directory.

<executable> specifies the path to the svn.exe.

<login> specifies the user login for source control

< password> specifies the password for source control

7 <triggers> Trigger blocks allow you to specify when CruiseControl.NET will start a new integration cycle.Typically; you'll want to use an Interval Trigger. Also useful is the Schedule Trigger for implementing daily builds.Use the Filter Trigger to prevent builds from occurring at certain times (such as when your source control repository is undergoing backup).
If you want to set up a project that will only respond to force build requests, you should specify an empty trigger section like this: <triggers/>.

buildCondition attribute specifies the trigger condition. E.g. IfModificationExists

Types of Integration Trigger Block are:

• Filter Trigger
• Interval Trigger
• Multiple Trigger
• Project Trigger
• Schedule Trigger
• Url Trigger

NOTE: Like all triggers, the filterTrigger must be enclosed within a triggers element in the appropriate Project Configuration Block

Filter Trigger:

The Filter Trigger allows you to prevent builds from occurring at certain times or on certain days (such as when your source control repository is undergoing backup). It is used to decorate an existing trigger. For example, if you have set up a Interval Trigger to cause a new build every 5 minutes, you can use the Filter Trigger to create a window during which the build will not run.

Example:

<filterTrigger startTime="23:30" endTime="23:45">

    <trigger type="intervalTrigger" seconds="60" />

    <weekDays>

        <weekDay>Sunday</weekDay>

    </weekDays>

</filterTrigger>

This trigger suppresses builds if any modifications are made between 23:30 and 23:45 on Sunday nights.

Interval Trigger:

The Interval Trigger is used to specify that an integration should be run periodically, after a certain amount of time. By default, an integration will only be triggered if modifications have been detected since the last integration. The trigger can also be configured to force a build even if no changes have occurred to source control.

Example:

<intervalTrigger name="continuous" seconds="30" buildCondition="ForceBuild"/>

 Multiple Trigger:

The Multiple Trigger is used to support the execution of multiple nested triggers. Each trigger will be executed sequentially in the order specified in the configuration file. By default, if any of the triggers specify that a build should occur then a build will be triggered. The build condition will be ForceBuild if any trigger returns a ForceBuild condition. Otherwise, the build condition will be IfModificationsExist if any trigger returns that condition. Multiple Triggers can contain nested multiple triggers.

Example:

<multiTrigger operator="And">

        <triggers>

            <intervalTrigger />

            <filteredTrigger startTime="23:30" endTime="23:45" />

        </triggers>

    </multiTrigger>

Project Trigger:

The Project Trigger is used to trigger a build when the specified dependent project has completed its build. This trigger can help you split your build process across projects and servers. For example, you could have a CCNet project that will trigger the regression test suite once the main development build has completed successfully. This dependent build could be running on either a local or a remote CCNet server.

Example:

<projectTrigger serverUri="tcp://server:21234/CruiseManager.rem" project="Server">

    <triggerStatus>Success</triggerStatus>

    <innerTrigger type="intervalTrigger" seconds="30" buildCondition="ForceBuild"/>

</projectTrigger>

Schedule Trigger:

The Schedule Trigger is used to specify that an integration should be run at a certain time on certain days. By default, an integration will only be triggered if modifications have been detected since the last integration. The trigger can be configured to force a build even if have occurred to source control.

Example:

<scheduleTrigger time="23:30" buildCondition="ForceBuild" name="Scheduled">

    <weekDays>

        <weekDay>Monday</weekDay>

    </weekDays>

</scheduleTrigger>

Url Trigger:

The Url Trigger is used to trigger a CCNet build when the page at a particular url changes. The Url Trigger will poll the specified url according to a configured polling interval to detect if the last modified date of the page has changed since the last integration.

This trigger is especially useful in reducing the load on your source control system caused by the polling for modifications performed by an Interval Trigger. If your source control system supports trigger scripts (such as the use of commitinfo scripts in CVS), you can use create a trigger to touch the page that is being monitored by CCNet to start a new integration.

Example:

<urlTrigger url="http://server/page.html" seconds="30" buildCondition="ForceBuild"/>

8. <tasks> Tasks Blocks are the action elements of CruiseControl.Net. They're the elements that do things, like executing a program, running tests, or send email results.

<msbuild> block used to execute MsBuild projects, which are the default project format for Visual Studio 2005 projects and can also be compiled by using the MSBuild application that ships with the .NET 2 Framework.

<executable> The location of the MSBuild.exe
< workingDirectory > The directory to run MSBuild in - this is generally the directory containing your build project. If relative, is a subdirectory of the Project Working Directory

<projectFile> defines the name of the build project to run, relative to the workingDirectory.

< buildArgs> defines Any extra arguments to pass through to MSBuild

< targets > A semicolon-separated list of the targets to run

<logger> The full path to the assembly containing the custom logger to use. Arguments can be passed to the logger by appending them after the logger name separated by a semicolon.

9 <exec> block defines related to Unit test files

 <executable> defines bat file path E.g.{Project working Dir}\RunTests.bat

<baseDirectory> block defines path of working Dir.

The RunTests.bat contains following commands

del C:\results.xml

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\MSTest.exe" /testcontainer:D:\BackUP\RMSubVertion\RiskModel4\Test\bin\x86\Debug\Test.dll /resultsfile:C:\results.xml

This basically deletes the results.xml which is created by the MSTest.exe each time it runs to avoid appending the file.

Then run the MSTest.exe with the Test.dll as input.

10 First we need to merge the results.xml file to the build log. To do that, update the publishers section of the ccnet.config file as given below

<publishers> 

    <merge>

    <files>

        <file>{WorkingDirectory}\results.xml</file>

    </files> 

    </merge>

    ... 

</publishers> 

Then modify the ccservice.exe.config (or ccnet.exe.config if you use ccnet.exe instead of the ccservice) file by modifying the xslFiles section as given below:

<xslFiles>

    <file name="xsl\header.xsl"/>

    <file name="xsl\compile.xsl"/>

    <file name="xsl\mstestsummary.xsl"/>

    <file name="xsl\modifications.xsl"/>

</xslFiles>

In the above section, removed the unittests.xsl which is there by default and added mstestsummary.xsl instead.
Now we need to configure the Web dashboard. Open the dashboard.config file and update the buildPlugins section as given below:

   <buildPlugins>

      <buildReportBuildPlugin>

        <xslFileNames>

          <xslFile>xsl\header.xsl</xslFile>

          <xslFile>xsl\modifications.xsl</xslFile>

          <xslFile>xsl\compile.xsl</xslFile>

          <xslFile>xsl\MsTestSummary.xsl</xslFile>

          <xslFile>xsl\fxcop-summary.xsl</xslFile>

          <xslFile>xsl\NCoverSummary.xsl</xslFile>

          <xslFile>xsl\SimianSummary.xsl</xslFile>

          <xslFile>xsl\fitnesse.xsl</xslFile>

        </xslFileNames>

      </buildReportBuildPlugin>

      <buildLogBuildPlugin />

      <xslReportBuildPlugin description="MSTest Report" actionName="MSTESTReport" 

            xslFileName="xsl\MsTestReport.xsl"/>  

Again, removed the unittestsummary.xsl and added mstestsummary instead. The new xslReportBuildPlugin element causes a link to be displayed on the left side called “MSTest Report”, and when clicked it will display the detailed test results in a table.

11. The email publisher can be used to send email to any number of users. It is common to include one user who gets an email for every build and then also send email to every developer who checked code in for this build.

Note: Make sure that all of the [Merge Publisher]s, along with the Xml Log Publisher task are done before the <email> publisher, or else you won't be able to include output from the build in the email.
A common mistake is to put the email task in the <tasks> section instead of the <publishers> section.
If an error occurs in the <tasks> section, the remaining tasks in that section are skipped, and CC.Net goes right to the <publishers> section.So if you put the <email> tasks in the <tasks> section, you'll never get any failure messages.

<email from="buildmaster@mycompany.com" mailhost="smtp.mycompany.com" mailport="25" includeDetails="TRUE">

    <users>

        <user name="BuildGuru" group="buildmaster" address="buildguru@mycompany.com"/>

        <user name="JoeDeveloper" group="developers" address="joedeveloper@thoughtworks.com"/>

    </users>

    <groups>

        <group name="developers" notification="Failed"/>

        <group name="buildmaster" notification="always"/>

    </groups>

Using CC.Net

Server folder contains two executables i.e. ccnet.exe and ccservice.exe.

ccnet.exe

The ccnet.exe is a console application which can be used to debug the CC.Net before running as service.

ccservice.exe

Once console application is working fine, ccservice.exe. which is windows service can be run for continuous integration.