C# dynamic – A friend you may want to keep a distance
Tags: net, csharp, dynamic
Published: 2019-08-19 20:26:50

---
title: C# dynamic – A friend you may want to keep a distance
published: true
tags: .NET, CSharp, dynamic
canonical_url: https://ankitvijay.net/2019/08/18/c-dynamic-a-friend-you-may-want-to-keep-a-distance/
---

Recently, after one of my PRs which was merged to master, my teammates started complaining about a weird scenario. On some occasions, the ASP.NET Core app hosted inside the IIS worker process (w3wp.exe), would simply die without any exception/ warning. There were no clear repro-steps and it was difficult to pinpoint what was causing the issue. It took me some time to figure out the root cause of the issue and it turned out to be quite an interesting issue.

## Background
As part of my PR, I had added a new code to map a `Repository` `object`/ entity to a `Dto`. It was quite complex and a multi-level nested `entity`. I did not use the library such as `Automapper` to automatically map the entities. Why I chose to do mapping manually could be a discussion for another day. Anyways, the culprit code went something like this.

We had an `abstract` base class, let us call it `AbsractBaseRepository` and this class was derived by as many as 18 different child classes. Something similar to below:

{%gist https://gist.github.com/ankitvijay/8beab053e5f6a0a73e8a3ecfb6b51374 %}

The `AbsractBaseRepository` was then used by one of the nested child Repository as below:

{%gist https://gist.github.com/ankitvijay/9d386b3fa7b737ca1a096062c5d335d8 %}

The `Dto` which was mapped from this `Repository` had a similar structure.

{%gist https://gist.github.com/ankitvijay/bfa10d31f8391ad1c9b0344a55993ba9 %}

{%gist https://gist.github.com/ankitvijay/a22ca3ee7ba57022dcc7420f2831d6fc %}

Why and how we ended up with this structure is again out-of-scope of this post. To map the `Dto` from `Repository`, I tried to be a little bit smart/ lazy and used C# `dynamic` as below:

{%gist https://gist.github.com/ankitvijay/faa37402c6b3d5d441259e24ceb34d12 %}

In the above code, casting the `repository` parameter to `dynamic` implicitly converted the base `repository `object` to the derived `repository` and call the correct overload of `ToDto` method.

## The Issue
Unfortunately, I turned to be too smart for my own good. I missed the mappings for one of the derived `Repository` class. In a scenario where the missed derived `Repository` was present in the `entity`, the code execution fall-back to base class overload method, that is, `ToDto(SomeAbstractRepository repository)`. This resulted in an infinite loop causing the process to crash during debugging. Since there were as many as 18 derived `Repository` classes this was somehow missed in integration and unit tests as well. The easiest way to fix this was to simply add the mapping for the missed `Repository` class. However, it presented an additional risk, what if we add another derived Repository and we miss adding the mapping for that Repository? In that scenario, we would land up in a similar situation.

## The Fix
As a fix for this issue, I decided to go back to basics and use explicit conversion to map the `Repository` and `Dto`, even if it meant more lines of code. The explicit conversion helped us to identify the issue at the compile-time or in the worst case throw a clear exception at run-time instead of blowing the entire process without any exception at the run-time. The updated code looked something like below:

{%gist https://gist.github.com/ankitvijay/faa37402c6b3d5d441259e24ceb34d12 %}

## Lessons Learnt
An important lesson which I learned while resolving this issue was to be extra cautious while using `dynamic`. For all the power `dynamic` brings, it comes at a cost. _Personally_, I try to avoid `dynamic` as much as possible and this issue just gave another reason why I would continue to do so.