Current Multi-blog enabling LINQ to SQL BlogEngine.NET Provider. (Updated 3/12/10)

I have been asked for this code so that we can share the multi-blog solution that has been working for me for almost a year now.  This is the time to check it out and help make it work for yourself and others.  I’m going to continue to “dog food” this here.  Current version of BlogEngine.NET supported by this provider, as of this post, is  Although I need to update my own site(s) from


How will I update?

Mine is easy.  Drop in the new DLLs.

If I do a code “diff” and find the Web code to have changed recently (which I’m sure it did) I will copy those specific files to the Web folder.


How do you update from a clean BlogEngine.NET code base?
  1. You should download the latest BE.NET code from codeplex and create a folder for the solution. 
  2. Extract the code from the zip into your solution folder. (…and follow the directions for setting up a stand-alone SQL Server Blog)
  3. Copy and unzip the folder into the solution folder with the Core and Web projects.
  4. Add an existing Project to the solution, select the BlogEngine.Linq2Sql project.
  5. Verify the References (to project “BlogEngine.Core”)
  6. Add a reference to “BlogEngine.Linq2SQL” from the “BlogEngine.NET” Web site.
  7. Change Target Framework on BlogEngine.NET Web site to “.NET Framework 3.5
  8. Execute the SQL build script “Linq2SqlUpdate.sql” to add schema to support Multi-Blogs.
    • Make sure to run against the Database you created in Step 2.
  9. Assuming you are using the correct connection string, modify the Web.Config
    • blogProvider, membership, roleManager
    • See: Web.Config.xml

For those who like pictures to verify what you're doing, here are a couple.  I'd rather have an installer but I'm not quite there yet.

Step 3:


Step 4:

Step4a Step4b Step4c

Step 5:


Step 6:

Step6 Step6b

Step 7:


Step 9:

    1: <BlogEngine>
    2: <blogProvider defaultProvider="Linq2SqlBlogProvider">
    3: <providers>
    4: <add name="Linq2SqlBlogProvider" type="BlogEngine.Linq2SQL.Linq2SqlBlogProvider, BlogEngine.Linq2SQL" connectionStringName="BlogEngine"/>
    5: <add name="XmlBlogProvider" type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>
    6: <add name="DbBlogProvider" type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" connectionStringName="BlogEngine"/>
    7: </providers>
    8: </blogProvider>
    9: </BlogEngine>
    12: <membership defaultProvider="LinqMembershipProvider">
    13: <providers>
    14: <clear/>
    15: <add name="LinqMembershipProvider" type="BlogEngine.Linq2SQL.LinqMembershipProvider, BlogEngine.Linq2SQL" passwordFormat="Hashed" connectionStringName="BlogEngine"/>
    16: <add name="XmlMembershipProvider" type="BlogEngine.Core.Providers.XmlMembershipProvider, BlogEngine.Core" description="XML membership provider" passwordFormat="Hashed"/>
    17: <add name="SqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="BlogEngine" applicationName="BlogEngine"/>
    18: <add name="DbMembershipProvider" type="BlogEngine.Core.Providers.DbMembershipProvider, BlogEngine.Core" passwordFormat="Hashed" connectionStringName="BlogEngine"/>
    19: </providers>
    20: </membership>
    21: <roleManager defaultProvider="LinqRoleProvider" enabled="true" cacheRolesInCookie="true" cookieName=".BLOGENGINEROLES">
    22: <providers>
    23: <clear/>
    24: <add name="LinqRoleProvider" type="BlogEngine.Linq2SQL.LinqRoleProvider, BlogEngine.Linq2SQL" connectionStringName="BlogEngine"/>
    25: <add name="XmlRoleProvider" type="BlogEngine.Core.Providers.XmlRoleProvider, BlogEngine.Core" description="XML role provider"/>
    26: <add name="SqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="BlogEngine" applicationName="BlogEngine"/>
    27: <add name="DbRoleProvider" type="BlogEngine.Core.Providers.DbRoleProvider, BlogEngine.Core" connectionStringName="BlogEngine"/>
    28: </providers>
    29: </roleManager>

BlogEngine.NET Core Version is running on this server as of this Post.

ref: (Waiting for a Minor Release of BlogEngine.NET with MultiBlog)


I based my implementation on SqlBlogProvider, but since it was out of synch with BlogEngine.NET I had a dilemma.  My biggest complaint about BlogEngine.NET if I had any at all was the fact that sometimes changes come at a snails pace.  This is not to say that you can’t find a new build there every other day, but that the major enhancements I want don’t always take, or in the case of MultiBlogs, the most popular enhancement to date, is completely ignored.  Once Jacob Proffitt created a solution, I figured it would be rolled into BlogEngine.NET.

OK, so I was Way off on this one. So here’s a strategy:

  • Get the latest BlogEngine.NET code and use it as a baseline. (
  • Get the latest SqlBlogProvider code and ditto. (27978)
  • Make sure to upgrade Everything to .NET 3.5
  • Modify the SQL Database Schema to include Blog and Host tables, and BlogDataStoreSettings
  • and add BlogId columns where necessary.
  • Recreate the DBML for the new schema.
  • remove references to multiblog="true" because they don’t matter anymore.
  • Simplify and verify.

OK, done!!!  Now what?

I have a set of Blogs running an older version of everything and now I have a new schema.  Also, I have new capabilities and only a SQL script to modify or add new blogs.  It is simple but always required modifications before running.

  • Windows Form, new simple DBML for required tables…because the Provider model is too complex,
  • and Done.

Oh, and I needed a migration tool and some more fun with Linq to SQL, so I created a one-off migration tool with a useless UI that could be done from a command line, but I thought I might need more.

And, it’s running now!!!


BlogEngine.NET code is now at version (change set 31351)


Now I have to isolate changes, bug fixes, enhancements I want and implement…but this is the exact scenario I want to avoid.

  • Do I create a Branch that uses most of BlogEngine.NET?
  • Should I start over?

I think the best option is to start a new core based on current or future technology and leave behind what can be upgraded.  Linq, Entity Framework, WCF, Silverlight 4, .NET 4.0 can be used much more.  MVC can become a solid base for the UI, maybe. This is not a hard nut to crack, and get’s easier with time and new technology.  The hardest part about using BlogEngine.NET today is that it takes longer to fix than to build again from scratch.

It’s time for a new architecture.  I’m glad I didn’t create one myself a few years ago when BlogEngine.NET was introduced, but I will be happy when I can safely deploy a new version based on those principles.

Pipedream: Multiple Blogs

I’m not sure if anyone else has noticed but the NUMBER ONE requested feature of BlogEngine.NET (That’s #1 by a landslide) is to support Multiple Blogs per installation.  I have been struggling with this concept and while searching for and designing a workaround using BlogEngine.NET and the Provider model using SQL Server only, I came across SqlBlogProvider that also uses Linq to SQL.  This model supports Multiple Blogs in a single SQL Server Database in a single Application folder.  It now also supports multiple hosts or domains per blog if required.  So the only dilemma I’m struggling with today is where to go from here.


Current Conundrum:Linq2SqlBlogProvider

Now that the SqlBlogProvider supports what I need, although there are a few items I’ve extended I’m still having problems syncing between the “current” or “newest” code base(s) of BlogEngine.NET and the SqlBlogProvider.  They don’t jive, nor should they.  However, I want it all, and I want it now…Yeah, I know it sounds like a song.  The strategy I would have employed was to Add a blog table, and then the host table to support another level of hierarchy, then add a BlogId to each necessary table.  However, in order to create the least possible interference with the Core, the SqlBlogProvider author added separate tables (Junction tables) and a separate Provider project.


I’ve made the changes to the latest BlogEngine source I had from a few days ago ( and SqlBlogProvider (1.5 Change Set 27978) but haven’t finished the work I wanted yet.  My plan is to finish some bug fix work across both projects which may be done as far as my issues are concerned.  Now I’m adding a GUI for setting up new Blogs (via Linq and the new provider I chipped out of SqlBlogProvider).  Then I’ll dog-food it for a while and see where it leads me.  I may learn enough from this to start fresh and rebuild the core in my own way but I’m willing to share the results if someone asks.

You’ll know it’s in use when the BlogEngine.NET version at the bottom of this blog changes from to or above.

This is a thread from BlogEngine.NET on CodePlex. (Multiple blogs on same installation

I would like to see the current dev plan, if it exists yet.  If I knew we/they/you were going to use SqlBlogProvider, and even integrate it into the core, I would like to help.  If there was also a way to allow multiple blogs within a single application, that would be great too.  Should everyone just create a new branch?

If we don't know the future plans, dates, implementation, etc., we're stuck deciding whether to wait or risk going forward with an alternative branch and missing out.  Communication would be good.  I may be missing something.  I've stated recently that I spend more time modifying current BE.NET code than I ever do Blogging and I have over a dozen blogs. is currently stable, from my perspective with SqlBlogProvider supporting all of those blogs on a single folder, with a single SQL database and schema.  The only (minor) issue is still creating multiple Web Applications and pointing them to the same folder.  I can live with that on an 8-way server with 2 GB of RAM.

It’s related to Multiple blogs in one BlogEngine.NET instance and BlogEngine.Net for SQL Server

The concern here is complex, balancing need, want and political correctness.  But it doesn’t need to be this way.  I’m more afraid of pissing-off the folks who have put so much into this project than I am of whether or not I can build a system from scratch so I don’t want to say what I’m thinking.  Hey, if I had the time, or could work with “you folks” I’d want to contribute towards a cleaner architecture, test methods (not that I’m the expert in that), and MVC version, even contribute the Oracle portion of data model and db provider.  But overall, I’d like to see a plan.  I’m most concerned about waiting for people who are deciding on things without customers’ input, frankly because we aren’t customers.  Nobody’s paying for this.  So, you get what you pay for, right?!?!  Not quite.  There’s an incredible value in this product, and for the developer in us, there’s even room for learning by fixing, altering and improving.

The point is, I feel useless in the process and could contribute substantially to the process.  I’d hate to say BlogEngine.NET needs “new” blood, because I think it just needs more time, as in planning and development effort.

If anyone is interested in contributing to this effort, but has been shut out, let me know if you want to go down the branch path together.  I’m not against trying something and dropping it in the future for the right reasons or sticking with it if it adds even incremental value, or for that matter, starting from a completely different approach.

It's already mid-August and I just finished a round of BlogEngine.NET updates to take advantage of the new features in 1.4.5.x.  For a lot of folks, the need to Blog is what makes this platform so valuable.  But my clients, and my own interests also include adding Extensions and Advertising.  Now that there's  a Text box Widget, I can add simple ads like an Amazon link, Google AdSense, and affiliate links right in the Widget Zone without any special code.  Maybe this can be improved to target this medium, but I have to admit, if it works, I'm going to use it as is.  But there are a few things I'd like to see sooner than later.

Multiple Blog Support

What if I had 15 Blogs on different topics and some of them included overlapping authors?  I would like to support this configuration with One code base, One server or service layer, connecting to a Single SQL database or SQL Server farm.  I know I'd want this because I want it now and I have 8 Blogs, with 8 Web Apps, 4 AppPools, and 8 sets of XML Data.

SQL Server Express wouldn't cut it since my server started running into resource issues.  Not because of SQL Server but because I need 8 databases the way this configuration is setup.  Even if I upgrade my server (or hosting platform) to allow for more capacity, it doesn't scale.  Also, I will spend more time maintaining Blogs than writing for them.  So more Blogs = Less Blogging.  That's not a positive goal for me. :(

See BlogEngine.NET on CodePlex: Multiple blogs in one BlogEngine.NET instance
See Also: SQL BlogEngine.NET and Multi-Blogging

I'm following the instructions from "Setting up BlogEngine.NET 1.4 to use SQL Server" so I can review the Provider and see if this seems practical.  I'll have to report back and add on here when complete.

Advertising the manual way

Anyone can now use a BlogEngine.NET 1.4.5 compatible theme and add a Text Box widget to the Widget Zone.  Then you can place and ad within, so long as it fits the box cleanly.  Don't forget colors, borders, iframe constraints., etc.  But this is still very clean compared with the alternative.

Using AdsenseInjector should place an AdSense ad within each blog post. I'm having problems when more than one AdSense block is configured on a page.  I still need to debug my specific issues, but it may stem from the fact that I messed with the Master file in the theme to place AdSense "elegantly" where I wanted it...of course this was just for testing the theory.  So, AdsenseInjector is a good start so I can't knock it.  It's certainly something I thought about but did no think through so now I have the benefit of someone else's labor.  However, I still would like to get it to work along side other Ads on my page.

Hacking various themes to produce Ad Friendly pages or posts may be the only way to get what I need.  Another way of looking at this could be to use the Widget or Webpart approach to building and organizing themes.

This was merely an exercise in describing what one blogger needs, but at the same time, setting in motion my attempts to achieve this and report back my R&D results.