In my last post, I discussed what my production environment looks like for ImaginaryRealities.com. In this post, I’ll discuss my development environment that I’m using to build the ImaginaryRealities.com web site. I won’t focus so much on the hardware than on the software and tools that I’m using to build the web site.

First, my main development machine in my den is running Microsoft Windows Vista with Service Pack 1. The reason why I’m using Vista is that I guess that I’m one of the few that do like it over Windows XP. Also, Vista has IIS7 and Vista SP1 added all of the additional IIS features that are available with Windows Server 2008, which means that I can develop for Windows Server 2008 on my Vista desktop.

For database development, I’m using Microsoft SQL Server 2005 Developer Edition on my computer. This edition allows me to use the full set of SQL Server development tools and servers to build and test my application, so I can maximize what I do in the production environment.

For version control, I’m using Subversion. Subversion, in my opinion, is the best version control system on the market, even better than Microsoft TFS. Plus, it’s a free and open source product, so the cost per user is pretty minimal. Since I’m on a tight budget which competes with my bills and play money, the cost is very important. And for a single user (me), it works very well.

For development, I’m using Microsoft Visual Studio 2008 Team System Developer Edition with Service Pack 1 installed. Since my production environment is running .NET 3.5 SP1, this version of Visual Studio with the service pack will allow me to develop for the full feature set available to me in the production environment.

For building my software, I’m using customized MSBuild scripts that I’ve built by hand. MSBuild comes with the Microsoft .NET framework and is very easy to learn. It does a good job. Before MSBuild, I used to use NAnt, but after making the switch (which I was initially reluctant to do), I don’t see much of a reason to go back to NAnt although I’m sure it’s still very popular.

For debugging purposes, I use the Microsoft Debugging Tools for Windows tools to create both public and private symbol stores and source code servers for the source code that I write and the projects that I build for personal and public use. I combine Debugging Tools for Windows with the source code for the book Debugging Microsoft .NET 2.0 Applications by John Robbins to further enhance my development and debugging environment.

Not all of the code that I write is intended to be personal or closed-source. I have done some open source development. There are also tools that I build from the original open source distribution that I modify for my own purposes, such as to add a strong name key because I like to strong name all of my .NET assemblies. Or in some cases, I may bring together multiple related open-source projects that use each other, but are not necessarily based on the same version of their cousins that I am using. In that case, I may import their source code into my Subversion repository and make my own “official” release of the tools that I may choose to put on my web site to share with others. In that case, I will also share the source code and symbol files on my public symbol and source code server.

In case you’re not familiar with the concept of a symbol server or source code server, check out the Debugging Tools for Windows. To quickly summarize, one of the outputs of a software build is a set of files with the extension “pdb.” These PDB files are known as symbol files and contain information that the debugger will use to locate each line of code and match locations in memory to variables or object fields. Without the PDB files, a developer is flying blind when debugging an executable image. The PDB files also contain information about the source code that the executable code was generated from so that the debugger can show the correct line of code to the developer.

Once software goes into production and is released, or if a developer is working with multiple versions of software, keeping track of the symbols and correct source code for any particular version of a software product is hard to do. This is where the Debugging Tools for Windows comes in handy. Using tools that come inside of the Debugging Tools for Windows, I can publish my PDB files to a location such as a web server (internal or external), disk directory, or network share and create a symbol server. During debugging, the debugger will automatically look at the symbol server, match the executable code to the exact version of the PDB file in the symbol server, and download the PDB file into the debugger. All that I need then to debug my code is the actual executable files so that I can attach to the executable in the debugger and get the debugging and symbol information.

To take this a step further, the PDB files contain the full path to the original source code that the executable code was generated from. This can be a problem when you have two or more developers or two or more machines, because developers are very individualistic when it comes to their development environments and I have yet to see two developers put their source code in the same place. Some companies that I’ve worked at, such as JDA Software, tried to make company standards where developers put their source code, but that never worked out because “I know the developer that came up with the standards, and I’m much smarter and better than that developer.” (This is meant as a generalized figure of speech and not as a derogatory remark towards any one person…it’s basically the arrogance that all of us software developers share.)

To fix this source code relation problem, Debugging Tools for Windows includes a set of tools collectively called Source Server. There are a couple of ways of using Source Server. First, I can take all of the PDB files that I’ve created through my build process and, before putting them into my symbol server, I can replace the physical file paths for the source code with executable commands. These executable commands instruct the Visual Studio or WinDbg debugger on how to execute my Subversion client to extract the exact revision of the source code that the executable code was generated from. By doing this, during debugging, I don’t have to have all of the source code in a specific location on my hard drive. As the debugger encounters code that it doesn’t have the source code for, the debugger will extract the version control command from the PDB file and will then execute Subversion to extract the relevant revision of the source code so that the module or program can be debugged.

To take this a step farther, what about open source software or other tools that I make available to other developers? I don’t necessarily want anyone going through my Subversion repository, and I don’t want to make my Subversion server accessible outside of the firewall, but I want other developers to be able to debug my programs or assemblies or at least be able to walk through the code when trying to figure out problems in their programs. To do this, I go one step farther and make available a public source code server and symbol server.

The symbol server is the easy part, because all that I have to do is copy my symbol server database (which is based on a directory structure) out to a public web site with normal HTTP access. For the source code, once I have indexed the PDB files, I can run another tool in the Source Server suite that will extract the source code from my Subversion repository and create a web server-friendly directory structure that the debugger can understand. Once the source code is extracted, I can then run one last tool that will replace my source code references in the PDB file with the URLs of the source code on my public web server.

One last concept to discuss here related to my public symbol and source code server is where to host this stuff. First, these files could occupy a lot of space over time, especially the binary files in my symbol server if I store not only the PDBs but also the EXE and DLL files. I would do this if I’m going to be doing debugging or analysis of crash dumps that are reported to me (this is another series of posts that I hope to tackle in the future). My production environment on my shared hosting account only gives me 3 gigabytes of storage space, and I’d prefer to use that and my server bandwidth for application processing by my web site and not necessarily serving static data. What I need is another solution that’s reliable (relatively), publicly accessible, and very cheap (because remember budget is a concern giving my limited income until I get customers buying products from me).

The answer that I came up with is to use Amazon’s Simple Storage Service, also known as S3. S3 is a web-service based storage service provided by Amazon.com. Any kind of information can be stored on S3, and I can control who gets to access my information. Also, S3 provides both SOAP and REST APIs for the data stored on the S3 servers, so I can technically serve content over HTTP from an S3 server. The cost for storage on S3 is also pretty reasonable:

• $0.15 per gigabyte per month of storage used
• $0.10 per gigabyte per month for uploading data to the Amazon S3 server
• $0.17 per gigabyte per month for the first 10 TB of data downloaded from the Amazon S3 server.
• $0.01 per month per 1,000 PUT, POST, or LIST requests (mostly used when uploading to the Amazon S3 server)
• #0.01 per month per 10,000 GET and other requests (used when downloading content from the Amazon S3 server)

That means that to share my symbols and source code, it only costs me $0.01 for each set of 10,000 source files or symbol files are downloaded from my server. While I haven’t shared any code yet that uses these servers (I will be soon), my highest bill from Amazon so far was for $0.18 which came last month and mostly involved uploading to the servers.

The other thing to consider when looking at the Amazon S3 service is that this would be a great addition to my production environment. I could use it to host static content such as images, video for Silverlight, ClickOnce deployments, and other downloadable files that I host on the web site.

Now Amazon S3 isn’t perfect. There was a highly publicized outage of S3 about a month ago, but for the most part it seems reliable to me and is much cheaper than the competition or using my hosting account’s disk space for this stuff, so it works for me for now.

In my next post, we’ll start looking at the design concepts for the new web site and will hopefully start writing some production code.