Published: 12 Aug 2009
By: Andrew Siemer

In this article we will be setting up the start of our development environment.

Contents [hide]

The Stack Overflow Inspired Knowledge Exchange Series

  • TOC Checkout the project homepage of this series to follow our journey from the creation of the famous StackOverFlow website.
  • Introduction

    In the last article I introduced this article series. We took a look at what we would be covering while discussing a StackOverflow inspired knowledge exchange. I discussed the concept of egoless programming and how it would apply to this series. We then took a look at the public information about StackOverflow regarding what was used to create the site as well as some of the known architectural concepts. Next we discussed the public database that StackOverflow released and what its makeup is. I then briefly touched upon some of the technologies that we would cover.

    In this article we will be setting up the start of our development environment. By the end of this article we will have a version control project set up on CodePlex to support our coding efforts throughout this article series. We will then take a look at what is required of a file and folder structure for a large project like this. From there we will create an ASP.NET MVC 2 web application and test project in a new Visual Studio solution. Next we will download and install the TortoiseSVN client to interact with our version control repository on CodePlex. We will then complete our article by performing our first check in to our version control repository on CodePlex and make our StackOverflow inspired knowledge exchange program public.

    Setting up source control on

    I chose to set up the source control for this project on CodePlex so that everyone could easily get to the source code and so that at the end of the project we would have a wonderful new open source application. Setting up your source control in this way is a great option if you don’t care who sees your code. It provides you with a platform that manages your source control without having to actually manage the platform yourself.

    Once you have created your account you can then move on to creating a new project. Do this by clicking on the Create Project link on the CodePlex home page (once you are logged in). Creating a project is very straight forward. Fill in the create project form and the following forms and you are good to go.

    Once you complete your create new project form you will need to verify your email address and then you are done. You are then able to go to your project’s home page where you can manage all aspects of your project.

    At the top of your project home page you will see “30 days left in setup period.” Next to that warning you have two buttons “Publish This Project” and “Delete This Project”. In order to publish your project you have to do a few things.

    • Edit the project home page to provide information about your project
    • Upload the initial source code for your project
    • Add your project license

    Once you have done those three things you can then publish your project for all to see.

    Now that I have our source control set up we need to see to those last three steps so that we can then publish our site. I will edit the home page of our project to provide more detail about the project. Done! Next I will choose a license type. I am going to choose the Microsoft Public License. It is easy to read and straight forward to understand. And in the end I don’t really care how people use this software but I am forced to choose a license to go public with this project. Finally we will need to upload our source code to complete the process. Unfortunately we don’t yet have any code to check in yet! This brings us to the next topic which is our initial solution structure.

    Initial Solution Structure

    Before we can upload source code into our new CodePlex repository we first need to create an initial folder structure for our solution. I always have a “projects” directory (generally on an external drive). Inside of the projects directory I create a folder for the project itself using that projects name “KnowledgeExchange” in this case. Under that directory I then create a “trunk” directory to follow the standard Subversion way of doing things (they usually have a trunk, branch, and tags directory). Inside the trunk directory I then create a “build”, “db”, “docs”, “binaries”, “dependencies”, and “src” directory.


    In the build directory I keep a copy of the NAnt build file. I also keep various helper files such as batch files and various other entry points into the build file.


    The db directory will house an “updateScripts” folder which will have incremental changes in the form of .sql files for each change to the database. By creating a SQL script for all changes to the database the history of the database is nicely versioned in the same way that all of our other code is. If we need to have data in the database (such as for lookup tables, or initial user accounts) we can also script inserts as well. Once we have this in place we can achieve two things nicely. We can perform integration testing where we run unit tests against our repository layer and test cohesion between our code and our database – and can then nicely role back to a clean environment to develop against. Also, when rolling out new versions of our system our deployment process will be easier to work with as we can execute our changes against the next level environment to deploy our updates.


    Generally when I work on a project of this nature I develop on my local machine. I call this my development or local environment. I would then merge my new code with other people on my dev team by checking in to source control and having some automated process integrate my code with the main branch on a centralized development server. As we move along the development process it would be nice to then move perceived stable releases to a QA server for quality assurance purposes. Next we would push the code up to a performance testing server. And if our code makes it through all of these steps successfully we would then package the code up and push it out to production. Each of these movements between environments is a move to the next level of acceptance to production.

    The db directory will also have a copy of the working database which will be used on a developer’s local environment. This working copy will be the initial baseline for the developer. The developer would make modifications to the schema and data of this database.

    We won’t get to far into understand the build process just yet, but know that we will also have a versioned database in the db directory. The versioned database will be part of the build process and will be used to initialize the developer’s environment or used to revert an established environment back to a clean state.

    The final items in the db directory will be various helper scripts. These might be batch files or SQL files used as part of the build process that directly relates to the database aspect of the build process.


    The docs directory will be used to house research and specification related data. This is a more generic folder that could hold workflows, software specifications, project charters, etc. By having the docs directory as part of your source control (rather than as part of a Sharepoint installation) a new developer will gain immediate access to the documents that they need to be aware of that pertain directly to this project.


    The “binaries” directory will hold any third party programs or assemblies that our project might use. Some examples of this for our project will be StructureMap, NUnit, NAnt, RhinoMocks, NDepend, NDoc, log4net, Elmah, and any other tool that we might need to use along the way. Many people might ask why we would need this to go into our source control. “Isn’t that a waste of space?” Yes, it is. But by doing this it insures that when a new developer “gets latest” to initialize their environment they are getting the correct versions of software that is compatible with our projects.


    The “dependencies” directory will hold all of the assemblies and tools that our projects will be directly “dependant” on. StructureMap for example is delivered with many various assemblies and resources when you download it. We only really need one assembly and a configuration file out of that bunch…for now. We keep all of the remaining resources in the binaries directory in case we need something else at a later date.


    The “src” directory will hold our source code. The root of the src directory will hold solution level items such as configuration files and the like. Other than that all of our specific project level files will go into a subfolder for each specific project.

    Anything else?

    As we continue to build we may end up with more folders. I will explain their use as we get to them. For now I will create these folders to get us started. Then I will create the solution and initial projects in Visual Studio so that we have something to upload.

    Setting up our solution

    Now that we have our source control project waiting for us and our folder structure waiting for us, lets create the solution that we will be working with. To do this we will first need to understand the type of application that we will be building. As ASP.NET MVC 2 Preview 1 just came out it doesn’t make any sense to not start playing with it straight away. So we will get started not by opening up Visual Studio but by navigating to the website and locating the ASP.NET MVC 2 Preview 1 download page.


    What if ASP.NET MVC 2 Preview 1 is not the latest version? Don’t worry! As I work through this project and article series I am sure that a new Preview or Release Candidate will be released. This is a good thing and not something to be afraid of! I will do my best to come back and add notes where applicable as the new releases make some examples obsolete or broken.


    I have ASP.NET MVC 1 applications that I have to support! Will this break them? Don’t worry. Scott Guthrie has stated on his blog that the MVC 2 installer will play nice with MVC 1. You are able to run both types of projects next to each other without fear of breaking your production sites!

    Once you have downloaded and installed the new ASP.NET MVC 2 framework open up your copy of Visual Studio 2008 so we can set up our solution!


    I only have the express editions of Visual Studio – can I follow along with you? Make sure that you have Visual Web Developer Express with SP1. If you are using an older version you won’t be able to work on both a web application and a class library side by side (in an efficient manner anyways). And let me tell you up front that it really sucks to not be able to work on all projects in one solution in one IDE!

    In Visual Studio create a new project. Expand the Visual C# project types and then select Web. On the right select “ASP.NET MVC 2 Web Application”. Then in the Name field enter KnowledgeExchangeWeb. In the Location field navigate to your KnowledgeExchange project directory and then into your src folder. Click OK.

    Then you should be presented with a “Create Unit Test Project” dialog box with “Yes, …” selected by default. Leave that selected and click OK.

    Once Visual Studio is done working you should have a solution window that looks something like this:

    Notice that we have our web project and our tests project! Before we do anything else lets save our solution to a more appropriate location. By default the solution file (.sln) has been saved into our first project which in this case is the web project. Not only does a .sln file have no reason to exist in that project but once we have a handful of projects and a ton of files it will become quite interesting to find the solution file! To relocate our solution file select the top level node in the solution window (Solution ‘KnowledgeExchangeWeb’) and then go to File(Save As. Browse to the src directory and change the name of the solution file from KnowledgeExchangeWeb to just KnowledgeExchange. Then hit save. Now go into your KnowledgeExchangeWeb project directory and delete the old KnowledgeExchangeWeb.sln file.

    With this complete lets adjust our project’s namespace and assembly default names. I am following the convention of Domain.ProjectName.Topic/Technology/Area. So in my case I will name this code base AndrewSiemer.KnowledgeExchange.Web and AndrewSiemer.KnowledgeExchange.Web.Tests. Do this by selecting the project, right clicking, and properties. Then set the assembly name and namespace for the project to your CompanyName or DomainName .KnowledgeExchange.Web, etc. and then save your changes. Now let’s build our solution!

    Our first check in!

    Now that we have our source control created, a folder structure to support our solution, and our initial solution created we can perform our first check in. The first check in is very important. It will allow us to set some filters on what sort of files we want to check in and what sort of files we don’t want to check in. But first let’s make sure that have all that we need to perform an actual check in.

    When creating a source control repository on CodePlex you are given several options for checking code in and out of the repository. Some of the options that you have are the following:

    • Subversion
    • Visual Studio Team Explorer
    • Teamprise Explorer
    • CodePlex Client

    On the majority of my projects I would use an actual implementation of SubVersion (or VisualSVN for those that don’t want to deal with the details of getting SubVersion up and running) and so I am very comfortable with this platform. This means that I will choose to use the Subversion URL. CodePlex provides you with a listing of ways to get to the repository by selecting the Source Code tab. Then on the right side of the page under Source Control Setup you can click the various clients they support. Clicking on the Subversion like provides you with this information:

    CodePlex will then suggest to you TortoiseSVN which is also what I would suggest that you use. Make sure that you have the latest version of this software as it is updated frequently! You can get TortoiseSVN here.


    I have been asked several times why I always choose to use Subversion and Tortoise instead of one of the many other options out there. My general response to this is that I like how Tortoise integrates with more than just the Visual Studio IDE. I like that Tortoise integrates with Windows Explorer so that I can manage all aspects of my projects rather than just the code related ones. Also, the tight integration between Tortoise, Subversion, and all the other tools that I use in my build processes makes managing automation considerably easier. I have also had a good deal of experience with Subversion, Vault, Source Safe, Perforce, and CMS and find that Subversion is a very stable, flexible, and easy to manage platform in comparison.

    Once you have TortoiseSVN installed navigate to your trunk folder in Windows Explorer. Right click the trunk folder and select SVN Checkout.

    This should then open up the Checkout window. In this window you want to set the URL of repository to the URL that CodePlex provided to you for your project (or to this one if you want to follow along with me: Then make sure that your Checkout directory path is set to the trunk folder of your KnowledgeExchange project. Everything else should look like the following screen shot.

    When you hit OK you will be presented with an alert window! The target folder is not empty. If you are planning on following along with this series creating your own solution in your own CodePlex repository this alert won’t matter! If you are instead planning on following along by getting latest from my KnowledgeExchange repository then you may want to pause and read on!


    If you want to follow along with me then I suggest that you create your own CodePlex project and perform all of the steps in your own environment. If instead you want to just skip ahead and get latest from then you should be aware of what is going to happen! Consider that I am writing articles at a faster rate than the articles can be published. Also, I am writing faster than you are reading. Or you are just now finding this series…a year later. When you get latest you will get whatever the latest code is in real time while reading an article of the past! If you want to following along with each article and you don’t want to maintain your own CodePlex repository then you should download the source code for this article instead of getting latest!

    I am now going to click Yes to my alert window. I am then presented with the Checkout window followed by an authentication window. I will authenticate using my CodePlex account. I then see that my checkout has finished successfully!

    What just happened here? Tortoise just synchronized itself with the CodePlex project and married itself to that repository. For those that are new to TortoiseSVN and Subversion you should now see an icon overlay on your trunk directory.

    With TortoiseSVN associated successfully with our code repository we can now actually check in our code! We do this by right clicking on the trunk folder and selecting SVN Commit. This will bring up a Commit window. The key to the Commit window is that this is where we can add a message to our check in as well as set filters for files that we don’t want to commit. You should always add a comment to your check-ins so that people know why you pushed code but also so that you know why you pushed that code 6 months later! I use the format of my name followed by a list of descriptors bulleted with an asterisk. Then you should review the list of items that are available for check in to ensure that you don’t check in things that shouldn’t be checked in. Items to watch out for are any folders or code generated by your local build process (bin or obj folders, .dll files, etc.). Also, it is not appropriate to check in your personal user settings!

    When you come across files that you don’t want to check in you can add them to the ignore list by selecting them and going to the Add to ignore list option. You can ignore a specific item or all items like that item. Do keep in mind that for some reason you can’t always add items to the ignore list in which case you have to ignore them yourself!

    Once you get all the files selected or filtered as you like you can then hit ok and watch as your files are added to the queue of files to be checked in.

    Once the queue is built and the files are confirmed to be in a state that they can be checked in, the files are then sent to your CodePlex repository.

    If everything worked as planned you should see a commit success along with the revision number. Then you can click ok.

    Publishing our CodePlex project

    Now that we have our initial set of code checked into our CodePlex project we should be able to finish publishing our project and make it public. Navigate to your project and select the Source Code tab. You should now see your new version of code checked in along with your TortoiseSVN comments.

    Now we can click the Publish button on the home page of our project. Once this is done the project can be found in CodePlex searches and more importantly people can download and work with our Knowledge Base project!


    In this article we created a version control repository on CodePlex to support us throughout the remainder of this article series. We then discussed setting up a file and folder structure capable of supporting us in a large project. Next we created our initial solution and related ASP.NET MVC 2 web application. We then got the TortoiseSVN client installed and configured to interact with our version control project on CodePlex. Finally we were able to perform the initial check in of our solution and make our StackOverflow inspired knowledge exchange project public for all to see.

    In the next article we will take our development environment to the next level. First we will create and configure a database for our project to use in our local environment. Then we can create a NAnt based automated build process and a few custom NAnt tasks that will build all of our code, run tests, extract various information from our code, and maintain a fresh database for us. Next we will set up a website on a centralized development server for all to see and interact with. Once our local automated build is running smoothly we will install and configure continuous integration with so that we can run our automated build on our development server each time new code is checked in to our KnowledgeExchange.CodePlex project. By the end of the next article we will have a fresh build deployed to our centralized development environment with each check in to our version control repository.

    <<  Previous Article Continue reading and see our next or previous articles Next Article >>

    About Andrew Siemer

    I am a 33 year old, ex-Army Ranger, father of 6, geeky software engineer that loves to code, teach, and write. In my spare time (ha!) I like playing with my 6 kids, horses, and various other animals.

    This author has published 29 articles on DotNetSlackers. View other articles or the complete profile here.

    Other articles in this category

    Code First Approach using Entity Framework 4.1, Inversion of Control, Unity Framework, Repository and Unit of Work Patterns, and MVC3 Razor View
    A detailed introduction about the code first approach using Entity Framework 4.1, Inversion of Contr...
    Exception Handling and .Net (A practical approach)
    Error Handling has always been crucial for an application in a number of ways. It may affect the exe...
    jQuery Mobile ListView
    In this article, we're going to look at what JQuery Mobile uses to represent lists, and how capable ...
    Book Review: SignalR: Real-time Application Development
    A book review of SignalR by Simone.
    JQuery Mobile Widgets Overview
    An overview of widgets in jQuery Mobile.

    You might also be interested in the following related blog posts

    Missing the Navigate Forward and Navigate Backward commands on your Toolbar read more


    Subject Author Date
    placeholder Great article! Nick Elliott 8/13/2009 4:11 AM
    RE: Great article! Andrew Siemer 8/13/2009 2:08 PM
    placeholder Awesome Job Andrew! Ahmed Al-Halwagy 8/16/2009 7:12 AM
    RE: Awesome Job Andrew! Andrew Siemer 8/16/2009 7:12 PM
    placeholder Keep up the Great Work! Robert Williams 8/16/2009 1:10 PM
    RE: Awesome Job Andrew! Andrew Siemer 8/16/2009 7:12 PM
    placeholder Next? Dave Hanna 8/18/2009 10:42 AM
    RE: Next? Andrew Siemer 8/18/2009 11:33 AM
    placeholder Next article Dave Hanna 8/24/2009 8:49 AM
    RE: Next article Sonu Kapoor 8/24/2009 9:03 AM
    placeholder RE: Next article Sonu Kapoor 8/24/2009 2:13 PM
    RE: RE: Next article Sonu Kapoor 8/24/2009 2:14 PM
    placeholder RE: RE: RE: Next article Dave Hanna 8/24/2009 2:34 PM

    Please login to rate or to leave a comment.