Problem with ResourceDictionary in Xamarin Forms .Net Native

Last week a colleague had the idea, to split the Resources, that we have defined in App.xaml in several ResourceDictionaries. Since our App.xaml has grown to over 400 lines, we thought this would be a very good idea, and did it as always:

 <Application.Resources>
        <ResourceDictionary xmlns:local="clr-namespace:TestResources">
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/Resources/Buttons.xaml" />
                <ResourceDictionary Source="/Resources/Labels.xaml" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

Looks good, and when we were testing the App, it worked well. But as soon, as we wanted to ship the App to our customer, it totally crashed during start up. What was the difference? We always test Debug builds, but without .Net Native
Toolchain active, but for shipping, we made a Release build with .Net Native builds activated.

The following error occured:

Unhandled exception at 0x05B6B264 (Windows.UI.Xaml.dll) in TestResources.UWP.exe: 0xC000027B: Anwendungsinterne Ausnahme (parameters: 0x0B477CF8, 0x00000003).

In the output window we see a lot of error messages:

Unhandled exception at 0x05B4B264 (Windows.UI.Xaml.dll) in TestResources.UWP.exe: 0xC000027B: internal error(parameters: 0x0B44D9B0, 0x00000003).

Unhandled exception at 0x777AF989 (combase.dll) in TestResources.UWP.exe: 0xC0000602: Ein sofortiger Ausnahmefehler ist aufgetreten. Die Ausnahmehandler werden nicht aufgerufen, und der Prozess wird sofort beendet.

Unhandled exception at 0x77627ED3 (combase.dll) in TestResources.UWP.exe: 0xC0000005: Access violation reading location 0x00000008.

I am not quite sure, why this happens but the solution is quite simple:

Add a code behind file (in our case Buttons.cs).

In the constructor, call “InitializeComponent()”.

Now we can include the ResourceDictionary directly in the App.xaml

In our case the Buttons.xaml.cs looks like this:

   public partial class Buttons : ResourceDictionary
    {
        public Buttons()
        {
            InitializeComponent();
        }
    }

..and the App.xaml

<Application.Resources>
        <ResourceDictionary xmlns:local="clr-namespace:TestResources">
            <ResourceDictionary.MergedDictionaries>
                <local:Buttons />
                <!--<ResourceDictionary Source="/Resources/Buttons.xaml" />-->
                <!--<ResourceDictionary Source="/Resources/Labels.xaml" />-->
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>

If you have a clue, why we need to go this way, just leave me a comment.

Error 0xC000041D using GetCallingAssembly()

Reflection is very cool, the meta data system of .Net is pretty cool. You can create objects of a given class, without knowing it at compile time, by just looking it up and instantiating it using reflection. But how can I look up a type? Some times you only know the name of a type you want to create, without knowing the correct assembly. Let’s say we have an assembly, that holds a service implementation to create a object:

class MyService
{
  object GetObject(string typeName)
  {
  }
}

The class we want to create, is in the assembly from where that function gets called. That is ok, but we don’t know that assembly at compile time, we can only find it out, when the function gets called. But how?

The regular solution would be, to use System.Reflection.Assembly.GetCallingAssembly(). But when we do this in .Net Nativ, we get an exception at runtime:

Unhandled exception at 0x78A7B264 (Windows.UI.Xaml.dll) in BlankApp3.UWP.exe: 0xC000027B

I think this is a bug within the .Net native compiler. But how can we find a workaround for that problem?

1. using a fully qualified type name

object GetObject(string typeName)
{
  var type = Type.GetType(typeName);
  return Activator.CreateInstance(type);
}

You can then actually use the complete name, including the namespace, when calling the function. (Something like: GetObject(“BlankApp3.Views.MainPage”)), so it’s not possible to lookup a type by name. But for our use case, it is enough.

2. lookup the assembly by name

object GetObject(string assemblyName, string typeName)
{
  var assemblies = AppDomain.CurrentDomain.GetAssemblies();
  var assembly = assemblies.FirstOrDefault(asm => 
                 asm.GetName().Name.Equals(assemblyName));
  var type = assembly.GetTypes().FirstOrDefault(t => 
             t.Name.Equals(typeName));
  return Activator.CreateInstance(type);
}

This is the most flexible solution in our case (but it takes more time). You can even look through all loaded assemblies, and find types by name. Please be aware that there is another bug, preventing you from getting all types from all loaded assemblies (the solution can be found on stackoverflow).

How to assign properties (fast) in C#?

Ok, the short answer to that question is easy, just assign it directly. That’s it, and this is the shortest blog post ever. But actually that’s not the point, I wanted to make. There are a bunch of methods to assign a class-property with a specific value, but how do they differ, when it comes to performance. Even though I can guess, that Reflection is probably very expensive, I have no real feeling to what degree. My measurements also came up with a surprise, I didn’t expect when I started this out.

The setting

For me, it’s very interesting to investigate that on .NET Standard with C# in UWP, because we are currently developing an App with Xamarin.Forms. Please keep in mind, that the results may differ on .NET Core or other targets, but I think there will be no dramatic difference.

We will generate a TestClass with a property Sum, afterwards, we will read the value, add an iteration variable to it, and write it back to the property. Let’s do that more than 10000 times, so we get a good feeling for the performance.

What possibilities we have?

Let’s do some brainstorming on what kind of methods we have to read and assign a value to a property.

1. Direct assignment

   obj.Sum = obj.Sum + i
   

2. Reflection

   var type = typeof(TestClass);
   var sumProp = type.GetProperty("Sum");
   var val = (int)sumProp.GetValue(obj);
   sumProp.SetValue(obj, val + i);
   

3. Function

   var func = (Action)((TestClass o, int n) => { o.Sum += n; });
   func(obj, i);
   

4. Dynamic

   dynamic objDyn = new TestClass();
   objDyn.Sum = i + objDyn.Sum;
   

Let’s start the test

First of all, we try to find out how long the first call takes. I assume, that the first access of a property takes longest. Afterwards it’s probably way faster. But enough talk about what might happen, get it on:

The measurements are in 10^-7 s. As we can see, the first calls with dynamic objects is very slow. All other methods are really close to each other. Is this just because of the Debug mode? How about compiling the code with .Net native? Maybe we can distinguish the methods better in Release Mode.

This seems to be a better solution. We can see, that direct assignments and function calls are very close, and take no time at all. The function call is a little bit slower, just because of the overhead of the function. Reflection is slightly better in .Net nativ (app. 50%) and dynamic calls are 95% faster in native build, than they are in debug mode.

But when we think about a real App, the first call isn’t very interesting. Just assume we have an App to manage our Customers. A customer object has 20 properties (name, street, zip code, etc.), we have about 5000 customers, and a page that shows all customers in a table. Our Model needs to be mapped to a ViewModel to show it on the screen. That gives us 100.000 assignments. I think this is a very realistic scenario, we can investigate on. (we will skip the first assignment call in our measurements)

What we can see, is that (as expected) function-calls and direct assignments take nearly the same time. Dynamic assignments are surprisingly fast, and reflection is very slow. But what does “slow” mean in that context? Have a look at the times measured:

1. direct: 1,2 ms
2. function: 2,0 ms
3. dynamic: 7,6 ms
4. reflection: 74 ms

We got so far, let’s have a look at the same setting with .Net native builds:

Where is direct and function? Both measurements are under 1ms, so there is a real boost. But there is a big surprise – What happened to dynamic????

1. direct: 0,12 ms ( -90%)
2. function: 0,3 ms ( -85%)
3. reflection: 45 ms ( -39%)
4. dynamic: 249 ms ( +337%)

I’ll investigate that issue on one of my future posts, if you have any ideas, how this could happen, please feel free to add a comment.

Conclusion

There is an eligible reason, why Microsoft introduced the dynamic objects. Dynamic objects are very common in scripting languages like PHP or JavaScript. When you use it to parse responses of a Rest-API or just want to read data from a Json in your own object structure. This is really neat because you don’t have to create an own class structure, that is only used as an intermediate layer.

I am very curious, so I also tried to use ExpandoObjects and in contrast to that a Dictionary<,>:

1. ExpandoObject: 800 ms
2. Dictionary<,>: 5 ms

So you should definitely try to use Dictionaries instead of any dynamic approach. It’s a little bit harder to code, but it seems to be worth it.

When it comes to reflection, you probably can not avoid it – it is also one of the big strength of C# and the .Net Framework, that makes it so flexible even when it’s still a strongly typed programming language. Although I will be careful in future developments, to find more conservative solutions, when possible.

Almost forgot… the winner is

direct assignment… I dare you knew that before 🙂