- 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.
- VisualHg: Mercurial 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.
Enter the url https://hg01.codeplex.com/nearforums 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 http://hginit.com/ and on http://mercurial.selenic.com/guide/.
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