$counter = New-Object Diagnostics.PerformanceCounter;
$counter.CategoryName = “My_Category”;
$counter.CounterName = “Counter_1″;

$counter.ReadOnly = 0;

$counter.Increment();
$counter.Close();

A good read on performance counters can be found here:
http://msdn.microsoft.com/en-us/library/ff650681.aspx

First, start up Powershell from either the start menu (Start > Run > powershell) or if you have Windows 7, navigate to control Panel > Administrative tools and run it from there.

Next, create the script to setup and create counters: 

#Global variable definitions
$cntrColl

Write-Host “Remove category”;
if([Diagnostics.PerformanceCounterCategory]::Exists(“My_Category”)) {
 [Diagnostics.PerformanceCounterCategory]::Delete(“My_Category”);
}
$script:cntrColl = New-Object Diagnostics.CounterCreationDataCollection;

Write-Host “Add counter 1″;
$counter = New-Object Diagnostics.CounterCreationData;
$counter.CounterName = “Counter_1″;
$counter.CounterHelp = “Help for Counter_1″;
$counter.CounterType = [Diagnostics.PerformanceCounterType]::NumberOfItems64;
$script:cntrColl.Add($counter);

Write-Host “Add counter 2″;
$counter = New-Object Diagnostics.CounterCreationData;
$counter.CounterName = “Counter_2″;
$counter.CounterHelp = “Help for Counter_2″;
$counter.CounterType = [Diagnostics.PerformanceCounterType]::NumberOfItems64;
$script:cntrColl.Add($counter);

Write-Host “Add the counters to PerfMon”;
[Diagnostics.PerformanceCounterCategory]::Create(“My_Category”, “Help for category”, $script:cntrColl);

To check the counter has been created, start Performance Monitor (type perfmon in Powershell)

Over all the book is pretty good excluding the starting chapters in which the author goes into a rant and throws a few tantrums. However, a good number of worked examples are provided which are helpful to explain the theory and the rationale provided is sound.

The topics below are ordered such that the more obvious one are towards the back.

Why Clean Code?

Why should we bother writing clean code? Why not just live on a coding high (with Pepsi and Pizzas) and thrive under the pressure of delivering against all the odds? The real problem is maintaining a steady rate of delivery after systems have gone live. If code is messy it becomes harder to understand / debug. Eventually, everyone becomes afraid of making changes since they don’t want to break the system.

Writing Clean Code takes practice and time. As I’ve said to my colleagues, development is an ever evolving cycle of iterations, new techniques and improvements as time progresses.

Single Responsibility Principle (SRP)

Classes / modules should only have a single responsibility and only one reason to change. This is one of the simpler OO principles, yet is widely abused. e.g. Car

Car { Accelerate();

Break(); DisplayPassenger(); }

Method DisplayPassenger() is not a responsibility for Car and should reside separately. The key purpose of applying SRP is to produce focused, small classes that have a dedicated purpose. When the classes are named adequately, it becomes easy for the reader to digest what is happening. The alternative is to have fewer large classes that are more difficult for readers to comprehend.

Unit Tests (UT)

Unfortunately, UT has often taken a back seat in development, especially when there’s an extortionate amount of pressure to deliver something quickly. The massive danger is that once the system has gone live without UT, there will be no time to back fill those missing UTs. Another developer who has to make a change on the code base has no confidence indicator that the changes won’t break the system. This is where UT steps up – if you bake these in early, you have some level of confidence that other developers won’t break the system.

UTs should be FIRST:

• Fast – quick to run otherwise they won’t get run often
• Independent – test can run on it’s own with depending on other tests to pass
• Repeatable – deterministic results based on the same environment settings
• Self-validating – Simple success criteria, e.g. pass or fail
• Timely – If you follow TDD (Test Driven Development), then write the test just before writing the code

As the developer, you need to be sure your UT is comprehensive enough to ensure that another developer changing your class will fail the tests if something detrimental is implemented.

Methods

1. Method names should be meaningful and ideally contain a verb
2. Methods should be single purpose – only do one thing and then return
3. When a method relies on another method within the same class, the distance between the methods should be small, (to save the reader from endless scrolling / searching). This is known as the method density. Keeping the density high makes easier reading
4. Avoid passing more than 3 parameters into a single method.

Comments

There are a mixed set of views around the use of comments in code:

• On one side there is the agile group who say comments are necessary – write readable code
• On another side, e.g. JavaDoc, comments were done so religiously, comments were often stated the obvious
• From experience, I can recollect having to troubleshoot / change JavaScript code in files that were over 5,000 line of code and the only thing that saved me were the comments!

My recommendation would be to use comments sensibly and explain things that would be difficult for a reader to gauge the perspective / scenario. Care needs to be taken that comments don’t become out dated and then eventually misleading. This is one of the drivers against comments.

Variables

1. Variable names need to be meaningful, e.g. a, theItem or scd don’t mean anything to an external observer. Try things like account, itemsToCheck or secureCommunicationsDevice
2. Microsoft’s Hungarian notation is arguably bad, e.g. what if you changed the underlying data type? Would that also require variable name changes? That is the primary reason not to use.

   However, to contradict this, why are all Java / .Net interfaces prefixed with “I”?

3. Define a constant variable for integer values

4. Variable member prefix (m_) for class level variables is no longer required as the m_ is not essential information

Summary

Hopefully, this short summary was appealing enough for you to investigate this further.

When working with WCSF (Web Client Software Factory) from Microsoft Patterns and Practice, it can be confusing to why core parts of the frame work throw service missing exceptions, such as: ISiteMapBuilderService and IAuthorizationService

Microsoft.Practices.CompositeWeb.Interfaces.ISiteMapBuilderService is not available in the current context.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Microsoft.Practices.CompositeWeb.ServiceMissingException: Service Microsoft.Practices.CompositeWeb.Interfaces.ISiteMapBuilderService is not available in the current context.
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

 [ServiceMissingException: Service Microsoft.Practices.CompositeWeb.Interfaces.ISiteMapBuilderService is not available in the current context.]

   Microsoft.Practices.CompositeWeb.Collections.ServiceCollection.Get(Type serviceType, Boolean ensureExists) +377

 . . . 

As usual, everything else from P&P is really good, so it’s worth spending time to troubleshoot and sort these minor problems out.

Solution

To get round this problem, there are a couple of items which need changing.

The first part is to check the web.config files have the correct virtual path set in the <Module /> nodes. Further details on this have been blogged here:

http://kiranpatils.wordpress.com/tag/wcsf/

Sometimes after an IIS RESET or restart, you need to ensure that the load order of modules is consistent and that any threading issues are avoided. This is done simply by ensuring that the ShellModuleInitializer Load Method loads services in a synchronized manner using lock(this).

public class ShellModuleInitializer: ModuleInitializer

    public override void Load(CompositionContainer container)

      lock(this)

}

Exception stack trace:
Exception Source:      System.Data
Exception Type:        System.InvalidOperationException
Exception Message:     Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached.
Exception Target Site: GetConnection

Fortunately the solution is simple, you need to modify the connection string being passed to ADO / Enterprise Library Database block to include:

Min Pool Size=100;Max Pool Size=200

By default, these values are used:

Min Pool Size=0;Max Pool Size=100

As always, increase values slowly until the problems disappear as higher values for these will consume more resources on your server / client

Further reading:

http://aspalliance.com/1099_Understanding_Connection_Pooling_in_NET.all

The best way of avoiding failed installs is to run the .Net Clean up tool, which has been blogged about by various authors. A good one can be found here on MSDN

“The CLR has been unable to transition from COM context 0x1fafc8 to COM context 0x1fb138 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.”

For this application, the main UI thread executes some business logic (BL) wrapped inside an assembly. The BL spawns of a number of background worker threads which fetch data and perform calculations. The UI thread which executes the BL needs to consolidate the results in each thread before returning control back to the user.

Thus, the UI thread is held in a loop until all of the background threads complete.

while(isRunning())
{
    System.Threading.Thread.Sleep(1000);
}

If this takes longer than 60 seconds, then the ContextSwitchDeadlock exception arises as no Window messages have been pumped.

Fortunately there is an easy fix – you can pump Window messages by using this call:

System.Threading.Thread.CurrentThread.Join(1000);

Thus, for this specific problem, changing Thread.Sleep to Thread.CurrentThread.Join is sufficient to keep the application running without exceptions.

However, there are certain circumstances where this grid isn’t ready. This is what I intend to explain in this blog entry.

Requirements

For my current project, the primary requirements for the grid are listed below:

• Req1: Display information from a DataSet
• Req2: Correct formatting of numbers and dates, e.g. two decimal places or thousand separator or proper dates, e.g. 01/04/2009
• Req3: Columns are added dynamically at run time
• Req4: Copy data into Excel

Req1: Display information from a DataSet

This part is really easy, creating and binding the dataset works flawlessly in just a few line of code:

//put some information in a DataTable

DataTable dt = new DataTable();

dt.Columns.Add(“Mon”, typeof(float));

dt.Columns.Add(“Tue”, typeof(float));

float flt = 10.001F;

for (int nLoop = 0; nLoop < 10000; nLoop++)

{

  flt += 0.001F; // some increment to change values

  int nInt = Convert.ToInt32(flt) + nLoop + 1000;

  double dbl = (double)flt;

  dt.Rows.Add(flt + 1F, flt + 2F);

}

 

// Binding the DataTable to the Grid – easy stuff!

dataGrid1.ItemsSource = dt;

As with a previous blog, don’t forget to set the grid’s Virtualisation mode. Based on this above snippet, it’s straightforward to get things up and running quickly.

Req2: Correct formatting

Basically two approaches exist: XAML or code (C#). I tend to give preference to XAML and aim for less code intensive solutions

XAML

Essentially this is creating a DataTemplate to allow the column to apply the StringFormat method. While this is good being done at a column level, this does need the Path attribute set in the Binding expression to work correctly. For fixed DataSets, this is not a problem – however, if you add / remove columns from the underlying DataSet at runtime, then you can’t set the Path and StringFormat values in XAML.

Code

The simplest way is to get a call back from the Grid via the AutoGeneratedColumns property and place code in the event handler e.g.

AutoGeneratedColumns=”dataGrid1_AutoGeneratedColumns”

The event handler lets you execute code for formatting each time after you bind the columns via ItemsSource

//Change format as appropiate           
foreach (DataGridTextColumn dgtc in dataGrid1.Columns)
{
  Style rightAlignStyle = new Style(typeof(DataGridCell));

  Setter setter = new Setter();
  setter.Property = DataGridCell.HorizontalAlignmentProperty;
  setter.Value = HorizontalAlignment.Right;
  rightAlignStyle.Setters.Add(setter);

  dgtc.CellStyle = rightAlignStyle;

  //Depending on the column, set the format 
  dgtc.Binding.StringFormat = “{0:N0}”;

  dgtc.Binding.StringFormat = “{0:F2}”;
}

As you can see, 1 XAML line = several C# lines. A great article on styling the grid is XAML can be found at:

http://blogs.msdn.com/jaimer/archive/2009/01/20/styling-microsoft-s-wpf-datagrid.aspx

In addition, a good list of those formats can be found at idunno.org: http://idunno.org/archive/2004/14/01/122.aspx

Req3: Dynamic columns

Here’s where thing start to break and get complicated. Adding columns to the DataTable and re-attaching to the DataGrid’s ItemsSource is straight forward – the grid even shows the new columns with no problem.

The problem is formatting of those columns.

In XAML, unless you know all of the columns beforehand and simply hide them, then this is difficult to achieve. This would also lead to lots of XAML code if you have many columns.

Thus, at this point, the code solution is looking more promising as you can simply switch the format in the AutoGeneratedColumns event handler.

Req4: Copy to Excel

XAML

Selecting the rows when XAML is used works really well – you could click on any text or any white space in the grid and that row was selected. However, cells which have formatting applied (via TextBlock or StringFormat method) don’t automatically copy over to Excel.

Code

When the code solution is used, the selection of rows dramatically goes down in user experience – if you select any white space, the row isn’t selected, you have to click on the actual text.

Conclusion

What would be really nice is for the grid to allow some simple programmatic access that formats cells readily and not have some aspect break! I have found a good alternative, but don’t want to bias vendors, so drop me a line if you want the results.

Links

http://blogs.msdn.com/jaimer/archive/2009/01/20/styling-microsoft-s-wpf-datagrid.aspx

http://www.codeproject.com/KB/WPF/WPFDataGridExamples.aspx?msg=2883597

http://sweux.com/blogs/smoura/index.php/wpf/2009/06/15/wpf-toolkit-datagrid-part-iv-templatecolumns-and-row-grouping/

http://wpf.codeplex.com/Thread/View.aspx?ThreadId=61051

It’s definitely worth mentioning a recent problem encountered during development. When a custom built user control was being rendered by the Visual Studio designer an exception was being thrown. Interestingly the application runs with no problems and the control functions normally.

This is due to the fact that the control can’t determine who is the host – your application or the designer?

The control relied on the application configuration (app.config) being present and available for subsequent operations in the default constructor. Moving the code to an Loaded() event handler made no difference and designer exceptions were still thrown.

This means the designer is invoking both the default constructor and Loaded method (if available) – which is obvious when you think about it.

Solution

• Firstly put checks to see if all pre-requisites are available.
  • You may have to make the assumption that since the executable of the application is up and running, the config file must be present. Thus, if it’s not found by the control, exit the control’s constructor gracefully after a failed check
• If you are using Dependency Properties with the control (and you control the XAML file calling the control), you can place the offending code in the Set property method
  • A bit of care needs to be taken since the Dependency Property methods are static and you need access to the actual control instance
  • It’s good practice to have a call back handler for the property which was registered when the property was defined

• If possible create an overloaded constructor which takes parameters. This won’t get called by the designer and can be a safe haven.

Links

http://msdn.microsoft.com/en-us/library/bb546934.aspx

While binding a large dataset to the WPF Toolkit Grid, the performance may appear to be very slow and unresponsive while the Grid renders the data. At my clients site, we experienced around a 20 seconds or so delay to render one view! The Data Access layer and business objects were timed to be only 2 seconds, thus the remainder was being eaten up by the Grid.

Solution

The WPF ListBox and ListView both suffer performance problems when many items are loaded, since they attempt to render all of the elements on load, including non-visible ones. The solution for them is to create a VirtualizingStackPanel. This works well and has been documented in several blogs.

For the Grid the solution is similar but all you need to do is set some attributes.

EnableColumnVirtualization=”True”

EnableRowVirtualization=”True”

Note: In Visual Studio 2008, the RowVirtualisation may be ticked but not specified in the XAML. To ensure this gets used by the Grid, uncheck and then check RowVirtualisation .

After these two minor modifications, the Grid now renders in 4 seconds (remember 2 are lost on other layers)

Appendix – Other Grids

At the present moment, the WPF Toolkit Grid offered by Microsoft is fairly basic. when compared to SyncFusion and Exceed. In summary the Microsoft Grid lacks the UI wow factor that you expect from WPF. Key things to remember:

1. The Microsoft grid truly follows Microsoft’s strategy around data binding and datasets, while leaving the programmatic APIs in a weak state. This said, I think this is a good thing and encourages best practice.
2. In this current deep dark recession, the Microsoft Grid is FREE! However, still be cautious over how long you spend on making the Grid look and feel the way you want as the development cost can rapidly diminish the savings