As it turns out, I clearly need to spend more time dealing with .NET’s unique version of “dll hell” because this really bit me. A couple of weeks ago I installed the .NET 4.5 framework on my server. This server hosts almost all of my websites, my brother’s and a couple sites of a friend of mine. In theory, this should have been fine. In reality, it caused major problems.
A while back I wrote a little sample of a web crawler. It was not terribly sophisticated but has been the biggest draw to this blog through search engines for some time. This is likely because it ranks very high (why I am not sure) in Google's rankings. For example, my crawler sample page ranks #1 in Google for "c# web crawl" and #3 for "c# web crawler". Neat.
Ran across a post today on the null coalescing operator in C#.
A few months ago I drastically changed how the urls on my site were built. I moved to using the ASP.NET 2.0 virtual path provider to make more friendly urls. Because I changed the "directory" structure, havoc was wreaked upon my unsuspecting relative urls. I had to go through my posts and look for bad links. I figured I might had missed some.
No, I'm not there. But I just watched the keynote live :). I must say, Microsoft continues to blow the developer in me away...
So I was running FxCop on a library today and it decided to flag a problem, exposing List<T> publicly outside of a class. The recommendation was to use Collection<T>. The reasoning was sound, but there is something in the documentation that needs to be cleared up.
We are switching a project I'm working on from a custom logging solution to the one built into the Enterprise Library, the "Logging Application Block". This is nice, because it means we can get rid of quite a bit of custom code (that's code we no longer have to debug or maintain). The logging application block is very well done as far as I can tell thus far. It makes it very easy to configure logging without having to change code.