It’s about to be a brand new year. As 2017 ticks over into 2018, it seems like a good time to look back and review what we’ve been up to. ConTabs only really got underway quite late in the year and it’s no way near finished, so let’s call this an interim review. Still, we can see where we are, how we got here, who we met along the way, and where we might go next.
Today’s post marks a bit of a leap into the unknown for me, as I explore using static analysis to improve my code with NDepend. I explain how it can be hard to know where to start, but also how valuable the insights can be. The actionable changes are demonstrated with commits from my development of ConTabs. Finally – in keeping with the expositionary style of this post – I close with some general observations (including an attempt to explain the difference between NDepend and ReSharper).
I ended my last post by throwing my hands up in despair because adding my .NET Standard project via NuGet triggered the download more than 40 irrelevant dependencies. In this short update, I’m going to explain how to get this working.
In an unexpected turn of events, this post is about the pitfalls I’ve encountered whilst publishing ConTabs to NuGet. My decision to make ConTabs a .NET Standard library has meant this was more complicated than I had anticipated. In this post, I’ll start by explaining the old .NET Framework approach and go on to show the new .NET Standard / Core way of doing things. Finally, I’ll talk about some unexpected guests that turned up when I tried to consume my new NuGet package.
After hooking my ConTabs project up to AppVeyor for continuous integration, the next thing I want to explore is automating test coverage reporting. In this post, I’ll talk briefly about the importance of measuring code coverage. I’ll then introduce OpenCover and Coveralls. Finally, I’ll go through my experience of wiring it all together, using AppVeyor as the platform.
For this post, I’ve been exploring the use of AppVeyor to continuously integrate my ConTabs project. I’ll start by explaining what continuous integration (“CI”) means, continue by introducing AppVeyor, before finally getting stuck into the specifics of my experience (including the gory bits).
Today I’d like to introduce a project I’m calling “ConTabs” – simple, but flexible table generation for console applications. As well as simply being an open-source project, I’m also planning to use ConTabs as an excuse to explore some of the interesting aspects of modern .NET development.
In today’s post, I want to share a trick I discovered: using Stackoverflow to help answer my questions. Before you stop reading, I mean without posting my question at all. In fact, I simply rediscovered the time-honoured tradition of “rubber ducking”. I think Stackoverflow provides the perfect place to rubber duck and I’d like to share my reasoning.
Have you ever wanted to test the behaviour of a method, without making it part of your public API? Have you ever been forced to choose between compromising on the encapsulation of your business logic, and ensuring that it behaves as expected? Allow me to introduce the
InternalsVisibleTo attribute! In this post, we’ll look at what this lets you do, but we’ll also touch briefly on the debate surrounding its use.
Today I had reason to do something I haven’t had to do in a really long time: add IntelliSense hints to a library we supply. Because it’s been so long since I last did this, I had to look up one or two details, so I thought I’d share a quick summary.