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.

The Stuff of Nightmares

Today I came across what seemed like a real showstopper in SL2. I was attempting to add a TabControl to a UserControl. All seemed to work well in the designer, but at runtime I would get two fairly vague exceptions:

and..

The second exception clearly pointed to where I had added the TabControl, but didn't really tell me what was going on.

I was pretty sure I'd seen the TabControl working before, so I opened up a new solution and copied the Xaml over. Below are the snippets chopped out of both solutions – no real difference here, but strangely the isolated solution worked!

Isolated Solution (works):

Original Solution (throws exceptions):

The Solution

After a while I realized I had the exact same problem some weeks ago and is nothing to do with the TabControl – it is to do with references!

Isolated Solution (works)

Here, the TabControl (which needs System.Windows.Controls.Extended) is instantiated within the startup project.

Original Solution (throws exceptions)

See the problem?

It turns out the startup project is missing the reference to System.Windows.Controls.Extended. The original exception "The given key is not present in the dictionary" is about not being able to resolve the xmlns:my="clr-namespace:...;assembly=System.Windows.Controls.Extended reference in the Xaml from the entry point of the application.

Since this is the second time this has happened to me, I thought it would be worthy of a blog!

I have found on occasion the 3rd party apps on my phone fail to start properly - the splash may show for a second or so but then I get returned to the home screen.  It seems lots of other people are having the same problem.  From personal experience I have found two causes for the problem:

1) The iPhone has been connected to an iTunes library that has 'someone else' logged in.  In my case, I changed the email address my iTunes account was registered to.  (My phone then started trying to do things under my 'old account', or was perhaps confused that the apps were downloaded under account X but was now trying to authorise against account Y).

2) Bad firmware update experience.  Both times I have installed firmware updates third party apps have stopped working.

Looking across forums people suggests removing and re-installing the applications which is far from ideal.

A simple workaround that does not involve deleting the apps (and seems to work fine for me) is to download and install a free app from the store.  Once it has finished, the other apps should start working again.

To stop Word from spell checking your code (or any particular section for that matter), create a new style and follow these instructions:

http://www.pnotepad.org/devlog/archives/000113.html

Today I had problems creating a new project on a TFS server that had no problems in the past.  It started complaining about not being able to connect to the Sharepoint Central Administration site.  Attempting to browse to the site at http://<server name>:17012/default.aspx confirmed the service was unavailable.

It turns out that for some reason the sharepoint central administration application pool identity in IIS on the TFS server had changed.  The fix was to reset this identity to that used when setting up the TFS server (eg WSSService).

Many resources are out of date when it comes to adding custom menu commands to a DSL (e.g. 'update .ctc file..').  The resource below is current with the VS2008 SDK and is explained brilliantly.

http://stalamoni.blogspot.com/2007/12/adding-menu-to-dsl-using-vsnet-2008-sdk.html

For other people to be able to use your DSL packages without having to install the VS SDK themselves, you will need to get a Package Load Key (PLK) and install it into the DSL package. 

To simulate the project running on a machine without the SDK installed (thereby replicating the issue), add the "/novsip" to the command line arguments for the debug project.   E.g:    /ranu /rootsuffix Exp /novsip /DesignTimeRun "..\..\..\Debugging\Debugging.sln"

If you now run your DSL project in the experimental hive, you should experience a 'Package Load Failure' - this is exactly what others will get due to not having the SDK installed.

To Obtain and install a PLK

• Visit: http://www.vsipmembers.com/
• Sign up if you are not already a member.
• Click "Request a Package Load Key"
• Create a new 'Product'.  The information on the next page must exactly match the same parameters in your DslDefinition.dsl file.
• Once the product is created you can request a PLK.
• Copy the PLK value, and paste it into a new value (e.g. 500) in VSPackage.resx in your package project.
• Add the following custom attribute to the Package.tt file (the < > tokens should be replaced with those supplied in earlier steps: 

  [VSShell::ProvideLoadKey("<minimum edition> ", "<product version>", "<product name>", "<company name>", <PLK resource value>)]

• Tranform the Package.tt template.
• Re-run the package (with /novsip switch) and ensure there is no 'Package Load Failure' - if this is successful, then the package should workon any machine that does not have the VS SDK installed.