DotNetNuke vs. SharePoint, the big showdown

I’ve been meaning to do this blog for awhile and it’s a long one so better get a fruit flavored drink of your choice and curl up on the couch with your laptop for this one. Sorry, I do apologize for the rambling (and length) as this post has now encompassed a couple of hours of my time and I’ve been bouncing up and down the text like Tigger on crack. Caveat lector.


One thing I want to stress as I go through this posting. I’ll use the term SharePoint throughout this post but it really will refer to both SPS and WSS capabilities. I’ll also use WSS and SPS where I talk about specific features so just keep that in mind as you fall asleep halfway through. Also note that most of this article discusses the current version of DotNetNuke (3.2.2 and 4.x) and SharePoint (SPS 2003 and WSS 2.0) but there’s mention of the v-Next flavors of SharePoint that will be coming with Office 12. I mention these because in some cases, they do level the playing field and create almost exact setups from what DotNetNuke has (for example with membership providers). So it’s a little hard to draw the comparisons without talking about it, but I’ll leave it as an exercise to the reader to draw your own conclusions given all data points. Hopefully it won’t be too confusing.


Microsoft introduced ASP.NET and people saw the potential, but they’re not completely sure about how to leverage it. Do we just rebuild our “classic” ASP apps using this new tool. What can we really do with it? Up until this point, anyone building a “portal” application would have done it manually. You all have done it because I’ve seen it time and time again. Corporate intranets built from ASP or even ASP.NET from the grass roots. I’ve even seen “web part” like implementations long before there were these funny doofers that people could drag and drop on web pages interactively.

Enter DotNetNuke. The amazing ASP.NET portal that spewed forth from IBuySpy. Okay, a super brief history lesson. Microsoft puts together a “portal” application to show off ASP.NET and it’s called IBuySpy, a fictional shop for purchasing spy type products (x-ray glasses, hidden microphones, that sort of thing). This app has a few key features showing off ASP.NET like being able to dynamically add “modules” to pages creating content, hide visibility based on membership, and provide simple site navigation (without having to manually edit pages to do any of this). IBuySpy is a starter kit and lets people build off it to create their own storefronts and portals. Life is good.

December 2002 rolls along and Shawn Walker forks the code, creating a VB.NET implementation with a few enhancements, and dubs it the IBuySpyWorkshop. The development community starts to froth at the mouth (as we often do with cool things) and thousands of downloads ensue (think Slashdot effect). It’s an immediate success and eventually evolves into it’s own product which is then renamed to DotNetNuke (this is a brief history, for a more concise one check out the DotNetNuke page or Shawn’s book). Since then, a few other forks have appeared all based off the IBuySpy codebase including Rainbow, etc. and I’m sure there are others. In any case, it’s a big hit and has some great features. Both DNN and SharePoint have a vast number of features where they align, and some other areas where they don’t. Let’s take a look at some of the differences and similarities and what makes each stand out.

Modules vs. Web Parts

A rose by any other name would be the same. Okay, so that’s not the quote but it works for me. DotNetNuke calls them Modules, SharePoint calls them Web Parts. They’re essentially the same thing. A .NET assembly (or assemblies) that makes up the logic and presentation for a function that can be placed anywhere on your portal.

A SharePoint Web Part, just like a DNN Module, is a component that can be used in a site. In DNN you add them to pages, in SharePoint you add them to Web Part pages. Same concept as they offer positioning, personalization, minimize capabilities, etc. DNN has a few extra baked in features that a SharePoint Web Part could use like RSS feeds, custom containers, and a print capability. Again, in vNext RSS is built into the entire system so your SharePoint Web Parts will now be subscribable, much like DNNs modules today.

The big advantage that SharePoint has over DNN is that DNN modules can only be used in DNN. SharePoint Web Parts can be used in other systems that use Windows SharePoint Services as a foundation (Small Business Server, Project Server, etc.). While you can’t use all Web Parts everywhere, if it works in WSS it will probably work in SBS. This feature actually becomes even more of an asset with vNext as ASP.NET Web Parts can be used in both ASP.NET apps as well as SharePoint sites so you’ll be able to say expose a data source in a business application and (depending on the codebase of course) drop it onto a SharePoint page without hassle. Again remember that this is all very dependent on how you build your Web Parts but I don’t see DNN modules being used anywhere but DNN, even with Version 4.x that is built on ASP.NET 2.0.

Having played my SharePoint Web Part card, I have to say that adding modules to DNN is a snap with it’s Private Assembly (PA) approach. Basically you package up the Module a certain way and a Host can upload it and make it available to any or all portals running under it. This is all done at runtime without the system going offline (which includes adding new tables to the database, etc.). This is great although I’m sure you could exploit this with a rogue module. Compare this to the fairly daunting task of a) adding an assembly to the bin directory or GAC b) adding the SafeControl entry to the web.config file and c) potentially doing an IISRESET or recycling the Application Pool. Now if someone were to build a “Upload Web Part Web Part” that would be something (hint, hint).

I won’t talk about developing Modules vs. Web Parts as I get into it below but it’s all very similar from a conceptual point of view (ASP.NET, User/Server Control, yada, yada, yada)

Core Modules

DotNetNuke provides about 25 core modules. These are available out of the box and ready to put onto any page by an end-user. The later releases (3.x and up) came with templates and a wizard to walk you through applying a set of pages and skins to your site immediately. This is very similar to a site or area template in SharePoint. SharePoint provides a stock number of list and document library templates along with a set of instances of these (based on the site template you select).

You might say DNN has more modules than SharePoint does but if you look at the DNN modules most can be achieved with a custom list and perhaps some custom views tossed in for good measure:

Feature DotNetNuke SharePoint Notes
Announcements Built-in Built-in Very similar but DNN offers the ability to add the date display to each announcement. Could be done with a DataView Web Part in SharePoint
Banners Built-in N/A Could be achieved with CEWP but not native. Could not accomplish banner rotation without either Java Script or custom Web Part
Contacts Built-in Built-in SharePoint wins out on this as it provides many more fields and can link to Outlook.
Discussion Built-in Built-in Both are very similar. Flat and practically useless for threaded discussions. DNN has a new core Forum module which is more like what traditional forums should be.
Documents Built-in Built-in Similar but SharePoint provides Office integration, versioning, and check in/out features that DNN doesn’t have.
Events Built-in Built-in Very similar as both offer list and calendar views, reoccuring events, expiration, etc. SharePoint provides Outlook integration with the ability to create a meeting workspace for an event.
FAQs Built-in N/A Could be done as a custom list but would need a DataView Web Part with Java Script or grouped views to do expand/collapse features that DNN has.
Feedback Built-in N/A Could be done with CEWP, Form Web Part, or a custom list but no email integration like DNN has.
IFrame Built-in Built-in PageViewer in SharePoint. CEWP can also link to content via a URL.
Image Built-in Built-in Pretty much exactly the same.
Links Built-in Built-in DNN has more flexibility around ordering and presentation of links but could accomplish similar things with SharePoint with some customization (not coding)
Newsfeeds Built-in N/A Requires third party web part but can be accomplished with Xml Web Part and XSLT file.
User Account Built-in Built-in Different access and presentation between SPS and WSS but similar to user account. Since SharePoint is using values from Active Directory rather than a custom list or database, not as much editing capability as DNN has.
Text/HTML Built-in Built-in CEWP in SharePoint. Pretty much exactly the same as DNN.
Members Built-in Built-in DNN has more features like last member logged in, current users, etc. SharePoint is generally just a list of who’s a member of the site.


It’s not an exact match, but it’s close and I would say each has advantages and disadvantages. An adventurous soul (not me, I have way too many projects on the go) might put together a custom SharePoint site template complete with the custom lists that DotNetNuke offer in a default DNN setup. There’s really no magic here although there some core DNN modules that you don’t need or have with SharePoint (like a login module). For the others, a custom list would pretty much give you similar functionality.

Putting on my DNN hat, I could say that you could add custom modules and perhaps tweak the codebase of DNN a bit to provide similar (but not 100%) funcationality of DNN that SharePoint has. After all, some of the Office 2003 integration is just done through ActiveX controls so nobody says it’s a “SharePoint” thing (for example, I’ve used the Address Book feature on a standard ASP.NET app before).

The only true gem that stands out here is the Office integration that SharePoint provides today and that may be compelling enough if you’re a MS shop and deal a lot with Office documents and Outlook contacts. You would probably have to go a long way with modifications to DNN to provide integration to Word (if that would be possible at all) and enable Word to check in a document to DNN (not saying it’s impossible, but certainly not a simple task).


This is the primary feature in SharePoint that is missing today. In SPS we have Audience targeting and some security features to hide areas, but more often than not (and especially in WSS sites) the user sees more than he should. This is called Security Trimming, only show the end user what he can do and don’t let him get 5 steps into a Wizard only to tell him he doesn’t have access to complete the process (man does that bug the crap out of me).

Anyways, in DNN we have the ability to target modules to roles or inherit the pages security settings (which can also be targeted to roles). There is no individual user targeting here, so you have to define a role and assign that role to a user for him/her to see (or not see) a page or module. It works quite well and is vastly used on systems where clubs present information to members only, but the general public gets a different view until they register or otherwise are granted access.

Security trimming is there in SharePoint vNext (finally!) so again, the playing field is level.

Custom Look and Feel

This is a tough one but I have to give it to DotNetNuke as the winner (for now, see note below).

DNN uses something called Skins, very similar to Themes in WSS or using custom CSS files in SPS. However DNN Skins go one step further and let you design the layout of the page, including pulling in modules and controls (like the current date/time and a login control that shows who the user is or a logout button if they’re already recognized). Building a Skin for DNN is pretty basic and can take anywhere from a few minutes to a few hours (depending on how complex you create it). The great thing with DNN is that it uses the skin for every page in the system (primarily because the architecture of DNN runs off a single page). In any case, you don’t get the level of granularity in Themes vs Skins and frankly it’s easier to create a fully customized Skin in DNN (I built the WSS Skin for my personal site in about an hour).

Of course, we have to talk about SharePoint vNext as it fully utilizes ASP.NETs Master Pages so basically once that hits the streets, all bets are off. Apply a master page and instantly, Bob’s your uncle.


You really can’t compare the two products on this level as SharePoint scales out to gargantuan sizes (Microsoft itself runs SharePoint for internal teams and has something like 250,000 team sites worldwide). Yeah, DNN is for hobbyists and in some cases can be used for corporate intranets, but I would want to try to scale it out to run the likes of IBM, Boeing, or NASA. A small corporation with a few hundred users, why not?

However as far as hardware goes, you can really only scale DNN out to 1 web server and 1 SQL server. There’s really no features like Enterprise Search, Single Sign-on, or separate indexing like SharePoint has so that’s the limit from an architecture point of view on DNN.

DNN provides many of the infrastructure items that ASP.NET has. For example logging. DNN provides a mechanism handling vendor ads and ways for them to pay for it. DNN also provides mechanisms to handle subscriptions so that users can access premium areas of the sites. You have to build these items for yourself in ASP 2.0 (again, it’s not difficult to build this, but does require “work”).

The best part about DNN is that a normal user can actually use it to add/edit/delete content out of the box. You can give them a demo and turn the mundane tasks over to them. You can accomplish this with SharePoint as well but for some reason a lot of people seem to scratch their heads at SharePoint. Maybe I’m just dealing with the wrong people.


You would probably agree that the DotNetNuke community might be bigger than the SharePoint one (or perhaps more/less mature). Maybe this is true as there are literally thousands of DNN sites out there running eCommerce sites, club sites, and personal home pages compared to probably hundreds of SharePoint sites. This might be a result of free vs. $$$ for extranet licensing along with some other factors. I would say finding SharePoint vs. DNN content is about a wash at this point.

As far as Modules and Web Part availability go, this is a pain point for me. SharePoint has it’s fair share of commercial vendors. Guys like ADVIS, OmniSys, CorasWorks, etc. are founded on building extensions on top of SharePoint. As for DNN vendors, there are a few with most of the modules coming from SnowCovered (a reseller) however most that I’ve found are poorly documented or just hacks that someone has put together to make a few bucks (yes, I’ve purchased modules from them just to test these waters but I’m not saying all vendors are like that). That’s the problem I have with DNN modules. There’s a ton of them out there, but they all seem to do very similar things and some are completely unnecessary. For example there’s a Google AdSense module. However with AdSense, you get the HTML code you need for it so you can just slap it into Text module in DNN or a CEWP in SharePoint. I find most DNN modules don’t really add much value or function, but on the flipside they’re usually pretty inexpensive. On the other end of the spectrum, SharePoint Web Parts generally go the distance with replacing built-in functionality (like Ontolica’s Search) and really increasing the functionality of your portal, but this comes at a hefty price usually pushing up into the hundreds if not thousands of dollars.

Maybe what bugs me more is the fact that I have to register on every freakin’ DNN site out there to get a demo of some module (or a free download). Believe me, I have hundreds of DNN sites that I’ve registered on just to see what they have to offer. Maybe I can’t blame the product for that as people can choose to leave their modules open for download without having to register, but then they lose the tracking feature.

This might be a sign of things to come should there be an influx of WSS v3 sites and user registrations with the new ASP.NET 2.0 providers so we’ll see where that goes. Come back in a year or so and let’s see how many SharePoint sites you’re registered on.

The other pain point is Skins and Themes. I’ve stumbled across maybe a dozen or so free Skins for DotNetNuke (with only a handful of them being any good) but there are some vendors/individuals who offer up custom Skins for a price. The SharePoint fence isn’t much better with probably the custom Themes Shane put together a few months ago being the best offering I’ve seen in a long time. So why don’t we have a repository of SharePoint Themes (well, WSS Themes technically) that are as plentiful as these Web Template sites that I get spammed about wanting to sell me thousands of site templates for a few dollars. That’s just not right.


The question of ASP.NET 2.0 might come up in discussion as we compare these two creatures. In 2.0 I can drop a DataGrid on a page, bind it to a business class with my ObjectDataSource using Generics, have it fire on select, update, and delete methods and write a little code to make it work (and by little, I really do mean little). Toss in master pages, web parts, and themes and I have pretty much what both DNN and SharePoint have to offer. So why would I use either?

In some cases, it makes sense to build something but think about what SharePoint gives you. I can create a list without having to have discussions with my DBA and model my system. I can have grouped views of the information and publish it in varies ways. I can even consume those services and present them a completely different way (say as a lookup field in an InfoPath form). In other words, I can do a lot of the heavy lifting that I would have to do in ASP.NET 2.0 but without having to do it, if you get my meaning. Same as DNN (except substitute “Modules” for “Web Parts”).

There are compromises here as a SharePoint list or a DNN custom module doesn’t have robust referential integrity nor can it easily talk to my legacy application and make calls to an SAP API without having to write all that stuff. Those compromises are what software development is about. Buy vs. Build and all that. If I already have something that can come pretty close to what I need, why build it. If I can extend what I have (like write a Module or Web Part to talk to my legacy system) then all the better.

So rather than starting with a completely blank page using ASP.NET 2.0, you can start with a blank site or portal then extend it to meet your business needs. Its the foundation that these frameworks already provide that will enable you to hit the ground running. Who really wants to code a “Feedback” page or “Members” module/web part when you can simply add one dynamically. Grant you, some people will say that they can just download someone’s User Control and drop it in, but then are you now just not getting back into building your own Portal? In the end you’ll find that to be a much easier model to sell in terms of productivity to leverage what you can get for free (although there is a steep learning curve with anything and SharePoint or DNN is no exception).


Which is a good transition into development. Both DotNetNuke and SharePoint are .NET based so both use Visual Studio as an IDE to build from and the framework to build on. As much as we all bitch and complain about how hard it is to create SharePoint Web Parts, personally I find DotNetNuke that much more complex. Take this Code Project article for example. It’s entitled Creating a DotNetNuke Module – For Absolute Beginners! The article is MAMMOTH and contains about 30 steps just what seems like a simple Guestbook module together. Wow. What a faceslap to the “simplicity” that DotNetNuke is supposed to be about. From a user perspective it’s good, but from the development side of the fence it’s madness.

One users experience was documented here on installing and setting up his environment. Grant you, he mentioned that he didn’t completely read the instructions and if you do follow the 35 page manual that Shawn has put together it (mostly) works. The thing is that this is 34 pages too long. When you actually have an template in VS2005 to create a module for you, why is it still so freakin’ complicated to get it up and running? To be fair SharePoint has it’s issues but they’re generally more specific like Code Access Security but to get a Hello World Web Part put together for SharePoint takes about a page (and that’s writing it up for Dummies to follow IMHO).

I mean, yes, we as SharePoint developers scream about how difficult impersonation is and how some APIs don’t work right or are not documented correctly. Yes, it’s an ugly world we live in and sometimes a PITA but nothing compared to the steps in this article. And this isn’t the only article or approach. I’ve gone through the official document and module creation and the Code Project article isn’t over complicating things. It really is that immense. For a SharePoint guestbook you could just create a list, modify the fields and if you really, really, really wanted write a Web Part of all about 50 lines of code to present the guestbook (you could probably just slap together a DataView Web Part in FrontPage with no code and call it a day, but let’s compare apples to apples here). Feel free to challenge me on this, but as far as developing DNN Modules vs. SharePoint Web Parts goes, even writing out HTML in code is better than the hoops you have to jump with DNN.

I can hear the OSS zealots out there now. Oh but DNN is Open Source (=good) and SharePoint is Microsoft Closed Source (=evil). Personally I think this is a non-issue. If you seriously are looking to sell someone don’t try to pitch them on the fact that you can crack open DNN and start making modifications whereas you can’t with SharePoint. Trust me, it’ll take more time to “add” a feature to the DNN codebase than its worth. There’s also the discussion around learning from DNN but I’m not very happy with how the codebase has evolved and frankly from some peoples experiences (and mine) just from building the codebase or trying to build a module for it, it seems to be a result of over-engineering and many extra unnecessary layers. It’s not to say SharePoint isn’t similar but SharePoints implementation of tables inside tables inside tables are presentation problem, not architectural issues.

If you really want to learn from something like this, get Visual Studio Express and install the Personal Web Site Starter Kit or something. Less code, similar functionality.

Bottom Line

DotNetNuke has it’s place. SharePoint has it’s place. Both are great at what they do and they seem to overlap in some areas, while completely living in their own space in others.

Currently. If you want an externally facing website where you want the standard message boards, blog, calendar, feedback, and files (and users can optionally register online), then I would say DNN is for you. CommunityServer has some of these and the latest beta looks like it’s approaching something usable like that as well however I haven’t seen a lot of add-ons for CS (or the add-ons were bastardized patches, much like how there are add-ons for phpBB to turn it into something other than a forum). The CS community isn’t as expansive as the DNN one is either as it hasn’t been around as long. You could probably do well with either if you’re looking for a simple community site for say a club or something but DNN does feature more modules (at a cost as you can see above) and more extensibility than CS does so if you’re planning to go beyond the OOTB experience, you might be better off with DNN.

As for DNN vs SharePoint, it’s a toss up. There are both pros and cons to each. In the current incantation, you need Active Directory behind SharePoint but that changes with the next version so you can go to a more “register and login” model like DNN has.

I think the Private Assembly feature of DNN is killer in that I can download/write/purchase a module and have it on my site in minutes without asking an IT guy to reset IIS or modify a web.config file for me. That alone sets DNN apart from SharePoint right now. Again, however, the feature system of SharePoint is going to allow this kind of approach but I don’t see it getting as simple as DNN is today.

Like anything, choose the right tool for the right job. Obviously DNN isn’t as scalable as SharePoint is and it can’t search file shares, web sites, Lotus Notes databases, etc. but then it also can’t be setup and running on an external web host where you don’t have console access in 10 minutes like DNN can.

Choose, but choose wisely.

Also be sure to check out Richard Dudleys post on DotNetNuke and SharePoint here as he puts together a good summary. His place is generally DNN for extranet, SharePoint for intranet. I would agree for the most part and it’s a good rule of thumb to follow if you’re into that sort of approach.

Update: Come to think of it and reading over Richard’s blog post again he really does touch on the main points I listed here (cost, Office integration, authentication, skinning, etc.). He just does it in a much more compressed and easy-to-consume-in-one-sitting read. Kudos to Richard.

OOTB: Out of the Box
CEWP: Content Editor Web Part

About eagle081183

Passionate, Loyal
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to DotNetNuke vs. SharePoint, the big showdown

  1. Full Report says:

    Magnificent web site. A lot of helpful info here. I am sending it to a few pals ans additionally sharing in delicious.
    And certainly, thank you in your sweat! Check out my website to get more info
    about car insurance in California, if you like.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s