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.
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.
Today I want to talk about adding log4net to a new project. It’s not hugely complicated or high-tech, but there are a few factors that mean I always seem to struggle with one aspect or another. There’s usually an irritating couple of minutes when I’m Googling questions and seeing purple links! This post is a sort of memo to myself then, and perhaps next time this post will be among those Google results!