Some first steps developing Windows 10 Universal Apps

The other day I decided to dive into developing a simple app for my Windows Phone. With Windows 10 and it’s Universal App (write once, run on all Windows 10 devices) on the horizon, I decided that will be the basis for my App. I skipped developing for Windows Phone 7, 8 & 8.1 but do have a strong WPF Background which would come in handy.

After digging around in the ‘net for a couple of hours, I realized I will have to take it slow and learn a little bit before dirtying my hands with code. Developing for Windows Phone is different to what I was used to from developing from “classic” PC Development. Fortunately, there was a course “A Developer’s Guide to Windows 10” over at the Microsoft Virtual Academy which helped to clarify a lot of things for me.

At this point my key insights were:

1. With Windows 8.1 there was a universal Windows 8.1 app template which is NOT what a Windows 10 Universal App is. The universal App on Windows 8.1 ended up deploying different Binary Code for different devices and having common code in separate DLLs. Take care not to mix these up.

2. If you are looking to use a local in-proc database, SQLite is the way to go. This needs to be combined with a wrapper, the two popular ones being SQLite-net which supports LINQ or SQLitePCL. At the time of the writing I was able to use Nuget to get the Universal App Versions I needed.

I’ll keep you posted for more.


A time to kiss, a time to hedge and a time to do things dirty

After my two-year hiatus in which I decided to build something with brick and mortar instead of with software, I finally find some time to work on other things that interest me again.

One of the things I have thought about in the last couple of months/years is the art of development. There are millions of books out there covering the subject of how to develop well. Some concentrate on coding, some offer frameworks and some propagate methods.

Having developed software for over 15 years and now contracted out software development over the past 3, I’ve realized a couple of things I feel I should share with you.

Firstly, let me start with a conclusion: development is a craft. Once you start thinking of it in this fashion, you can compare it with other crafts and see how software development can fit into this. My favorite craft I like comparing it to, is blacksmith or carpenter.

Hiring a blacksmith or carpenter barely happens anymore today. If, then it is because someone is seeking something unique. How did this develop? You can take a page out of the industrial revolution for an answer.

Before the industrialization, there were masters of their craft and nothing else. They designed the product based on customer wishes, created it – often with help of apprentices and journeymen. Depending on the experience and skill of the craftsman you either got good or bad results. The really good ones earned a lot, the really bad ones made a living. The main point is that the results strongly depended on the person you hired.
Then the industrialization and mass production set in. Initially, there were workshops where every craftsman worked one station doing the one thing over and over building on the results of other. On the one hand it increased overall productivity, on the other it started creating hierarchies and reducing the importance of the individual.
In the end the labor was divided up to a point where the performance hardly had any impact on the overall result. The results were always the same, everyone was exchangeable and machines took over more and more of the work.

What does this have to do with software development? The development lends itself readily for parallels with the industrialization.

Books such as Clean Code or Design Patterns are in essence crafters swapping ideas of how to solve particular problems. They tend to be prescriptive and the developer must have some skill to be able to use the described solutions.
Frameworks tend to fall more into the class I would term workshop or early automation. They reduce implementation depth for the developer who delivers the solution, improving overall productivity in the process. It still requires skill and knowledge to use the components, but as many very popular frameworks (.NET or the JDK comes to mind) prove, you don’t really need to know all that much to use the things. Another candidate for this category are things like Continuous Integration and other development approaches which focus on the how instead of the what.
The dream of every person paying for software development would be to have a factory which assembles the software on the production line and you receive a fully vetted, shrink-wrap ready result.
In fact, there have been several attempts at this. One I remember vividly is the software factory analyzed by Jack Greenfield. (article here) In fact I liked several of the points he brought up so much, it formed a part of what I’m getting at here. I don’t believe he found the right solution – many have tried to build the equivalent of a factory in software and haven’t been able to make it work. The examples often used it the car factory where one can choose between many options but deliver the same base product. I find these examples wrong and misleading. They fail to compare the right steps with each other. Software development is the equivalent with designing the car. The step of mass production is creating the delivery package and copying this.

What does this mean for you as a developer? Well …

  1. Improving your craft is an important part of your education. Realize though that this has its limits in term of overall impact.
  2. On team scale one can improve overall productivity by using techniques that fall in the area “workshop”. This generally requires time and effort to create as you are i.e. setting up a process.
  3. Don’t believe you can set up a factory. Every sales pitch in that direction I have seen were just that – a sales pitch. If you really do figure out an effective method – contact me. I would like to be in on the millions.

Bottom line, be very clear on what kind of project you are working on. If this is a one-off, two month effort is it really worth the effort to set up a workshop? Do you really have to think of where to build in hedges for further development? Or is maybe “KISS” the answer?
On the other hand if you are writing a 1000+ days of effort, it might be worth the initial investment to gain productivity and insure that you can deliver a solution even when people leave the project or similar. It also is worth the extra effort to hedge against change as such large software tends to continue to live for years on end. Quick and Dirty create more problems than they solve.
Think strategically, don’t believe that a solution that worked the last time will work every time and make sure that you have a wide selection on strategies you can pick from.

Loading Fluent Menu at run-time

I started playing around with WPF a little bit. Of course I also wanted to build a proper ribbon interface if I was creating a windowed application. Microsoft’s Ribbon Package was ok, but I was looking for more. If you want a good list, check out the discussion here. Ultimately I decided for the open source solution on codeplex. Of course I wasn’t happy just to have a ribbon, it had to use Prism as well. I don’t do things half-baked. Prism – for those who don’t know – is a library from Microsoft which helps to implement the MVVM Paradigm. (as described in a MSDN Article)

As part of the model I needed to load a menu when a view is loaded in a region. You have two options:

  • Show/Hide a menu on demand – eh, not really. The view was defined in a separate module and I didn’t want to define the module in the Shell in advance
  • Load the menu at run-time from the module – much better. Of course I didn’t want to program the menu but insert a control.

So, making my life as difficult as possible, I defined following fragment

<Fluent:RibbonGroupBox xmlns:Fluent=”clr-namespace:Fluent;assembly=Fluent” 
                      Name=”TrainingMenu” Header=”Training” Common:NavigationOrder.Order=”1″>
    <Fluent:Button Header=”Test data” />
    <Fluent:Button Header=”Target data” />

Code 1: Fluent RibbonGroupBox Fragment

Note the property Common:NavigationOrder.Order=”1”; this is an Attached Property added to allow the loading component determine where in the menu structure the item should be placed.

This wasn’t too difficult, the real trick is to figure out how to load the fragment and then insert this at run time. The solution is

private static RibbonGroupBox FindRibbonGroupBox(Assembly callingAssembly, string menuName)
            Uri uri = new Uri(String.Format(“pack://application:,,,/{0};component{1}”, callingAssembly.GetName().Name, menuName), UriKind.RelativeOrAbsolute);
            StreamResourceInfo streamResource = Application.GetResourceStream(uri);
            if (streamResource == null)
                throw new ArgumentException(Resources.MenuResourceNotFound, “menuName”);
            Baml2006Reader bamlReader = new Baml2006Reader(streamResource.Stream);

            return XamlReader.Load(bamlReader) as RibbonGroupBox;

Code 2: Loading RibbonGroupBox at run-time

Look at the callingAssembly. This I use to determine a part of the Package URI which locates the WPF Control.  The other part of the Package URI is the menuName parameter. The complete URI would look something like this


This is used to locate the resource in the component to then read the Baml – a kind of Binary Xaml – via the Baml2006Reader. Finally use the XamlReader.Load Method to create the RibbonGroupBox.

Finally, adding the RibbonGroupBox is just a matter of Adding or Inserting it into the correct collection.

Visual Studio Installer vs. InstallShield LE vs. WiX

One of the things I’ve been thinking about the ennf Solution I’m working on right now, is how to deliver it to users. I’m a great believer in starting with the build project and the installation project before doing much of the other development things.

The standard delivery method on Windows is MSI. If you snoop around what kind of projects Visual Studio 2010 offers on this you run into three basic options

  1. Visual Studio Installer
  2. InstallShield LE
  3. WiX – Windows Installer XML

All options have trade-offs and the big question is which one to use. Personally, I’ve worked with Visual Studio Installer and WiX before – I haven’t used InstallShield LE. Here a decision help:

  1. Visual Studio Installer
    this is the easiest way to create MSI Packages. The down-side is big though. For one, the Installer is really, really limited in what can be done with it. For anything more than just a simple deployment scenario, you do not want to use this. For another, Microsoft has announced that they will discontinue it and provide it for backward compatibly. Find the article at the Deployment Group Blog
  2. InstallShield LE 
    this one is still easy to work with and unlike the Visual Studio Installer actually works with MS Build, which is important if you want to setup a good build process. Having never used this one myself, I can’t really say much on the pros and cons on this. I suggest checking out the comparison provided by Microsoft on MSDN.
  3. WiX – Windows Installer XML
    originally scheduled to be included in the Visual Studio 2010 package, it was dropped from the delivery build sometime in the beta phase. (Check out the article from Rob Mensching) From my experience, the learning curve for this is pretty high. Because it offers the full possibilities of MSI, the complexity is accordingly high. On top of this, it doesn’t have a nice designer interface. Nonetheless, if you want to take full control, this seems like the best product from my point of view. On the other hand, I’m a perfectionist, I like using the best product regardless of how easy it is to use. For a comparison check out the MSDN article I mentioned before.

One way or another, before you go ahead with creating your setup solution, you should read what Microsoft tells you about the placement of binaries as part of the build process. Lastly, find the WiX Toolset at

NUnit Testing of Entity Framework 4.1 and code-first

A while back I started a new project called ennf – Eddie’s Neural Network Framework. (Check it out at One of the things this framework brings along is an automatic storing of the networks in a database with the code-first Entity Framework 4.1  from Microsoft. Of course I wanted to create NUnit tests for the software as I’ll be developing this over years to come and when other people get into it, I’m bound to not have a complete overview over all the code. And it is a best practice anyway. 

Unfortunately Microsoft hasn’t gotten around to implementing the framework Unit-testing friendly. One blog from a Microsoft Engineer (sorry, don’t have the link anymore) in essence said “It wasn’t the first priority”.
@Microsoft: please make unit-testability a priority on your next cycle. Thanks.
That being the case, the situation leaves you with 2 options:

While Moles is a nifty idea, I ran into trouble trying to use them with Unity Framework 2.0 and the Enterprise Library. For some reason (which I didn’t research further) the unity framework suddenly didn’t work correctly anymore once I tried combining it with Moles. My guess is that the reflection somehow got messed up, but that is really just a stab in the dark. A way how to do this can be found here.

That left me with option 2 – wrapping the entity framework with my own interfaces. There are blogs aplenty around showing how to use the IDbSet interface to create unit tests. (example here or an older example here)
Be warned: that is only half the story and the blogs are quiet on anything else. Once you take that path, you end up having to slowly replace all classes with wrappers. At least if you use the Entity Framework for anything else than trivial things. The first step is to setup your T4 Templates which is fairly easy to do. And then the fun starts. First you replace the DbSet, then the DbEntityEntry and then it starts getting boring.

Well … if you want to Unit-test, then you don’t have much options. How does such wrappers look like? An example

public interface IDbMemberEntry<TEntity, TProperty> where TEntity : class
        TProperty CurrentValue { get; set; }
        IDbEntityEntry<TEntity> EntityEntry { get; }
        string Name { get; }

        bool Equals(object obj);
        int GetHashCode();
        Type GetType();
       ICollection<DbValidationError> GetValidationErrors();
        string ToString();

Code Example 1: Interface for DbMemberEntry

class DbMemberEntryAdapter<TEntity, TProperty> : IDbMemberEntry<TEntity,TProperty> where TEntity : class
        private DbMemberEntry<TEntity, TProperty> _MemberEntry;

        public DbMemberEntryAdapter(DbMemberEntry<TEntity, TProperty> memberEntry)
            _MemberEntry = memberEntry;

        public TProperty CurrentValue
                return _MemberEntry.CurrentValue;
                _MemberEntry.CurrentValue = value;

        public IDbEntityEntry<TEntity> EntityEntry
            get { throw new NotImplementedException(); }

        public string Name
            get { return _MemberEntry.Name; }

        public ICollection<System.Data.Entity.Validation.DbValidationError> GetValidationErrors()
            return _MemberEntry.GetValidationErrors();

Code Example 2: Implementation for DbMemberEntry

Ok, the example isn’t fully implemented, but you get the idea. The rest is just coding …

NuGet – a cool tool for the command line freak

If you’ve been doing IT as long as I have and worked all sorts of different operating systems and software, you come to appreciate different features in different systems. One of the really cool things in Linux is the ability to install something with a package manager. Gentoo for example uses emerge to install something. So, if you want ecplise you enter something like “emerge eclipse” and voilá – you have eclipse.

A very similar tool for Visual Studio has been around for almost 1 year and I just found out: NuGet. Open up PowerShell, execute something like “Install-Package EntityFramework” and presto. Of course no Microsoft-based tool can live without a graphical interface and this is no exception, but I really love the command line.

There are already 2.000+ projects on there and Microsoft is promoting the thing actively as well – just take a look at the ADO.NET Team Blog on Entity Framework 4.1

And if you’re wondering: yes, I did run into it there.

Waterfall vs. Agile: a case for simple development

I haven’t written much on development practices lately. Time to catch up on one of my personal hobbies. I’ve been challenging the current trend to call everything “agile development”. Anyone who has followed my posts (on my old blogging site) will know: I’m not an agile methods poster boy. Too often I’ve seen projects burn and fail because a project or company decided to introduce agile methodology without setting up the team for success. No matter which development style you follow: introducing a new set of processes takes time, dedication and a lot of work. I don’t think that agile methods can’t work. But taking a look at the hype-curve these are for sure at the crest of the wave.

My first question is: would a developer develop differently depending on which management style you use? Yes and no. The factors that define how a developer develops I would say are:

  • the requirements,
    No matter what, at the end of the day what gets developed is directed by the requirements. How and what requirements are requested for by the user is strongly dependent on the level of understanding by the user. So his understanding will actually dictate – and I think very, very strongly – how and what a developer develops.
  • the amount of time to develop the solution,
    If time is available, the developer will make sure that the solution is future-proof (as far as he can), flexible and consistent.
  • the flexibility of the architecture
    No matter what – at the end the overall architecture will determine what the developer can do
  • and his motivation
    Depending on how motivated a developer is, he will either go out of his way to make it right or just code a simple solution.

The question is: how much do agile methods influence these factors?

  • Requirements: The way the user requests the requirements depends strongly on how much the user understands the system. Sounds trivial, but this happens more often than one might think. Especially in the beginning of a solution users tend to have sky-high expectations and ideas and don’t realize the amount of work it creates and how little some features might actually create value.
    Here many agile methods profit from an iterative approach. Because the user is confronted with reality early and often, the amount of communication effort is reduced and simplified.
    The down-side is that the developer must develop a feature in such a fashion that it is presentable to a user in a short time. Especially in the beginning of a development cycle solutions require quite a set of skills from developers. For example: if I write the feature “Print data” I first need to set up logging, tracing, error handling and other plumbing. If I don’t take a careful look, develop with foresight and have a few tricks up my sleeve how to set up a skeleton, this will not work well and lead to a lot of rework further down the road.
    At the end though, iterative development is not something necessarily limited to agile methods although it has popularized it. One can still use a phased and more formal development style and still take an iterative approach. It is really much more dependent on developers who are used to working in that fashion.
  • Time to develop: the more time a developer has, the better the solution one would think. Actually that is not necessarily the case. There is research that make a case for not providing too much time as the overall return drops off after a certain point. Many managers therefore deduce that you have to keep the pressure up by giving the developer less than necessary time. (The Scotty-Effect) The result is a sub-optimal solution with early success but a heavy price to pay further down the line. A great book on the subject of software estimation and finding the magical “necessary time” is “Software Estimation: Software Estimation: Demystifying the Black Art” from Steve McConnell and in this connection the chapter “Is It Better to Overestimate or Underestimate?”. The point here is: agile methods doesn’t really help you to find the optimal effort for a give problem. Where it does help is to break down the work in to more easily estimated portions and get a grip on these more easily. But to be honest: take a read of the book, even big estimates can be up to 10% accurate if done correctly.
  • Architecture flexibility: without loosing too much words on this, the skill and experience of the architect and the developers is the most important determinant for this. No two ways about it. The only question is how to get the optimal mix of oversight and independent work. Different methodologies have a different concept here, but at the end this is truly not dependent on the method.
  • Developer Motivation: is often dependent on the “interesting, new code hacking/administrative work or maintenance work” ratio. Depending on the developer of course. This is the most seductive part of agile methods. They raise the prospect of not needing as much administrative work as other methods and in turn raise developer satisfaction and unleashed the shackled developer. In fact, agile methods require much more discipline even if you fill out less documents, as any Scrum Master will certify. The major question therefore is “how high is the necessary administrative work”? Again this is not dependent on the method you follow but how you implement them. Even a complete, fully processional setup will and can tailor the necessary non-code relevant work to a minimum. I still wonder how much overhead conventional methods have compared to agile methods for this to actually give a noticeable edge to be honest I don’t believe noticeably much. On the other hand, a feeling of more freedom and space can be very motivating for developers.

So … reviewing the pros & cons, I would say agile methods have important and relevant points to contribute. I believe especially that an iterative approach can be very valuable. On the other hand, agile methods tend to be adopted by the development team without the buy-in of the customer. Often import communication tools with the client like risk and change management are considered superfluous having the project run against the wall not because of development skill but poor client management skills. Especially in consulting scenarios (and not in-house development), the efforts involving communication with the client can be more than the actual development..

Conclusion: what I’ve mentioned several times, is that it is strongly dependent on the goals of the client, the skill of the involved developers and how the project manager organizes the processes. Agile methods provide an option and point to solutions to everyday problems in development. They are another Tool in the project managers tool box.

Each approach has its strengths and weaknesses. And understanding when which mechanism is appropriate is the challenge. No method with all processes in place fits all projects and is appropriate in every situation. Choose the one that solves the set of problems most, adapt it and adapt it as the project progresses. In an innovative, completely new area of work I would go with a more iterative, agile approach while in a more settled and business critical system I would take a more waterfall like approach. Whatever you do: keep it to the minimum necessary to achieve your goal.

Create a free website or blog at

Up ↑