I’ve recently blogged about how excited I am by the promise of Blazor. Well, I’ve built my first Blazor app and, having tried it, I’m no less excited. There are still plenty of rough edges (which I talk about below), but it fundamentally works. In this post, I’ll try to outline the pitfalls as best as I can, in the hope that others find it useful. Please don’t construe anything I write as a criticism of the Blazor team – what they’ve done is already game-changing.
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!
If, like me, you’re coding education was (ahem) “non-standard”, you might not have given much thought to the underlying mechanics of how .NET uses memory. Us C# developers are a bit spoilt really. We can pretty much get on with the coding, without having to concern ourselves with allocating memory or worrying about leaks. The CLR does an excellent job of sorting it all out behind the scenes.
It was only when boxing came up in a conversation recently that I realised how flakey my understanding of memory management in .NET really was. I mean, I sort of knew the concepts, but I think I thought I knew it better than it turned out I did. So I went away and brushed up and thought I might as well share my new understanding. In this post I’ll try to cover some basic concepts, such as value types vs reference types, the stack and the heap, and boxing and unboxing. I’ll finish by explaining both why you should care and why it’s less of an issue these days. In future posts, I may go a bit deeper into some of these concepts, using this post as a reference. Continue reading
Today I came across an Entity Frameworks edge case: I needed to retrieve the value of a property set by the data provider when an entity is added to the context. In this post I’m going to outline the problem, explain why it happens, and provide two solutions.