Tiny house

19 Mar

Is this the future or a crazy idea? Kinda like the idea about small, simple and focus on the most important values. But is it realistic?

// thomas

Congratulations Microsoft and Xamarin

25 Feb

Bluefragments congratulates Microsoft and Xamarin for the exciting news that Microsoft intents to acquire Xamarin.

This is great news for the important cross-platform endeavors the mobility market is demanding: To do more – on any device – with less effort.

In Bluefragments we have worked hard to become the most trusted Xamarin partner in Denmark in order to match our skillsets on the Windows platform. Our efforts has given us a strong leadership position on both platforms – and we could not be more excited to see that the two companies now becomes one.

Exciting future ahead!

Do you have what it takes?

22 Jan

In Bluefragments we build great solutions – and we got a lot more exiting work coming.

Do you have what it takes to join our “Microsoft App partner of the year” (3 years in a row), Xamarin and IoT pioneer company?

Drop me a line – just keep it short and to the point … like your code.

Nominated for 3 Microsoft Partner Awards

5 Nov

Tonight is the annual Microsoft Denmark Partner Award show – and Bluefragments are nominated for 3 awards.

We submitted applications for three categories and has been honored with a nomination in all three (which of course must mean we are among the 3 best in each category in the field of more than 4000 Microsoft partners in Denmark :)):

  • App partner of the year
  • Innovation Partner Partner of the year, Product Services & Technology
  • Customer satisfaction

The award show tonight is at the brand new Microsoft Office in Lyngby – exciting times :D

MPA_nominering_2015_App MPA_nominering_2015_Bedste_Kundetilfredshed MPA_nominering_2015_Innovations_Produkt_S_T

// thomas

Guide: How to use a MacMini as your Xamarin.iOS Build Host

30 Aug

This guide describes how to setup your Windows PC and your MacMini so you can use your MacMini as Xamarin.iOS Build Host and continue to develop on your Windows PC – even if you’re traveling.

If you develop iOS apps based on Xamarin you will most likely be using a MacBook Pro (or something similar) running Windows in some form. If you’re a Windows developer working on a Windows PC and for good reasons wants to stick to this setup, you have an alternative to buying a MacBook Pro. To be able to compile your Xamarin.iOS apps you will need a Mac – but you can actually settle with a MacMini costing less than 25% of a MacBook Pro.


First of all you will need to have Xamarin installed on your Windows PC and on your MacMini. When you install Xamarin on your MacMini it will automatically install Xamarin.iOS Build Host. If you install Visual Studio 2015 on your Windows PC you can choose to install Xamarin during the setup process.

The network

Your Windows PC and your MacMini needs to be on the same network for Visual Studio to be able to find the Xamarin.iOS Build Host. The MacMini is designed to work as a static machine in an office or a home. If you’re working from your office this is not an issue – you will most likely be on the same network.

However if you travel or work from different locations it is not an option to bring your MacMini all the time. For the Windows PC and the MacMini to be on the same network all the time you can use a simple VPN tool. I have good experience with Hamachi from LogMeIn – it is really simple to create a network and have your Windows PC and your MacMini to join the network.

To connect Visual Studio and your Xamarion.iOS Build Host you will need the IP address of our Xamarin.iOS Build Host – it is revealed in the Hamachi client. I have experienced that in some cases you will need to restart Visual Studio have you connected for the first time to be able to maintain the connection.

Now that you’re on the same network the connection and have setup the connection between Visual Studio and your Xamarin.iOS Build Host, the connection will remain even if you’re on different locations.

Remote access

When you debug a Xamarion.iOS app from Visual Studio you will have it running either in a simulator (on the MacMini) or on a device (connected to your MacMini). If you’re working right next to your MacMini you can easily see the simulator or use a device.

However if you’re on a different location you will need to have remote access to your MacMini.

On your Windows PC you will need to have a viewer installed. I have tried TeamViewer and UltraVNC and found UltraVNC to be the best tool for me as it is the most simple tool (if you choose UltraVNC beaware of the many ads on their homepage – the viewer is ad free).

On your MacMini you just need to enable remote access as it already have a VNC server included. Graham Miln wrote a post on how to enable it.

Using the client viewer you can now easily debug and run your Xamarin.iOS app even if you’re not sitting next to your MacMini.

MacMini startup

For the above setup to work it is crucial that your MacMini is available at all times. By default the MacMini will go sleep after a few minutes if not used. I bought a small app to keep the MacMini awake called Stay Awake – I’m sure there are several app like it.

I setup Stay Awake and Xamarin.iOS to start automatically when the MacMini starts – and finally I set up the MacMini to auto login during startup to ensure that it will be availble even if it for some reason reboots.

// thomas

Notice: I have experienced that the connection between Visual Studio and Xamarin.iOS Build Host becomes unavailable on some company guest networks and on some mobile networks.

Child node exited prematurely. Shutting down.

13 Jan

As written yesterday I have spend the weekend working on a Windows 8.1 solution for a customer. For several good reasons (mostly fun) I tested the solution on my Windows 10 Preview machine running Visual Studio 2015 Preview.

When I compiled I got the following error:

Child node “2” exited prematurely. Shutting down. Diagnostic information may be found in files in the temporary files directory named MSBuild_*.failure.txt.

The error itself didn’t reveal much about the error but of course everything pointed at either Windows 10 Preview or Visual Studio 2013 Preview.

A quick search showed surprising few results. I found two leads that I tried to follow.

First lead was this one Problems with Parallel build using MSBuild at StackOverflow. It lead me into modifying the MSBuild process to run without parallel. I tested in a command prompt with the following command.

“C:\Source\[Customer]\[Project]\[Solution].sln” /t:Build /m
/v:q /p:Optimize=”True”;DebugSymbols=”True”;Configuration=”Release”

The issue remained and I had to follow my next lead HeatDirectory failure on TFS with MSBUILD error MSB4166: Child node “3” exited prematurely also from StackOverflow. It lead me into modifying the solution and projects to x86 instead of x64 as well as changing the MSBuild process to build on an x86 platform. The issue remained.

To be honest at this point everything seamed like a bug in Visual Studio 2015 Preview and I actually considered giving up and accepting the bug (hahaha I wouldn’t give up in a million years!). A little bit desperate I installed Visual Studio 2013 on my Windows 10 Preview machine. To my frustration the issue remained in Visual Studio 2013.

For fun I tried to begin to exclude projects and files in the solution. First the test projects (of course!), then the portable class libraries and then the nuget packages. The issue remained. Finally I began removing features and styles and suddently I could build and 5 minutes later I had identified the bug.

As part of our refactoring between the Windows Phone 8.1 project and Windows 8.1 project we had by mistake added a DataTemplate to a ResourceDictionary. Well it is actually ok but the issues was that a Button in the DataTemplate called the Tapped eventhandler (and that is definitely no-go!).

To reproduce the error all you need to do is add a ResourceDictionary to your solution (you don’t need to make a reference to it from the App.xaml file). Add the following DataTemplate to the ResourceDictionary:

<DataTemplate x:Key=”template1″>
<Button Content=”Hello World”
Tapped=”button_Tapped” />

With the eventhandler removed the solution compiled in both Visual Studio 2013 and Visual Studio 2015 Preview on my Windows 10 Preview machine. Finally! :D

Obviously something is changed between Windows 8.1 and Windows 10 in the way solutions are compiled or at least at what causes a compile error (looking into that now). And I guess a few improvements could be in place regarding the error message :)

// thomas

MakePRI : warning 0xdef00520: Invalid qualifier

10 Jan

The last couple of days I have been working on a Windows 8.1 solution for a customer. The solution is an universal app and we launched the Windows Phone part last month so this month is all about building the Windows 8.1 part.

In the Windows Phone app we used resource files for handling strings and localization. Resource files are easy to use and allows us to set x:uid on a control to apply localized strings.

Looking forward this solution doesn’t work for us. We decided to use a very simple dictionary solution that we can call to the the localized string we need. To fill the dictionaries we had three xml files with data each representing a langague. The xml files was named strings.en-us.xml, strings.da-dk.xml and strings.sv-se.xml.

When we build the solution we got the following warnings:

5>MakePRI : warning 0xdef00520: Invalid qualifier: DA-DK
5>MakePRI : warning 0xdef00520: Invalid qualifier: EN-US
5>MakePRI : warning 0xdef00520: Invalid qualifier: SV-SE

In my search for a solution I checked the <Resource Language=”x-generate” /> in the Package.AppManifest files to see if this was causing any issues – it wasn’t.

I was looking into external assemblies that might would be missing some resources – it wasn’t an issue.

After a little bit of further searching I figured it out! It was the nameing of the xml files that caused the warnings. If filenames inlcudes language codes (da-dk etc.) the solution expects the app to be supported in this language – and it wasn’t. After a quick renaming of the three files the warning was gone :)

// thomas