This error is thrown by Visual Studio when you run out of disk space.

I got this because I ran multiple performance profiles of my pet project ClosedXML and forgot to delete them as I was testing. Apparently not many people forget to do this because I couldn't find anything about this error on the web.

For the last 6 months I've been working on an open source project to make Excel files and now it's at a point where I can start "promoting" it. I called it ClosedXML and it's hosted on Microsoft CodePlex.

The reason for the name is simple, after seeing how horrible it is to deal with Open XML files my first thought was "If this what it's like to work with Open XML I'd rather work with something that was closed!".

The component is coded in C# but can be used by any .Net language like Visual Basic (VB). It has many features geared toward handling data, for example you can set the value of a cell to an IEnumerable of any kind and ClosedXML will create a table from that object (it works with DataTables too).

For a full list of features as well as a plethora of examples please go to ClosedXML - The easy way to OpenXML.

To be more precise the title should have been "The case against enforcing Test Driven Development (TDD) as a strength jacket onto developers". I have absolutely nothing against people using TDD if it helps them write better code. The problem I have is with forcing developers to think and behave in a way that it's not natural to them. Those who want to use it fine, the ones that don't let them be.

More...

I recently attended an event of .Net Rocks! (one of my favorite podcasts). They were "on tour" making a show on 15 cities throughout the country. The event was divided into the following 3 sections:

• Ivar Jacobson's Interview:
• Richard's presentation on load testing
• Carl's presentation on Silverlight 4

More...

I'm a big believer in the 80-20 rule (http://en.wikipedia.org/wiki/Pareto_principle) because I see it work almost every day while developing business applications. After gathering the requirements and sketching the application, we try to identify that 20% of effort which will give us 80% of the results. Usually after building it, our users are so satisfied with the product that we only have to tweak a few more things and move on to the next high value item. If the business side thinks it's worthwhile to invest more in the product we proceed to identify what else will give the company the best bang for their buck.

The phrase "Use the right tool for the right job" gets thrown a lot and in my opinion it's just overated. You're much better off learning to use a small number of tools very well than trying to learn how to use a plethora of tools because you want to use the right tool for the right job. More...

In part 1 we looked at how we can implement tracing and debugging to know what our program is doing and any error it may encounter. In this post we'll take a look at more ways to use the Trace and Debug classes, the listener's output, and implementing an easy way to get plenty of information in our trace files with minimal code.

In these examples we're going to use a lot of boilerplate code. This is only necessary for us to show what kind of information we want our trace files to have. In a later post we'll learn how to remove almost all this boilerplate code and still have all the tracing functionality we need. 

The main purpose of this post is to give you ideas on how you can implement tracing in your own applications.

More...

This is the first in a series of posts to shed some light into tracing and debugging techniques. We'll start with the basics, configurations (via code and settings file), and then move on to more advanced topics like implementing your own customized trace listener and using aspect oriented programming to trace/debug an entire class/assembly by adding an attribute to it.

In this post we'll take a look at simple debugging and tracing techniques in the .NET Framework. More...