#1 underestimated risk in .NET projects:

Libraries you add to your code.

Yes.

They are necessary in every project.

Yes.

They speed up development massively.

But, I've faced many maintenance issues while working with libraries in the past 12 years.

The most expensive time it happened to me?

I was working on a project where I had to parse incoming Excel files.

For that, I used EPPlus, a popular open-source library for handling Excel files. The library was great and made development faster and easier.

But several months into the project, after we completed a lot of features:

1. EPPlus became a paid product and required a commercial license.
2. It meant we either upgraded or got stuck on the 4.5.2 version. And miss out on new features and critical security updates.
3. The company eventually decided to upgrade since Excel import and manipulation were critical for onboarding new clients to a platform.
4. So they decided to buy 5 licenses for my team.

Each license cost $409 per developer per year (a total of $2,045). In this case, the ROI of using this library was greater than the cost.

But when you lock in on a library, you need to be prepared for things like this.

After all, every library you add is a maintenance burden and a risk.

​

Common risks when using libraries (and how to minimize them)

Here are some common risks when using NuGet packages:

• An open-source library becomes commercial - as explained above, it happened to me.
• Library goes obsolete - and no-one maintains is anymore. Best case, you rely on someone from the open-source community to fix the bugs. Or delve into source code and fix it yourself.
• Security issue - a security issue in the dependency means a security issue in your application.

To minimize the risks:

• Abstract libraries behind interfaces you create. This makes changing libraries a lot less of a challenge.
• Minimize the number of libraries. Don’t import the whole library if it contains something you could easily build in a few hours. The next section will help you with this.
• Upgrade as frequently as possible. Take a look at the last part of the email if you want to automate NuGet upgrades.

​

4 wickedly effective questions you have to ask before adding a library

Before adding a new library, here are 4 questions I have:

1. Is it popular? How many downloads does it have?
2. Is it actively maintained? How many developers maintain it?
3. Could this library introduce a major security issue to my project?
4. How easy, straightforward, and fast could I build library features I will use?

Based on the assessment, I either decide to:

• Use the library
• Look for an alternative.
• Build my own solution if it doesn’t require too much upfront work and ongoing maintenance. But be careful so you don’t fall into reinventing the wheel trap.

​

How to update libraries automatically using GitHub robots

You can use a built-in GitHub app to automate NuGet version upgrades:

Dependabot.

Dependabot is a GitHub feature that makes it easy to update your NuGet packages. It can also notify you when the package you use has a security bug.

But it’s not limited to NuGet. It also supports:

• npm
• Gradle
• Maven
• Docker
• … and many more

To enable it, follow the instructions on this page.

After you set up everything, you will start to get automated Pull Requests:

​

As a summary:

Be picky. Use libraries.

But treat them as a potential liability.

Not as an asset.

​

Enjoy your weekend.

Kristijan

​

​