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


  • Vicenc,

    Thanks for the information. It's good to hear that progress is being made on the development front. I just know (and from reading the linked articles) that it's not a trivial thing to build a new module. I've also had problems just even compiling DNN (latest version, clean install, etc.) let alone trying to build a new module using the wizards and compiling it.

    I'm sure the development experience will get better with this as time goes on and like I said, each tool has it's place so I'm not trying to alienate DNN saying it shouldn't be used ever. I think however, unless DNN does some serious steps to really leverage ASP.NET 2.0 rather than just compile under it, that the next version of SharePoint with it's foundation in the 2.0 framework will leave DNN miles behind rather than the yards that separate the two now.

    In any case, all good stuff and being on the core team probably means you have a better understanding of the whys and wherefores of what's happening in that scene.


  • Outstanding post, Bil! Love the core modules comparison, and I totally forgot about security trimming.

    I think one reason why SP development seems so difficult is because people don't generally know how flexible the custom lists and views are, and their first reaction is to fire up VS and try to write a custom web part (I fell into this trap at the beginning of my SP experience, too). Couple the WSS OM with CAML, and it seems very daunting. Of course, once your needs exceed the capabilities of a custom list, you're back to the PITA aspect of SP dev. But at least some of the easy stuff is covered.

    My first SP installation was easier than my first DNN installation, but DNN has improved in this area.

  • Thanks Richard. SP does have a lot of different technology to grasp. JavaScript, .NET, CAML, XML, etc. so it is daunting and not something you can just "pick up". DNN has it's share of this in how the system architecture works but I think once you get your head around it's not bad.

    Like I said in the comment to the core team, it's getting better so hopefully we'll see more improvement in this area as I do feel DNN is a good tool, just needs some polishing (even though they're on v4).

    As for the core module comparison, I did leave out some of the other core SharePoint modules to compare against DNN (like the Form Library and Task list in SP) but the post was getting long and out of hand so I decided to call it a night.

  • I'm not very big "Active Directory" fun-aged technology must be replaced by something more useable long time ago;-)

  • I'd like to correct one thing in this wonderful analysis. DNN and SharePoint are both portals - we (Community Server folk) are not positioning Community Server as a portal.

    Rather, Community Server is a platform used to enable community applications. We just had a team in Redmond last week at a SharePoint lab.

    Furthermore, Community Server has been designed, architectually, to scale out; easily supporting multi-server environments as well as the ability to off-load search (we actually offer an Enterprise Search in 2.0) that is completely file system based.

    Community Server is designed to empower sites such as and

    P.S., we're looking to hire some SharePoint experts, so if you read this and think, "interesting." ping me at rhoward _at_

  • Great article Bil. The table comparison is very informative having only had a brief look at DNN some years ago.

    I am interested to know if there is a difference in the visitor statistics they both provide. Whilst this is an area I am still to delve into in some depth, this is something that business owners regularly request.

  • I agree on the complexity of developing DNN modules. It's a complex system, but the advantage is the ease of distribution and installation. There are some decent walkthroughs and CodeSmith templates for setting things up, but it's harder than I expected.

    DNN has supported webfarm deployments since the 3.1 release and makes extensive use of cached data, so I don't know why you've decided it won't scale. Do you have any information to back that up - even anecdotal?

  • @Rob: Thanks for the info and sorry if it sounded like I lumped CS in with the portal view of the world. I was really trying to refer to CS as a community tool, although I haven't seen it as a platform for community applications, only a tool to host forums, blogs, and photo galleries (and files with the latest build). Sorry for any confusion there.

    @Jon: Yes, DNN does support webfarm deployments. I guess when I'm talking scalability I'm talking modularity to scale out that SharePoint offers as you can split up the job server, index server, database server, web front end, and search server (and have load balanced flavours for some of these). While DNN supports the webfarm, the architecture of it (currently) is that everything resides on a single server so you can't say have your eCommerce page running on one server with your registration and administration functions on another. I probably should have said granularity of modular scalability or some techno-babble like that. So yes, DNN scales on the web side (and I guess it will support a SQL cluster, but just assuming it doesn't really care) but I was referring to breaking up the system into more manageble pieces.

    Hope that clears that up.

  • @Ian: Nice summary and decision making process there. It's interesting you didn't consider something like the Club Starter Kit that comes with ASP.NET 2.0. While it's static OOTB, there's a couple of simple tweaks to make the content more dynamic (there are a couple of MSDN articles on extending the kits for this purpose). It's not as dynamic in say adding pages as DNN or SharePoint is, but for something like a Church it might do fine. Food for thought.

  • @Shaun: Great stuff and thanks for the update. As for Master Pages, just stick around to see how portable they become with the next version of SharePoint and the design tools. I think this will trump your statements about portability and designs. DNN skins are great as they're very easy to create, but they're not as powerful as Master Pages (for example, I can't embedd a page within a page with Skins like I can with MPs). Thanks.

  • I would also like to address another point made in the comments above...

    DotNetNuke is not a portal. DotNetNuke is a Web Application Framework. You can use the services in the framework to build portals, but you can also use them to build many other types of applications including standard ASP.NET web applications, community sites, intranets, extranets, and vertical market application service provider ( ASP ) applications. In reality, it is a rich service layer on top of ASP.NET which eliminates much of the mundane coding required to build a web application from the ground up.

  • @Shaun: Thanks again and I'm writing an update blog now as my comments to your message started down a path that was turning into a post so you can check that out and thanks for getting my mind going!

  • Excellent blog!

    We've based our current website on DNN 3 and I'm currently tasked with identifying the strategic direction for the site development, particularly as a number of our clients use Sharepoint and may wish to take advantage of some of the functionality of a number of our modules in their web-parts. These Web-ModParts have business process functions that do not depend on the underlying libraries that each solution framework has.

    In the round I tend to agree with the conclusions that that DNN=extranet, Sharepoint=Intranet for at least the next 6 months until Office 12 comes along, then re-evaluate.

    Comparing DNN with MCMS produces [for me] a view that DNN = non-complex website structure, MCMS = larger scale & wider publication management structure. DNN doesn't yet have any sophisticated search capability.

    DNN wins out for skinning. An important feature where we need to quickly personalise both content and presentation for our clients' online space [In our website].

    Lastly, Whilst I agree with Shaun regarding the development cycle - you can cut out all the envelope stuff if you want to - Once I'd developed a couple of modules, I found that to get to the 'core' of the requirement was a matter of minutes - and the best practice infrastructure was still in place - important to ensure thast future developers of the module worked in a familar framework and to prevent any architectural futureshock.

  • One can never discount the value of "community"!

    In the 3.x series DotNetNuke clearly established a pattern of abstracting features, enabling alternative providers and enhancing framework level services.

    I'll save the monologue *grin*, but version 3.x saw the launch of 24 different BSD licensed sub-projects, each geared toward improving various aspects of the platform ( through modules, installers HTTP compression, etc ). This is a trend that will continue.

    These projects provide opportunity for talented developers and technology professionals to contribute to and derive personal recognition for their efforts. It can be amazing how much motivation 1/2 million adoring eyeballs can generate *grin*.

    Thanks for the very objective and thorough evaluation. They help us improve!

  • I've written several DNN Modules for a customer, and it's a fantastic framework. Further, the architecture has been a source of inspiration for my own ASP.NET work.

    Good article. Thanks.

  • How about web standards compliance (use of ActiveX etc.) and nice playing with non IE browsers, how do they compare here?

  • Hands down DNN all the way!!!

    Go Shaun!!!!!!!!!

  • I have to disagree with the comment about master pages in the next version of wss - NOT A BIG DEAL. the concept is similar to dreamweaver template files - which brings good functionalities, but not even close to skins and containers in DNN. DNN skins are very customizable, flexible and dynamic.

    As far as DNN and Sharepoint, 1 thing will always put DNN a few steps ahead in this duel: 2 words ------>> OPEN SOURCE

  • Maybe this article should be reviewed, it's still the first link to appear on Google using a basic research like "DotNetNuke vs. SharePoint" and it doesn't give the idea of what DotNetNuke really is today. DotNetNuke is used b wide companies since his architecture evolution.

  • may I just say now is 2010 October, this post should be removed as DotNetNuke DNN sucks/sux as well as sharepoint. Period. Thanks.

Comments have been disabled for this content.