One of the great things about working for iMeta is the fact they encourage you to take professional qualifications. Not only this, they actually pay for it and give you time to study. As a result of this, I have now obtained my second Microsoft qualification, this time in WPF – rock on!

Overall the exam is not too difficult provided you have had experience working with WPF and have read this book from cover to cover - the vast majority of the questions are Xaml based so make sure you are comfortable with that side of things.

Good luck to all others wishing to take this exam.

Following on from my last post regarding Silverlight for business, I thought I would share a technique that enables code (and tests) to be shared between Silverlight and standard .Net components. Enjoy!

Key Concepts

The solution is structured to ensure it can target the Desktop .Net and Silverlight .Net runtimes concurrently. It is anticipated the majority of source can be shared across the platforms, though it is inevitable there will be some source that exists solely for either platform.

Folder Structure

• The root for the code is 'Source'.
• Each solution is isolated inside a folder beneath source. In the example above, the 'iMeta' solution is located within the 'iMeta' folder.
• Each solution folder has two branches for the different runtimes. (DotNet/Silverlight)
• Each project is kept in its own folder beneath the runtime branches.
• Unit Test projects are isolated beneath a 'Tests' folder. This will enable better management of check-in policies.

   

Solution Structure

• Solution folders isolate the different runtime branches. (.Net/Silverlight)
• A 'Tests' folder isolates unit tests from the main source branches.
• In general, the runtime branches should mirror each other, with the inclusion of the term 'Silverlight' in the assembly name. This enables you to easily identify which assemblies in a bin folder are Silverlight ones (otherwise they'll be called the same, have the same version, and reflector will show they have the same code!)

Project Structure

Assembly Name and Namespace

• Mirrored assemblies share the same namespace, but not the same assembly name.
  • As MSBuild dumps built assemblies in the same location, without customising the project files it is not possible to isolate the different platforms into separate folders and so the same-named-assemblies would overwrite each other. Customising the project files would require deploying a ProjectItemTemplate to team members for each project type. This would inevitably be an annoying error prone step.

     

  • As stated above, it is just easier to name the Silverlight assemblies something different so you can identify them.

Signing

• The key for signing assemblies resides in the solution folder, and is added to the solution as a Solution Item.

• Each project references the key as a link and signs against this reference.

Code Sharing

• Projects that mirror each other should share code. Although Desktop.Net and Silverlight.Net cannot share assembly references, they can share source code.
• To share code, 'Add Existing Item', navigate to where the shared code primarily exists, and 'Add as Link'.
• By default, Silverlight projects define a SILVERLIGHT constant which can be used for conditional compilation.

Test Sharing

• In a similar manner to sharing code, Test code can also be shared via 'Add Existing Item'-> 'Add as Link'.

NOTE: One thing to bear in mind when creating unit tests for the Silverlight class libraries is that there is no integrated unit testing framework for Silverlight. Instead you have to create a 'Silverlight Test Application'. The project template and binaries for the Silverlight unit testing framework can be found here.

For our purposes, we placed a copy of those binaries in our 'External' folder for the Silverlight branch so other developers on a project can find them easily.

Continuous Integration

Silverlight Unit tests will not run in CI builds due to lack of integration support from Microsoft, though there is a rumour this will be included in a future release. In the meantime, running the Silverlight test suite can be a manual task that is achieved by launching the test project. Alternatively, if you have some spare time, there is a workaround to get it running on your build server. Needless to say, all tests that pass in the Desktop.Net branch should also pass in the Silverlight.Net branch.

Today, a Silverlight demo we developed became available on the Microsoft Silverlight Showcase. The purpose of our demo is not to show how wizzy a video stream can be, nor is it to demonstrate a wacky or futuristic UI; it is simply a practical demonstration of a business application developed using Silverlight. It combines the paper based form, guidance and calculations found on the UK HM Revenue & Customs site.

Please feel free to have a look!

DISCLAIMER! The application is for demonstration purposes only and should not be used when submitting an SA970 to UK HM Revenue and Customs.

Recently I set up a new TFS project using the Scrum for Team System Template, and spotted a bit of a problem whilst scouring the log for a broken build:

Done executing task "CreateNewWorkItem" -- FAILED.
...
...
...

C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(1422,5,1422,5): warning : TF42097: A work item could not be created due to a field error. The following fields have incorrect values: Field: 'Reason' Value: 'Build Failure'

C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: The "CreateNewWorkItem" task failed unexpectedly.

C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: Microsoft.TeamFoundation.Build.Tasks.TaskException: TF42097: A work item could not be created due to a field error. The following fields have incorrect values: Field: 'Reason' Value: 'Build Failure' --->
...
...

MSBuild was unable to create a new work item about the broken build. The problem lies in the TFSBuild.proj file produced when creating a build definition – it always assumes there is a 'Reason' field it can write to when creating a work item:

<WorkItemFieldValues>System.Reason=Build Failure; ...

The solutuion is simply to remove the field assignment ("System.Reason=Build Failure;") from the list.