Interesting observations when putting your software up for download

I've had a few programs up for download as freeware on popular download sites (such as download.com). In fact, my latest program (HTML Combiner) is up there now as well. On my website, I also employ the free statistics tracking software called statcounter.com (a great service).

I'm always amazed by the diversity of people visiting my website. A look at the stats reveals people from across the world, using different OS versions, and especially the site linking to them. A couple interesting observations:

• Most people (> 50%) of my visitors are using Windows Vista/Windows 7
• Although the majority (60%) are from the US, that leaves a significant portion from other countries
• The referring links come from websites that are hosting my software when I haven't submitted it to them. 

I thought the last point was really interesting. There are a lot of software download websites that seem to just pick up the programs and host them without notifying me. Now I'm not giving any specifics because to be honest, I don't mind the traffic and my programs are free anyway. But if they weren't free, I might be more interested in this observation.

This is recurring for each program I've put up for download (3 of them...) and interestingly I find them also posted on warez websites (by a google search) even though my programs are totally free!

What happens when you just set a Stream position to zero (C#)

This morning I was fixing a few bugs which I had found in HTML Combiner and I noticed a few of my unit tests that loaded configuration files were failing. They were using a MemoryStream object so that they read from a string instead of the file system. The first thing I thought was that it was just a problem reading from a string, and wouldn't happen when reading from an actual file.

Of course then I ran the program and notice that when I loaded the configuration file for my website, my tags were showing up twice. After setting up NUnit to run in visual studio and stepping through the debugger, it was in fact reading the file multiple times.

After spending about an hour wondering what was wrong, I casually glanced at a few links on google about resetting a stream position (which I do at the beginning of the method). Finally, I made it to the StreamReader.DiscardBufferedData example code on the MSDN library website.

If you change the stream position using Seek, the actual position of the buffer is now out of sync. So you have to call DiscardBufferedData in order to force the stream to go to the desired position. After I added this line everything worked once again:

sr.DiscardBufferedData();          // where sr is a StreamReader
sr.BaseStream.Seek(0, SeekOrigin.Begin);

This made me glad that I've been adding unit tests to catch things like this -- I might have overlooked the problem the tests weren't failing. Another similar incident happened a few days ago when a small bug was introduced after I made a change, the bug would result in the build path not being loaded from a configuration file. The actual problem looked pretty innocent, it would have taken time to isolate the cause. However, I was able to catch it because the test failed shortly after I had made the change.