Monday 15 December 2014
Monday 22 July 2013
We’ve recently started using the Silverlight 5 PivotViewer control in On Key Express as a great way for visualizing the Work Orders showing the work list that needs to be completed/has been completed. Here is some screenshots showing the different “cards” of information for the Work Orders at different zoom levels.
Small Card View
Large Card View
One of the great features of On Key Express is the ability for clients to translate the system into any language. This is great feature for customers who have engineers working across the globe as they can customise the system into any language they which to support. We supply the default English translation but the clients can even decide to change the English translation if they have certain client specific terminology they want to use.
This language feature however imposes an important restriction of any third party control that we use – we need the ability to translate any resource displayed by the control. We make extensive use of the excellent Telerik RadControls for Silverlight. Fortunately these controls are fully localizable by hooking up a custom ResourceManager to override the default resources being used by the Grids and other controls.
The PivotViewer control has quite a few resources. It ships with support for a few languages out-of-the-box through providing the resources in separate System.Windows.Controls.Pivot.resources.dll resource assemblies. By setting the ItemCulture property you are able to use the different out-of-the-box translations shipped with the control. However, unlike the Telerik controls there is however no easy way to hook into the control to override the resources being used. We can create additional resources assemblies for different languages but as mentioned previously, the client decides what additional languages they want to support.
We therefore needed a way to hook into the PivotViewer to inject our own Resource Provider that will use the client provided resource translations. Technically we store the clients translations in a database that is periodically synchronised with the client devices. After looking at the PivotViewer using Reflector, we confirmed that it makes use of the usual an internal static Resources class that is generated whenever you add .resx files to a project. The Resources wrapper internally makes use of a ResourceManager that uses the current culture to access the language specific resource file. We needed the ability to intercept the calls being made by this ResourceManager. We also wanted the ability to still use the existing Microsoft resource assembly as the default fallback mechanism for any of the resources that we don’t want the clients to translate. There includes the numerous exceptions and other design time resources which the clients aren’t interested in.
With this in mind, we created the following PivotViewerResourceManager wrapper class:
Notice that the class is a simple ResourceManager wrapper around the existing Microsoft resource assembly. When override the GetString method to allow us to first do an external lookup for the resource using our IResourceProvider interface. If we do not have an external translation, we simply delegate to the Microsoft provided resource. We adopted the convention of prefixing all the client provided translations for the PivotViewer with the “MSPivot” prefix as it makes it easier to identify all the translations related directly to the control. With all of this in place we simply added a trigger to the PivotViewer XAML to load and inject our PivotViewerResourceManager when the control is loaded via the InjectResourceManager method.
Here is a sample screen shot of our ResourceManager in action with the PivotViewer. Notice that some of the resources for which we provide translations are show in a different language whilst the rest of the control falls back to using the default MS provider resources.
Tuesday 02 April 2013
BackgroundAt Pragma we've been improving on some of our deployment practices during the past few releases. I've always been a great proponent of trying to automate as much of the deployment process as possible. One of the aspects that we improved on recently was the ability to automatically generate the Release Notes from our Team Foundation Server repository with every daily build of our software. This automation gives us quite a few benefits:
- Visibility into what's included with every build from the beginning of a release
- Ability to QA the Release Notes earlier in the development cycle as part of our daily builds
- Use of our existing TFS work items as the source for feedback, i.e. no context is lost between developers telling the technical writer what to include in the Release Notes. The technical writer only needs to check the grammar and spelling of the TFS Work Item feedback.
- No manual intervention required to get the bulk of the Release Notes document generated
- We want to be able to merge some manually authored content into the Release Notes document. Sections like What's New, Modifications and Maintenance typically contain functionality that are implemented by various TFS Work Items (Product Backlog Items, Tasks etc). So we wanted the ability to manually author these sections and merge the content with remainder of the document that is automatically generated.
- We want the ability to selectively filter out some Work Items from being included in the Release Notes document by running a custom TFS Query. An example of Work Items that we want to exclude are the internal bugs that were discovered for new functionality not yet released into production.
- We want to use MS Word to author the manual content to make use of our existing corporate stylesheets
- We want the output to be available as a PDF
- We want command line support to allow us to automate the process as part of our daily builds using TeamCity
- We want the PDF to use bookmarks to enable easy navigation between the different sections
- We want the PDF to use our corporate branding/style
The next step was to create a ReportRunner class to take these settings and generate the report in the PDF format:
Generating the PDF
On a high level, the process for generating the PDF turned out as follows:
- Create new blank PDF
- Add a front page
- Add (merge) the contents of the manual PDF into the new blank PDF whilst keeping track of the bookmarks contained within the manual document (see Requirement #6)
- Run through the list of processed work items to add the document content for them into relevant sections in the new PDF
- Re-bookmark the whole document to enable easy navigation throughout the whole PDF in support of requirement #6.
To add the front page and also include a custom footer on every page containing the build version, generation time stamp as well as page number, we created a ReleaseNotesPdfPageEvents class to implement the IPdfPageEvent interface that iTextSharp provides for executing custom logic when a PDF document is opened/closed, new paragraphs, sections are added etc. This class is then assigned to PageEvent of the PDF writer to ensure that the custom logic executes as part of the PDF generation process (see line 16).
After adding the front page, the content of the manual PDF is merged into the new document (lines 30-35). Keeping track of the bookmarks turned out to be quite an interesting exercise and is done as part of the Merge method.
After merging the existing content, we process the in-memory list of work item information by firstly grouping the Work Items based on their resolution types into sections like "How do I", "Bug Fixes" etc. (lines 38-41) and thereafter writing these sections into the document using the WriteWorkItems method:
For every new section we add an additional bookmark into the Bookmarks collection to make sure that we have a complete list of bookmarks for all the available sections in the document (see line 14). The final step in the generation process is to add these bookmarks into the new document using the CreateBookmarks method.
Friday 28 December 2012
One of the great new features included with .NET 4.5 and Visual Studio 2012 is the async/await support for writing more elegant multi-threaded code in C# or Visual Basic. Support for writing tests that make use of the async/await keywords is available for the Microsoft Test Framework as well as most of the other popular xUnit testing frameworks like NUnit. In addition to providing support for async/await baked into the compilers for Visual Studio 2012 and .NET 4.5, Microsoft has also released the Async Targeting pack for Visual Studio 2012 that enables projects targeting .NET 4.0 or Silverlight 5 to use the Async language feature in C# and Visual Basic code.
Using it in your Silverlight 5 code is quite handy – especially when invoking web services from the client. However, the Microsoft Test Framework for Silverlight has not been extended to support running these asynchronous tests. However, in a recent blog post by Morten Nielsen he shows how it is possible to go about adding this support to the Silverlight Test Framework. He provides a customized version of the Silverlight Test Framework, but also urges us to go vote for getting this added directly to the official Silverlight Toolkit.
I know a lot of development shops like ourselves still have quite a substantial amount of Silverlight code to maintain, so please go and vote for the issue to get Microsoft to add support for it in the Silverlight Toolkit.
Monday 19 November 2012
In our current team environment we are using the VS 2012 Professional SKU with a MSDN subscription due to the cost savings it affords us. That implies that we miss out on features like the integrated Code Analysis. Up till VS 2010, Microsoft released an updated edition of the Code Analysis engine with the standalone FxCop installation. That implied that even though we didn’t get the tooling integrated into Visual Studio directly, at least we could use the standalone edition of FxCop to execute the same set of Code Analysis rules on our code base - albeit in a bit more laborious fashion.
With VS 2012 Microsoft has not yet released an update to the standalone FxCop. Here’s the MSDN forum post where I raised the issue as to when an update will be released. The current standalone edition also doesn’t seem to support the new Portable Library format being used to cross target different .NET platforms. Following the advise on the forum post I’ve created an UserVoice issue to request an update. So if you are in the same boat as to using the standalone edition, please head over to UserVoice and go vote for the issue to get it resolved. Thanks.
PS: Btw, if you would like to run the standalone FxCop in VS, you might want to consider the FxCop Integrator. Haven’t used it, but it seems promising although there hasn’t been an update for a while.