Contributing to the .Net Runtime
My First .Net Contribution
Today a feature enhancement I proposed and implemented was merged into the .Net runtime main branch for .Net 6 release!
The Background
At the time I was working for a company called, WatchGuard Video. WatchGuard built body cameras and the evidence management software for them. I was hired originally to come in to help launch Evidence Library.
The site, when I started, was several independent SPA sites in a mono-repository. Myself and the other engineers were working on upgrading ASP.Net Framework to .Net Core. One of the biggest concerns, beyond authentication, was configuration.
The independent sites I squished back together into one SPA and we started the process of migrating configurations. During that time we were migrating more and more configurations from resource files to a cloud build system.
To support the effort I updated all the site and project configurations to read in the old .Net Framework project settings files, JSON, and Environment variables. I did this by using the .Net configuration extensions.
The Problem & Solution
Immediately I ran into problems reading in the inconsistently named configuration key names.
The JSON configuration settings had names like, some.flag that get loaded into the IConfiguration dictionary. The dictionary key to property name mapping is done via JsonPropertyNameAttribute on the class properties.
The .Net configuration binder does not know of anything outside of the objects actual property names when it attempts to lookup the key’s value by property name in the configuration dictionary.
I created an implementation of iterating over the property attributes to look for any that contained a name string value, and using it to lookup the configuration value by that key value.
I used this customized version of the .Net configuration binder, but that created unseen technical debt to anyone not familiar with how the .Net configurations worked internally.
I knew I needed to get this officially added to .Net to avoid a home rolled hack.
The Timeline
Dec 28, 2019: I proposed the implementation I’d created to the .Net runtime team. I created a GitHub issue and then pushed the implementation as a proposal via Pull Request (PR.) I learned later that’s not exactly how you’re supposed to contribute.
Jul 27, 2020: The issue sat dormant for a long time as the .Net configuration repositories were eventually moved into the .Net runtime repository. In July, a Microsoft engineer engaged on the proposal and determined where it fell in terms of area of contribution.
Aug 11, 2020: Was asked to update the GitHub issue to fit the .Net runtime API proposal format.
Oct 1-Nov 30, 2020: Back and forth on implementation decisions. Decision is made to go with a specific custom binding attribute. API proposal was updated.
Mar 26, 2021: Eventually, the .Net runtime team reviewed and approved the API proposal. API proposal was labeled as “up for grabs.”
Mar 28, 2021: I created an implementation using a new custom binding property attribute to perform configuration lookups.
Apr 13, 2021: The implementation goes through code review, is approved, and merged into the .Net runtime main branch for the .Net 6.0 release.
Final Thoughts
I started using .Net in college back in the early 2000’s. Today a feature enhancement I proposed and implemented was merged into the .Net runtime main branch.
It wasn’t a huge enhancement, but the fact I was able to contribute to the .Net runtime feels surreal. Only thing I can compare it to is catching a fly ball at a baseball game.
I’m also thankful that now my previous companies engineers won’t be stuck without an official solution when they update their .Net core versions.
Win win. Good day.
-Rob