I went ahead and added a single RSS feed to my site.  I ended up using the RSS Toolkit that can be found on Dmitryr's blog.  It was very easy to get the tool kit to publish RSS.  I need to bounce the RSS XML format against the 2.0 specifications to be sure I am emitting decent RSS. 

I had one problem with the control that comes with the tool kit.  I attempted to create multiple channels based on the Blog Catagories that I have defined in case someone would want to subscribe to only a specific catagory.  However when I placed this control in a repeater whenever a post back occurs I get an error stating this "is not a valid virtual path".  I suspect it has something to do with the control when it is trying to append the ChannelName to the query string.  For now I just removed the subcatagory RSS feeds.

Well I decided to move my blog off of .Text and onto a custom blog application that I am writting from scratch.  I didn't really have any problems with .Text but I wanted to create some new features and I did not have the source.  So as it stands right now I have limited blogging features in my custom solution.  I was able to migrate my data out of .Text and into the new schema without much issue.  I have some old links to the old blog that will have to be changed.

I will be slowly adding the following features:

• RSS Feeds - Done 6/4/2006
• Ability to add comments
• Blog search
• Support for blogging API so that I can add blog entries from a smart client application
• Submit blog entry by email
• Ability to create blog entries but delay the publishing of the entries - Done 6/10/2006

In my day job at JDA Software I have been looking at code coverage options for determining the effectiveness of our testing.  My team uses four types of tests to test the software we write.

• Unit Tests - Tests focused on a single component of the application.  These tests are MSTests that exercise a specific software component and typically mock out any dependant components.
• Integration Tests -  Tests focused on multiple components of the application.  These tests are MSTests that exercise a component and it's dependencies to ensure the components work together.
• Manual Tests - Tests that are executed by are testers manually from a GUI interface. 
• Automated functional test - Tests that are scripted in a fashion that can be repeated build after build to ensure the build is still functional.  Sometimes referred to regression testing.

The goal of implementing a code coverage process was to determine the effectiveness of the types of tests listed above.  Visual Studio 2005 Team Edition (for testers and developers) provides some nice code coverage features we wanted to tap into.  Code coverage of unit tests and some integration tests worked fine from the visual studio IDE.  But for the integration, manual and automation tests that used web services we began to run into problems.  The web services that where hosted under IIS where not getting covered.  After some research I determined that code coverage under ISS was not going to work.  So I started looking into alternatives.  One thing I noticed is that web service projects that where not hosted under IIS had no problem getting covered.  These types of projects used the development web server that comes with ASP.NET 2.0.   So I decided to look into using the same development web server in place of IIS for code coverage purposes.

The generic steps for establishing code coverage for web services is as follows:

1. Turn on instrumentation for the binaries that you want to cover
2. Start the coverage monitor
3. Start the development web server for a specified unused port pointing to the folder that is supposed to represent the web service.
4. Execute your tests
5. Stop the development web server
6. Stop the coverage monitor
7. Review the results in Visual Studio 2005

For the following commands use the Visual Studio Command prompt.

Turning on instrumentation of assemblies from the command line is done by the following command:

vsinstr -coverage myassembly.dll

To start the coverage monitor you use the follwoing command:

start vsperfmon -coverage -output:mytestrun.coverage

To start the development web server use the following command:

start WebDev.WebServer /port:8080 /path:c:\mypath

To stop the development web server simply right click on the task bar icon for the web server and select stop

To shutdown the coverage monitor use the following command:

vsperfcmd -shutdown

We were now able to do code coverage of all types of tests that we planned on implementing.  Some of our test runs are going to executed by the build and some will be executed by the testers.  Since VS.Net 2005 supports the ability to merge code coverage results this should not be a problem to combine all runs into a single report that now shows how effective our tests really are.

Some references to articles that help me come to this conclusion:

Command Line code coverage:

http://blogs.msdn.com/ms_joc/articles/406608.aspx

Using WebDev.WebServer from the command line:

http://www.devsource.com/article2/0,1895,1886246,00.asp