Heading to 2010

Soon we will be in 2010... and microsoft gave us some early new years presents...

Currently playing around with:

• Team Foundation Server 2010
• Visual Studio 2010
• Sharepoint 2010
• Office 2010

All looks quite neat and some really cool features have been implemented... Top 5 things i like...
- Linked workitems in TFS
- Improved reporting in TFS
- Support for TDD in VSTS
- Improved support for sharepoint development in VSTS
- BCS in sharepoint 2010

Is code coverage usefull for measuring software quality?

There is a lot of debate going on how much percentage should be attained. But first however is code coverage a good measurement or quality? In my personal opinion it is very usefull if an historical trend is kept. if coverage drops over time this migt be an indicator of issues tha are arising somewhere else... not enough time, quick and dirty hacks,...

But how much is enough? this like almost everything in software development is offcourse it depends. I think it largely depends on the type of application you are building, if it is ver largely dependant on workflows and long running processes the significance is going to be less then when you are doing a lot of calculations. And offcourse code coverage does not cover 1 thing which is quite important and usually the root of all evil: missing requirements :)

Implementing INotifyPropertyChanged by using Unity Interception

This example uses Unity interception to be able to bind objects to a UI by just applying a [Notify] attribute to a property, this done by intercepting the call and propagating it to a INotifyPropertyChanged implementation.
From MSDN:
The INotifyPropertyChanged interface is used to notify clients, typically binding clients, that a property value has changed.

Step 1 create an abstract class that encapsulates all the functionality we need.
See below for a class diagram:


Step 2 create the handler:
NotifyPropertyChangedHandler which inherits from ICallHandler
public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext) {

IMethodReturn result = getNext()(input, getNext);

if (!input.MethodBase.Name.StartsWith("set_")) return result;
//Remov the set_ to get the property's name
var propertyName = input.MethodBase.Name.Remove(0, 4);
//invoke the modified property
//maybe we should check if the target is indeed o BindableOjectBase ;)
BindableObjectBase target = (BindableObjectBase)input.Target;
((IBindableObject)target).Modified(propertyName);
return result;
}

Step 3: Create the attribute
Create a NotifyPropertyChangedAttribute class which inherits from HandlerAttribute
create a default constructor:
public NotifyPropertyChangedAttribute() {
_CallHandler = new NotifyPropertyChangedHandler();
}

override the folowing method
public override ICallHandler CreateHandler(IUnityContainer container) {
return _CallHandler;
}
Step 4: Setting up the UnityContainer:
UnityContainer_Container = new UnityContainer();
//Registring interception extension
_Container.AddNewExtension();
_Container.RegisterInstance(instance);
_Container.Configure().SetDefaultInterceptorFor(new TransparentProxyInterceptor());
var object container.Resolve();

the last step took a little time to get it working the way I wanted since DI usually works by injecting interface implementations but this was not what I wanted to do. Since interfaces define behaviour and properties have nothing to do with behaviour but with state.

I will post the full source code later

call javascript form a sharepoint cutom toolbar

Here is a short code snippet which calls a javascript when you click a custom button in sharepoint. You should register the custom javascript through Page.ClientScript.

//Load the custom button
ToolBarButton printButton = (ToolBarButton)Page.LoadControl("~/_controltemplates/ToolBarButton.ascx");
printButton.ImageUrl = "~/layout/image/print.png";
//Here is where the magic happens
printButton.NavigateUrl = "javascript:PrintPage()";

ToolBar toolBar = (ToolBar)Page.LoadControl("~/_controltemplates/ToolBar.ascx");
toolBar.Buttons.Controls.Add(printButton);

Symptoms of Rotting Design

There are four primary symptoms that tell us that our designs are rotting. They are not
orthogonal, but are related to each other in ways that will become obvious. they are:
rigidity, fragility, immobility, and viscosity.
Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multiweek marathon of change in module after module as the engineers chase the thread of the change through the application.
When software behaves this way, managers fear to allow engineers to fix non-critical
problems. This reluctance derives from the fact that they don’t know, with any reliability, when the engineers will be finished. If the managers turn the engineers loose on such problems, they may disappear for long periods of time. The software design begins to take on some characteristics of a roach motel -- engineers check in, but they don’t check out.
When the manager’s fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.
Fragility. Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.
As the fragility becomes worse, the probability of breakage increases with time,
asymptotically approaching 1. Such software is impossible to maintain. Every fix
makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost.
Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
Viscosity of environment comes about when the development environment is slow
and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optiimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.

These four symptoms are the tell-tale signs of poor architecture. Any application that exhibits them is suffering from a design that is rotting from the inside out. But what causes that rot to take place?

Source: Robert C. Martin (http://www.objectmentor.com/)

How can we detect sofware rot before or while it is occuring? Under the motto "To prevent is better than to cure".
The problem is that software roth rarely shows on the short term. I like to compare it to building a house... you build the basement and you realise its not level but level enough for now since your scope is quite limited. When you start building the ground floor you notice that it the problem is becoming more eminent, if after a while you construct more and more floors you will notice that your apartment block will eventually collapse but by then its too late to do something about it.

Everybody knows this but how can we prevent this? I have seen this occur over and over again due to short term quick and dirty hacks and solutions because developers do nor succeed in managing expectations. The only thing you can be certain about in software is change! "It works for now" is imo the beginning of the end.

How can we prevent this? By applying the SOLID principles:

• SRP: Single Reponsibility Principle
• OCP: Open Closed Principle
• LSP: Liskov Substitution Principle
• ISP: Integration Segragation Principle
• DIP: Dependency Inversion Principle

For more information on this I would recommend Robert C. Martin's Agile Principles, Patterns and Practices in C#

Adding custom properties to Webparts in Sharepoint 2007

Apparently the syntax changed in MOSS 2007 to add custom properties to your web part in.

Code below:

[WebBrowsable(true)]
[WebDisplayName("Connection string:")]
[SPWebCategoryName("Data")]
[WebPartStorage(Storage.Shared)]
[WebDescription("Connectionstring")]
[Personalizable(PersonalizationScope.Shared)]
public string ConnectionString { get; set; }

Team Build: Setting up workspaces

One of the errors you might encounter whilst using team build is the following:

The specified path, file name, or both are too long. The fully qualified file
name must be less than 260 characters, and the directory name must be less than
248 characters.

The guide here below will help you to avoid these. But you should also keep in mind not to make your folder structure to complex or too deep. You can group your projects in your solution using solution folders which are not reflected in your physical project location.

Working Directory Build Agent
Set the working Directory for the Build Agent to a path that is not to long (e.g. C:\BuildWorkSpace\$(BuildDefinitionPath). Be aware to add the $(BuildDefinitionPath) variable in order for every build to be stored in a unique location.

Note: this will be replacing the $(SourceDir) variable. (see below)

Source Control Folder
Set the source control folder correctly to the folder containing the solution file.

See below for Solution structure. Te solution root is the parent folder where the solution resides.

Team Build: Strong naming assemblies and Team Build

This article provides a great Walkthrough for using strongly named assemblies and Team Build in combination with Automated Unit Testing.

http://ozgrant.com/2008/03/13/strong-name-your-assemblies-with-team-build-using-a-private-key/

One additional problem I came across though is when you are running x64 make sure you disable the strong name verification as wel in x64 and x86 consoles!

sn -Vr *,7f668b9f3b05cdd1

Team Build: Enabling Code Coverage without using a test list

Modify the Test Arguments PropertyGroup to contain the RunConfigFile tag and point it to the correct location



<RunConfigFile>$(SolutionRoot)\01 Dev\Sharpsolutions.SharpMoney\LocalTestRun.testrunconfig</RunConfigFile>


After you have enabled ofcourse the code coverage for the correct projects.

Team Build and Referenced Assemblies

This session I am going to give some tip how you should reference shared assemblies.

I am currently building an application that uses several things of Enterprise Library and RhinoMocks for unit testing. Now these references have to be made to fixed locations but this can impose problems when building from different machines (think build agents differebt developer machine setups).

What I did was on my build agent I shared the build folder and mapped a networkdrive to it (in my case s:\). then I created a structure like this:
Enltlib\latest\ to which I copied the complete bin directory from entlib. The big advantages is that if you decide to upgrade later you just rename the folder to v4.1 and create a new latest folder where you copy the latest binaries to. Like this everybody will always be referencing the latest binaries without having to redo all their references in their projects

The advantages of this approach is that its completely independent of your machine setup. And if you have to work offline from your TFS once in a while you just make sure you check out the latest version of your BuildStore share the drive on your local machine and map it to the same network drive and your projects will continue to build without having to redirect the references all the time.