Developer Guide

Microsoft Forums Moderators Toolset

Created By: Joe Morel
Date: August 14, 2006

Introduction

Welcome aboard to the Microsoft Forums Moderators Toolset project! The goal of this project is to create an effective and useful toolset for our forums moderators. We are planning on developing this project 100% transparently and collaboratively, and so to do, we have a few basic guidelines around development that everybody needs to follow.

As with everything in this project, this document is available to edit, and you should feel free adding or changing something as you see fit--just let the rest of us know that you did (use the Discussions tab!)

Necessary Tools for Development

You will need a few tools for development installed. While developing, it's important to keep in mind that we do not want to make other developers to go out and buy new software to be able to contribute, so please keep the following tool requirements in mind before you add a dependency to the project.
  1. IDE: To develop this project, you will need, at a minimum, Visual C# 2005 Express Edition Other versions of Visual Studio 2005 will work as well, but any extra components included in them are not requirements for contributing to the project, and should not be added as dependencies to the project.
  2. Source Control: We are using the Team Foundation Server-based source control that is available through CodePlex. To connect to the server, you will need Team Explorer installed (freely downloadable here:)
  3. Testing: We will be using NUnit for all unit tests that we write for the toolset. NUnit can be downloaded at http://www.nunit.org
  4. Code Analysis: We will be using the freely downloadable version of FxCop for all code analysis.
  5. Installer Technology: For an installer, we will be using the Windows Installer Framework (WiX), which is available at: http://sourceforge.net/projects/wix/

Making Changes to the Source Code

To prevent us from all making random changes to the source code which may or may not be beneficial for the rest of the community, we should follow the following workflow for contributing changes to the source base:
  1. Create/Find a Work Item: Using the issue tracker, you should create a work item for what you are trying to add or fix in the project. What's bothering you? What needs added? What needs fixed? If you are planning on making the changes soon, go ahead and assign the work item to yourself. Work items are the basic unit of "stuff to do" on this project. By taking a work item, you are committing to the rest of the community that you will do your best to fix the issue. If you find that it's too difficult, or you simply don't want to do the work item anymore, just unassign yourself from the work item, so somebody else might be able to take it on.
  2. Use Team Explorer to Check Out the Source: By using Team Explorer to check out the source code, you'll automatically be letting everyone else know that you are modifying the source. If you aren't going to make any changes, make sure you check the code back in, discarding the changes.
  3. Comment, Comment, Comment! With many people working on the same source, make sure you comment your code well--we all want to understand what you did!
  4. Make a Shelveset: Using Team Explorer, you can create a shelveset and associate work items with that shelveset. Go ahead and be descriptive with your description of your shelveset. What are you changing? Why? Did you have any workarounds you had to use? To learn more about shelvesets, check out this article on MSDN: http://msdn2.microsoft.com/en-us/library/ms181403.aspx
  5. Get a Code Review: It's important to get your code reviewed before you check it in. Getting a fresh pair of eyes looking at your code is beneficial--it's a great way to make sure that your code both works and is something that's on the right track. For our project, you need to obtain sign-off from at least one other person before checking in your code. Ask for the code review in the Discussions area, and be sure to identify your shelveset name and the general changes that you made to the code.
  6. Check In Your Code: Now that you've gotten validation for your changes, you're ready to actually check your changes in. When you perform a check-in, make sure that you write a brief description on what you changed, and associate the work items that you resolved with that check-in.

The minimum unit of work for a check-in ideally is at least one work item being resolved, although exceptions can occur on a case-by-case basis.

Developing on our SQL Server

The Developer Solutions team at Microsoft has obtained web and SQL hosting for this project. Although all server-side calls should be mapped to web services whenever possible, a limited set of developers will be given access directly to the SQL server and web server. Changes to the actual database should be kept to a minimum. If you need the password and information to access the hosting area, please directly email Joe at joemorel AT microsoft DOT com.

Last edited Aug 15, 2006 at 5:55 PM by joemorel, version 3

Comments

No comments yet.