Converted BlogEngine.NET to ASP.NET WebApp

Topics: ASP.NET 2.0
May 11, 2010 at 9:15 PM
Edited May 11, 2010 at 9:17 PM

First, thanks for a great opensource project. After spending some good quality time deep inside the code I can safely say that this is a very impressive piece of work and my hat goes off to the developer!

However, running as a Website project (as opposed to Visual Studio Web Application) doesn't fit in well with our corporate development environment. We prefer to run ASP.NET projects as Web applications for the following reasons:

1. Easier control of generated assembly name (at cost of dynamic compilation--but isn't that what SharePoint hosted controls using SmartPart do perfectly well anyway?). In our case, this was a real killer as we have built our own extended configuration layer that looks for and loads configuration files based on the executing assembly name. However, where the assembly name is non-deterministic (as it always is for Website projects) this approach loses.

2. Ability to publish the Web site underneath a virtual directory rather than consuming an entire Web site. In our environment, it's quite common for developers to have multiple Web projects pulled down and all running simultaneously. We encode each Web app to run as a unique virtual directory under a non-standard port (such as 7280) that we create once per developer box. Consider that requirement compared to how Website projects work; they are generally published to an entire Web site (they consume the root of the site).

3. Unable to sign Website projects (think about it--dynamic compilation precludes signing in any case).

In our case, we have the blog engine customized to match our corporate Web site, We store the blog engine source code as a dependency within our overall solution, and we have our project settings configured to automatically create and run the blog engine as a virtual directory underneath our top-level Web site. Only by using a Web application could we get this level of flexibility, which makes building up-to-date deployment images much more convenient for us.

The whole process of converting the blog engine to be a Web application took just a few hours, we have the blog site up and running now (with AD integration). The only real bug we ran into was in admin/Pages/Users.aspx. The code:

<asp:TemplateField HeaderText="<%$ Resources:labels, email %>">
                  <ItemTemplate>
                    <%# Server.HtmlEncode(Eval("email").ToString()) %>
                  </ItemTemplate>
                  <EditItemTemplate>
                    <asp:TextBox runat="server" ID="txtEmail" Text='<%# Eval("email") %>' />
                  </EditItemTemplate>
                </asp:TemplateField>

loses when the user email is NULL on the provider (in our case, Active Directory). We replaced this code with:

<asp:TemplateField HeaderText="<%$ Resources:labels, email %>">
                  <ItemTemplate>
                    <%# Server.HtmlEncode(SafeEmail(Eval("email")).ToString()) %>
                  </ItemTemplate>
                  <EditItemTemplate>
                    <asp:TextBox runat="server" ID="txtEmail" Text='<%# Eval("email") %>' />
                  </EditItemTemplate>
                </asp:TemplateField>

Note the call to SafeEmail which is defined in the (*new* based on our work) code-behind as follows:

    /// <summary>
    /// We *can* have NULL emails on AD
    /// </summary>
    /// <param name="email">The email to check (retrieved from provider during data bind)</param>
    /// <returns>Either the actual email or [null] (could be driven by labels for locale support)</returns>
    protected string SafeEmail(object email)
    {
      string safeEmail = null;
      if (email != null) safeEmail = email.ToString();
      if (string.IsNullOrEmpty(safeEmail)) return "[null]";
      return safeEmail;
    } //SafeEmail

Also, we modified Global.asax to use only the code-behind for code (which loses some flexibility but adds a bit more code security).

While a more rigorous upgrade would add comments and disallow all warnings, redoing the entire BlogEngine project in an afternoon is enough for one day. We're happy to share the code if any other would find running the blog engine as a true Web application rather than a Website as useful as we do.

Thanks again for a great project and we hope that other will find the blog engine as Web application useful. Would be great if we could get this committed to the source tree; we're happy to submit it at any time (there's no upload link on this entry form so we can't do it here).

 

Coordinator
May 12, 2010 at 4:31 AM
franklinyah wrote:

While a more rigorous upgrade would add comments and disallow all warnings, redoing the entire BlogEngine project in an afternoon is enough for one day. We're happy to share the code if any other would find running the blog engine as a true Web application rather than a Website as useful as we do.

Thanks again for a great project and we hope that other will find the blog engine as Web application useful. Would be great if we could get this committed to the source tree; we're happy to submit it at any time (there's no upload link on this entry form so we can't do it here).

 

This is great, we not going to convert to web application for variety of reasons but what would be really helpful if you provide feedback on any gotchas you run into and any ideas on how to make projects more compatible so for those who need web application it would be really easy to change just few things and get it up and running. We could document this process on the Wiki page.

May 12, 2010 at 10:26 AM

My concern is that as the blog engine grows we won't be able to keep up with the new features. WRT to a cookbook on how to convert to Web application, I believe the conversion to be a one-way function so choosing to go that route precludes going back. If I have time I will put one together this morning; we're a very small shop and even spending an afternoon on the project was a cost. Because the project is opensource and I purposefully did not change any of the supporting code, is it possible for us to post the source tree on this codeplex project under a separate namespace? I arbitrarily selected BlogEngine.Main as the namespace for the blog engine itself.

The quick steps (to jog my memory):

1. Create empty solution, add existing BlogEngine.Core project as existing project.

2. Create empty Web application, add BlogEngine.Core project as reference. Also set project settings as necessary (screen shots...)

3. Pull in default.aspx / .cs from the blogengine project. Modify the markup to

4. Try to convert default.aspx to Web application (right-click option from Solution Explorer). This fails, resolve by pulling in source files

5. Try to run (just default.aspx). This will fail, but much of the code (thankfuilly) throws exceptions when various required folders (especially App_Data folders) are not in existence. Create these folders, take a bit of time to look at each one; some of the folders and XML files are required (such as the first meta-post describing how to post) but if you are using XML storage then an existing blog engine install will contain a lot of created XML files that should *not* be stored in source control. This is the long pole in the tent (getting default.aspx to compile and run from F5 command in Visual Studio). Once you get that working, then you notice that the ASPX page in the browser is not correct (not showing styles); that's when you hop over to web.config and modify based on the existing web.config from the original blog engine. It's very cool that resources are handled as compressed files via ASX handlers and I'll be looking more closely at that code. At some magic point you get default.aspx to show up with stylings and all required images (such as the RSS feed). This took me about two and a half hours.

6. Repeat process for each page on the default site menu (login, etc.) The process is: pull in source file, modify namespace on markup and code-behind, convert to Web application, try to compile. This part starts to go really fast, at the end you have all the source files pulled in and every single one is running with the required three files (.aspx, .cs, and .designer.cs). This ended up taking about two hours.

7. Implement your authentication last; it's normally web.config related in any case (although we use the handy Active Director provider that is available from the blog engine project).