As we jumped into the DNN train in 2005, our emotions went extremes from literally loving it, to complete frustration of being stuck into a mud.

After all we've been through, as an overall impression, we generally are content with it and can recommend to everyone.

But the road is not so straight.

Maybe you can create a working portal within seconds, but completing a web project with DNN is not a straightforward task.

"If you have a hammer in your hand, everything seems like a nail to you".

This is what happens when you deal with DNN for some time. This is the "Temptation of Using DotNetNuke". After we started to use DNN, every time we had a web project in hand, we thought of using it. Most of the times, we did use.

The question is : "In which cases should I use DotNetNuke?"

We used DNN from large scale portals to even small personal web pages. Using a CMS for large sites looks like an obvious choice, but using it also on smaller sites yielded good results.

But as general, it has "pros and cons".

You rarely complete a DNN project without implementing one or more custom modules. It doesn't take too much time to discover that built-in modules does not cover 100% of customer needs.

And as you may know, creating custom modules is not easy as producing stand alone applications. Module developing task was even harder with versions 3.x and below.

If you don't control the project process firm enough, sometimes, you override the spirit of framework. And this is the start of the collapse. Your DNN Visual Studio Solution project becomes a stand-alone mutant project (that is no longer a framework). The obvious consequence is that you can no longer upgrade to the next version.

After completing a few of such false practices, we came to the conclusion that : "Never touch the framework and make your developing with respect to framework principles".

Unless the project is really geared for a portal and both sides agree that a CMS is a must, you have the dilemma of "Design vs Functionality".

You may be well aware that the project seems more like a portal rather than a advertorial web page, but you should be well prepared to convince your customer.

The visual design is very important and unfortunately, when you deploy DotNetNuke, you have less choices.

SEO (Search Engine Optimization) is an overlooked issue in any way. But especially when we use a framework, we tend to think that the portal is already SEO friendly. But it's damn wrong. You should still work hard to optimize your site.

First of all, besides all its benefits, DNN brings some problems to site optimization. Most significant problem is the huge HTML load of the pages (including javascript linked files). Adding the HTML loading time to the server processing phase, your pages may download slow, and its not good for search engine popularity.

Also you have disadvantages for long URLs and vice versa.

You should overcome these difficulties by taking care of your site. Do not take SEO for granted. Fortunately, you have everything in hand to tune up your DNN site.

We tend to use DNN even in small web projects and we never regretted it. After years of development and the persistence of the community, DotNetNuke proved itself as a stable and strong framework.

To make things short, we trust the future of DNN but we take our steps very carefully. Because it's still an untamed terrain.