This project is read-only.

Development instructions

Developer Tools

  • Visual Studio 2010: Integrated Development Environment.
  • ASP.NET MVC 3: Visual Studio templates and required dlls to run.
  • SQL Server 2005 or above: Database server and GUI tools for managing the development database. Express edition is free.
  • TortoiseHg: Mercurial revision control client that integrated into Windows Explorer.
  • VisualHgMercurial revision control client that integrated into Visual Studio.
  • MySQL 5 or above: Optional. Only required to deliver/test releases.

You can choose any other tools than the ones proposed above, but it would be hard to receive support for other tools inside the Nearforums Team.

Get the source code

To get your working copy of the source code, you should create a local clone of the repository.

First, create a new folder on your local machine where you want to download (or clone) the repository. Next, use TortoiseHg to clone the repository in the newly created folder, as shown in the illustration below.

Clone Command 

Enter the url as Source Path and click OK. You can continue reading a small guide on how to use TortoiseHg on Codeplex or you can also read the official TortoiseHG documentation.

Additional Mercurial references can be found on and on


Coding style conventions

For coding style conventions, we use the Microsoft All-In-One Code Framework Guideline (.NET coding standards).

Creating data-access classes

The data-access layer uses .NET DbProviderFactory to work on any database server technology. It should work on SQL Server 2000 (or above), MySQL 5 (or above), Oracle 9i (or above), ...

Writing unit tests

Writing test cases is helpful because it forces one to define the task precisely in advance, and also it speedily reveals the bugs in one's first try (and second, and third...). Also, unit tests are very helpful for future mantainance and refactoring. That said, we do not have a rigid policy about this, not for now. We must do the unit testing on the top level layer (ie: Controllers) in order to test all the functionality.

.NET and Mono

Nearforums tries to stay portable between .NET and Mono by using C# that compiles to IL that can by executed on both .NET and Mono Runtime.


All database development is done in the SQL Server database. We use DbUp for mantaining and updating the development db.

Setup your local development database

To setup your local development database, run DbUpConsole.exe console application located in the db folder. It will execute all sql scripts located in the folder db/scripts.

Updating your development database

If a new sql script has been added to the folder db/scripts in the repository, execute the DbUpConsole.exe, and it will update your local db by executing only the new sql scripts.

Commiting database changes

After doing changes on your local db, script your changes into a file and put it inside the folder script with the name mssql.NNNN.comment-about-script.sql where NNNN is the 4 digit number that identifies the script. The number must be greater than the identifier of the latest script. If your script contains create statements you must include IF EXISTS / DROP clause.

Run DbUpConsole.exe, if the result is success, add the files and commit the changes to the repository.

ASP.NET Membership database

If you want to use a Membership database in your development environment with forms authentication, the web.config already has it enabled. All you have to do is run the aspnet_regsql.exe wizard to configure and install the Membership database on your MSSQL environment. The tool can be found on: %windir%\Microsoft.NET\Framework\<versionNumber>\aspnet_regsql.exe  

Where <versionNumber> is the .NET Framework you are using, which should be 4.0.

Porting to MySql server

All the database changes must be ported to MySql before releasing. This should be done by the person in charge of the release.


The nearforums team prefers that active development happen in the default branch. Changes made to default branch have the highest visibility and get the greatest amount of exercise that can be expected from unreleased code. For this to be beneficial to everyone, though, our default branch is expected at all times to be stable. It should build. It should work. It might not be release-ready, but it should certainly be test-suite ready.

We also strongly prefer to see large changes broken up into several, smaller, logical commits — each of which is expected to meet the aforementioned requirements of stability.

That said, we understand that it can be nearly impossible to apply all these policies to particularly large changes (new features, sweeping code reorganizations, etc.). It is in those situations that you might consider using a custom branch dedicated to your development task. 


Once the features to include in a certain version release have been decided by the team, a person from the team should be in charge of doing the release. For more information see Releasing.

Last edited Mar 16, 2011 at 12:09 PM by jorgebg, version 27


jasonco Feb 19, 2011 at 3:06 AM 
Ur most welcome!

AmyIee Feb 17, 2011 at 5:48 PM 
Thanks for the thorough explanation :)