How Did MSD2D integrate ASP.NET Forum With Its Main Site?

How Did MSD2D integrate ASP.NET Forum With Its Main Site?

(Note: For users who have questions about this and/or previous article, please post them in our .Net article forum, where you can find a lot of help: Our authors and other users will post response to your questions.)

Since we launched the NEW MSD2D web site last week, we have received many inquiries about how we integrated statistics from our ASP.NET forum with our main web site. In response to this, we will describe the key technical details so that interested .Net web developers can display similar data from the ASP.NET forum in their own web sites.

We will start with a high level view of the overall ASP.NET forum architecture. The code we got from Microsoft's official ASP.NET web site is divided into two assemblies. Codes in the "Engine" folder compiles into aspnetforum.dll (for logical objects, such as users, forums), and codes in "Aspnetforums\Aspnetforums" folder compiles into starterforum.dll (for UI) by default. These two are just the default names that you can change from your visual studio project property or use command line switches. Here is a figure that roughly shows how the components interact with each other:


There are no design time support for the controls, since the team has been focusing on real value-added features, rather than making it designer friendly. Hopefully it will be so soon.

ASP.NET forum data are stored usually in Microsoft Sql Server, therefore we need to run the Sql script that comes with the forum code. If you want to modify the script to write to an existing database, be careful not to drop any existing tables. For example, there is a "Users" table in ASP.NET forum, there might also be a "Users" table in your own production database. By default, the script will create a new database called "aspnetforums".

Once the data is in place, we can start working on the code. There can be two kinds of configurations. You can either set up the forum to be a separate virtual directory (a new app domain) or simply put the forum codes into a sub folder (simpler alternative). In the former case, you will deal with two separate web.config files, therefore you can simply use almost the default from's original settings, whereas in the latter case, you have only one web.config in the root folder, then you need to copy and paste the right sections from ASP.NET forum's web.config into your existing root web.config. At MSD2D, we opted for the first alternative, although we need to deal with two application domains, the maintenance is much easier due to the fact that there is less code tangling and two databases are separate.

The most knotty issue at integration is how you handle the user information. Usually your existing user table will not have the ASP.NET forum user table fields, such as "YahooId", "MSNId", etc. To make it plug and play, I believe it is better to have two separate tables than inserting the extra fields into your existing user table. That way, it is easier to remove the forum in the future when you do upgrade or no longer need that functionality.

So suppose we have two user tables, then the remaining issue is only setting up a "bridge" or middle layer between your production user table and the ASP.NET forum user table. The critical thing to bear in mind is it should be a one-to-one relationship. ASP.NET forum uses "username" field as the primary key for user table, so your existing user table need to have a primary key that maps to one username in the forum user table. Preferably when the user login on main site, you can have a session object that remembers username and whatever field that is needed to resolve to a corresponding user object in forum, and vice versa. This presumably will take place in the login pages.

When the user log in to forum for the first time, by default, ASP.NET forum will automatically generate a random password in the forum if the user is not a recognized user, and send it to the user's email address. Here we can do our trick to make integration happen. In the login click event handler:

public void LoginButton_Click(Object sender, EventArgs e), you can rewrite the code to use the user's production site password (which is now either in Session["username"] or the user just input it in the textbox) as the forum password, production username as forum username.

After that, things are all easy to manage. For example, if you want to link post's author's user profile back to your existing site's user profile page, then simply modify the UrlUserProfile( ) method in the "Components\Globals.cs" file - one major component singled out in the figure shown above, like what we did at,

static public String UrlUserProfile {
get {
     //return SafeConfigUrl("AspNetForumsSettings", "urlShowUserProfile", string.Empty).Replace("^", "&");
     return "/Content/User_profile_03.aspx?id=";

Notice we commented out the default SafeConfigUrl for all ASP.NET forum hyperlink. All other hyperlinks can be customized through Globals.cs file as well.

To change the look and feel of the forum to suit your own site is also a snap, since the forum uses skin files which can be added and/or modified in the "skins" folder. For example, if you want to override the default skin for post, just modify the "skins/default/Skin-Post.ascs" file to suit your needs. All dynamic data are generated and bound to the skin at runtime using reflection. Just be sure to have the control IDs in the skin files that are needed in the corresponding "Controls\PostView.cs" file, casual changes will not work in modifying the skin file.

ASP.NET forum is a great showcase for best practice in ASP.NET programming. If you have a good architectural view of the model behind it, you will find customizing it is easier than you expect.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.