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!
I recently discovered Project Euler and have become an overnight evangelist. For those of you unlucky enough to not have discovered it yet, Project Euler (pronounced “Oy-ler”, by the way) is a series of maths problems that lend themselves to being solved with programming.
In my humble opinion, Project Euler is great. So great, in fact, that I thought I’d spell out exactly why you should give it a try. So here goes, 4 reasons I think you should give it a go.
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
In my current role, I find myself working a lot with our sales handling pipeline. It takes an order through our API and starts a set of processing pipelines for things like fulfilment, accounting, and our CRM system. Because the main entry point of the pipeline is an API, I used to find myself using Fiddler to make fake calls to our API in the testing environment.
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.
Welcome to my new blog!
My name is Tom Wright and I’m a software developer living in the East of England. I’m also a father, music-lover, and balloon animal connoisseur, although I don’t plan to blog about any of these things here. Professionally, I spend most of my time working in C# and related technologies on a range of web-based, back-end and integration projects.