.Net

Running certain tasks in a scheduled manner may be an easy solution for many problems. One might be refreshing the application cache when the data needs to be fresh and warm no matter what the actual traffic is. Other could be the synchronization or periodical clean-up. There are obviously few good architectural patterns to do it in more elegant and efficient way - distributed queues, publish-subscribe models, enterprise service buses etc. But the simplicity of scheduling still might be an important decision variable.

It’s always good to have static code analysis in your build process. I guess no one these days argues with this statement. This usually forces developer to make conscious decisions on code-level performance, reliability, security, design etc. Few times CA warnings saved me from producing a quite nasty bugs. Sometimes however FxCop yields some really strange stuff.
This post will describe the one I stuck with some time ago. But more interestingly it shows that sometimes .Net developer must look deep under the hood of high-level language abstraction to solve certain issues.

Writing a component for parsing XML files with XMLSerializer I had to provide DTD validation (DTD file was already created long time ago so there was no sense for creating XSD schema). The component must have been able to work in console application and web app (as a SharePoint timer job) so there was no chance to guarantee the same paths for DTD file (which was always specified in doctype directive in processed files). In such situation I’ve decided to deliver the DTD file as embedded resource in component assembly.

Have you ever had a problem with a user complaining on and on that when he clicks some button in your application his computer hangs but it works fine on any other machine where you have tested it? The web service is consuming all the available memory in completely indeterministic way? Or maybe your web application is magically crashing on production machine when it works in the same usage scenario on development and test environment? If not, you are probably in about 1% of the most luckiest developers in the world (or you are not the developer).