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.
Author: Tom
The perils of publishing a .NET Standard library to NuGet
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.
Continuous monitoring of test coverage with Opencover and Coveralls
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.
Continuous integration in the cloud with AppVeyor
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).
Introducing ConTabs – a vehicle for exploring modern .NET development
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.
Rubber duck debugging with Stackoverflow
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.
Testing without compromise using InternalsVisibleTo
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.
Using XML comments to provide Intellisense hints
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.
PiLights part 1 – kit and test code
At work, we have a system that lots of users interact with, but which sometimes needs some “alone time”. From time to time, we email our users and ask them to close the client application, so that it can do what it needs to do. (Needless to say, this software was not written in-house!) Users being what they are – and emails being what they are – this approach leaves something to be desired.
A colleague and I put our heads together and decided that we needed something obvious, intuitive and highly visible. “What if,” we thought, “we could wire up some traffic lights to a Raspberry Pi?” So that’s what we decided to do. In this multi-post blog series, I’ll outline what parts we used, how we wrote the software, and how we made our little old Pi ready for the enterprise environment. In this first episode, I’ll focus on how we got to a working proof-of-concept.
Tools of the trade – my top 3 peripherals at work
This post was inspired by conversation I had at my desk today. It’s a conversation that takes place every now and again and it always takes the same form: someone will come over to my desk, start using my mouse, and remark on how lovely it is. They aren’t wrong. My mouse is excellent. Not flashy, but quietly brilliant. And it’s not just my mouse either. My keyboard is a joy to type on and I have some pretty nice wireless headphones too.
Now, the point of this post isn’t to boast about all my lovely things. As I point out in these desk-side conversations: these are the tools of my trade. During the week, I spend fully a third of my waking hours using a keyboard and mouse to cajole electrons into doing my bidding. Whilst I’m doing this, I very often use my headphones to shelter my concentration from the noisy open-plan office around me. Given that I’m using these things so much, any minor niggles can add up to become real productivity drains. In short, it’s pretty important to work with decent tools.