PCL Tips and Tricks: Hashtable

The introduction of Portable Class Libraries, PCL, considerably facilitates the sharing of functionality across managed Microsoft and Xamarin platforms. I am very enthusiastic about the PCL concept, and I have ported several .NET Framework open source projects to Portable Class Libraries. Along the way I have stumbled across various issues of making .NET Framework source code PCL compliant. In this mini-series I'll share my experiences and workarounds to facilitate the transfer to PCL for other developers.

C# code that has its roots in pre-generic time (.NET Framework 1.x, that is) often tend to contain non-generic collections such as ArrayList and Hashtable.  In the Portable Class Libraries however, non-generic collections are avoided to the largest possible extent, and Hashtable is one of the missing classes.

Hashtable is simply a non-generic dictionary (it implements IDictionary) and it also shares the main methods and properties with the generic Dictionary<TKey, TValue> class, which is available across all PCL profiles.

It is thus actually quite straightforward to replace all Hashtable instances with Dictionary<TKey, TValue> instances. And as an added benefit, the dictionary can often be specialized as well, i.e. instead of replacing Hashtable with Dictionary<object, object> you can apply the actual key and value types.

Here is one example from the CSJ2K project, which is a C# class library for JPEG2000 encoding and decoding. In the .NET Framework-only project on Codeplex, in the ChannelDefinitionBox class, the field definitions is declared as a Hashtable where int is always used as keys and int[] as values.So, in my PCL adaptation of the CSJ2K project on Github, I have happily replaced Hashtable with Dictionary<int, int[]> in the adapted ChannelDefinitionBox class.

One additional comment is in place: in the aforementioned project CSJ2K, the hash tables are consistently created using the Synchronized method to ensure that the hash table is thread-safe. Dictionary<TKey, TValue> on the other hand does not guarantee thread-safety. A solution to this problem would be to instead use ConcurrentDictionary<TKey, TValue>, but this specialized dictionary is available in substantially fewer PCL profiles. If your PCL is targeting Windows Phone 8 or earlier, or Silverlight for that matter, ConcurrentDictionary will not be available. There is another workaround to this issue, but I'll save that for a subsequent post...

PCL Tips and tricks: ASCIIEncoding

The introduction of Portable Class Libraries, PCL, considerably facilitates the sharing of functionality across managed Microsoft and Xamarin platforms. I am very enthusiastic about the PCL concept, and I have ported several .NET Framework open source projects to Portable Class Libraries. Along the way I have stumbled across various issues of making .NET Framework source code PCL compliant. In this mini-series I'll share my experiences and workarounds to facilitate the transfer to PCL for other developers.

It appears to be very common that .NET Framework class libraries containing some kind of text processing relies on the ASCIIEncoding class, or alternatively the Encoding.ASCII static property.

ASCIIEncoding is not portable, but fortunately it can very easily replaced with another encoding that is available in (I think) all PCL profiles, namely UTF8Encoding. The UTF-8 encoding contains the ASCII character set as a sub-set, and it is even stated in the MSDN documentation for Encoding.ASCII that:

If your application requires 8-bit encoding (which is sometimes incorrectly referred to as "ASCII"), the UTF-8 encoding is recommended over the ASCII encoding. For the characters 0-7F, the results are identical, but use of UTF-8 avoids data loss by allowing representation of all Unicode characters that are representable. Note that the ASCII encoding has an 8th bit ambiguity that can allow malicious use, but the UTF-8 encoding removes ambiguity about the 8th bit.

So, whenever encountering ASCIIEncoding or Encoding.ASCII in source code that you are porting to PCL, simply replace it with UTF8Encoding and Encoding.UTF8, respectively.

Open source project of the day: Evil DICOM

Over the last four years I have contributed a fair amount of code to the open source community. Some of these projects I have initiated myself, other projects are forks of existing projects that I have adapted to Portable Class Libraries or new target platforms. The projects range from optimization and scientific computing, over medical imaging and image processing to utility libraries. In this mini-series I intend to give a short introduction to each of these open source projects.

A while back, Rex Cardan published his DICOM toolkit Evil DICOM. Evil DICOM is a .NET Framework based light-weight toolkit primarily for parsing and manipulating DICOM files. Network communication is barely included, and the toolkit does not contain any imaging functionality.

The lack of network and imaging functionality makes Evil DICOM a suitable candidate for turning into a Portable Class Library, and thereby substantially broadening the platforms on which Evil DICOM can be utilized.

When I first came in contact with Evil DICOM, my initial idea was to adapt the toolkit to Windows 8 (formerly known as Metro) applications. Few changes were required, it was practically only the file I/O that had to be adapted to Windows 8/Metro. One of the very early commits in my Evil DICOM fork on Github contains this solution. My work also led Rex Cardan to look in the same direction, and he has later published his own Windows 8/Metro application based on Evil DICOM in the Windows Store.

Rex later made a large revision of the Evil DICOM class library, and I then decided to take a step further and attempt to adapt the library to a Portable Class Library targeting as many platforms as possible.

The result of this adaptation is available in my Evil DICOM fork on Github. This PCL version of the library provides all functionality of the original class library except one class for reading DICOM files via sockets. This specific functionality has instead been made available as a separate .NET Framework only class library. The Portable Class Library currently targets these platforms:

• .NET Framework 4.5 and higher
• Windows 8 and higher (formerly known as Metro)
• Windows Phone 8 and higher (Silverlight)
• Silverlight 5
• Xamarin.Android
• Xamarin.iOS

As I mentioned in the beginning, Evil DICOM is extremely light-weight and in principle limited to DICOM file textual manipulation. A substantially wider ranging C# DICOM toolkit is fo-dicom. It so happens that I have also extended this toolkit to other Microsoft and Xamarin platforms. However, this will be the issue of a subsequent post in this series. Stay tuned...

Open source project of the day: YAMP

Over the last four years I have contributed a fair amount of code to the open source community. Some of these projects I have initiated myself, other projects are forks of existing projects that I have adapted to Portable Class Libraries or new target platforms. The projects range from optimization and scientific computing, over medical imaging and image processing to utility libraries. In this mini-series I intend to give a short introduction to each of these open source projects.

Since I have just recommended the project on StackOverflow, I thought I'd start with YAMP. YAMP is short for Yet Another Math Parser. It is written mainly by Florian Rappl, and is a high-performing parser of mathematical expressions including scalar, vector and matrix algebra, a vast set of mathematical and statistical functions, variable management and so on. The parser is relatively fast compared to other mathematical parsers available, and it is written entirely in managed C# code; it has no dependencies towards native libraries.

Originally, YAMP was targeted solely at the .NET Framework. However, since YAMP is written entirely in C# and is only using a limited set of non-portable classes and methods, I took on the challenge of porting YAMP to a Portable Class Library, PCL, targeting as many of the Microsoft (Windows 8/Metro, Windows Phone, Silverlight) and Xamarin (iOS, Android) platforms as possible. It was a relatively simple task to adapt YAMP to PCL. The original code made use of some non-portable methods that could be easily replaced with corresponding calls to portable equivalents. The main issue turned out to be the inclusion of file I/O operations in the vanilla YAMP version. Fortunately, these classes were isolated and could easily be excluded from the PCL class library.

I published my adaptations in a Github fork of the original YAMP library; my fork is available here.

My work was appreciated by the main author Florian Rappl, and I have continuously collaborated with him to merge all PCL adaptations into the main YAMP repository.

Now, YAMP is avaliable as a .NET Framework only NuGet package here, and a PCL enabled NuGet package YAMP.Portable is available here.

To learn more about YAMP, you may also have a look at this CodeProject article by Florian Rappl.

Copying a project resource image to a WriteableBitmap in a Windows Store application

It seems like the Windows Store application projects in Visual Studio 2013 Update 2 do not like embedded resources:

Build action 'EmbeddedResource' is not supported by projects with an output type of 'appcontainerexe'.

So far I have used embedded resources to include image files that I programmatically assign to WriteableBitmap objects for example in my Windows Store applications, but now this approach does not seem so fruitful any longer.

Here is what I did instead.

a) Set the image file Build Action to Content, and Copy Always to Output Directory:

b) Reference the WriteableBitmapEx library, most easily via NuGet.

c) Use the FromContent extension method in the WriteableBitmapEx library to load the image via its URI:

var tmp = BitmapFactory.New(1, 1);

var wbm = await tmp.FromContent(

    new Uri("ms-appx:///Assets/image.jpg"));

And voilá! Now the image file resource is sufficiently loaded into wbm.

BitmapFactory.New is a method in WriteableBitmapEx which can be used portably to create a WriteableBitmap object across different targets such as Windows Store, Windows Phone, .NET Framework etc.

Otherwise, practically all methods in WriteableBitmapEx are extension methods, and therefore the FromContent method a little awkwardly requires an incoming WriteableBitmap object, that it ignores.

ms-appx:/// is the root or base URI (Uniform Resource Identifier) of the application, and Assets/image.jpg is the path relative to the base URI.

The revival of a blog

It's been practically two years since I last posted an entry on this blog. It's not that I have not had things to write about (on the contrary). However, there has been a little bit of mismatch between the blog format and my ambitions, and therefore I have rather focused my presence to forums like StackOverflow and Twitter.

At the same time, I continuously make new experiences in the field of software development and radiation therapy that I believe are worthwhile sharing, so I now think it is time to revive the blog. This time I will try to keep the posts shorter and appearing more frequently.

To really mark the beginning of this new era, the blog is also receiving a new name:

Outcome counts - Lessons learned from being a Cureos person.

Welcome to the new ride :-)

Upgrading to VS 2013 Update 2 - One word (or a few) of caution...

I have recently adapted AForge.NET Framework and Accord.NET Framework to Portable Class Libraries (here and here), targeting .NET Framework 4.5 and higher, Windows Store applications (Windows 8 and higher) and Windows Phone 8 and higher.

Both AForge.NET and Accord.NET make extensive use of unsafe code. This feature has not been officially available for Windows Phone 8, but by manually editing the project file of the Portable Class Libraries in question, I have been able to successfully circumvent this limitation.

After upgrading to Visual Studio 2013 Update 2 last week, it seems like this loophole of mine is now at least detected. When trying to compile the libraries containing unsafe code, I get error messages like the following:

Error 1 'Allow unsafe code' is not supported by one or more of the project's targets. [...]\accord\Sources\Accord.Math\Portable.Accord.Math.csproj 0 0 Portable.Accord.Math

For some reason, the libraries still appear to be successfully built, but I am currently not sure of their applicability. Further testing is obviously necessary.

Note: no error is reported when I build the libraries using Visual Studio 2012. For my own peace of mind, maybe I should revert to the previous VS version, then...