Tools & Code: Installing DotNETNuke From The Source-Code Package

DotNETNuke (DNN), is probably one of the best complete CMS frameworks developed for the ASP.NET platform. Yes, there are others, but in my research none of these alternative frameworks combine the capabilities and extensibility that the current DNN platform does.

Unfortunately, the success of DNN has had a detrimental effect on their ongoing documentation efforts, which many can already attest are falling behind in their compatibility to current versions and framework extensions. Downloaded documentation files are still displaying 2006\2007 timestamps and have not been revisited since.

The DNN site itself has become as proportionately extensive as that of Microsoft’s. The result, as any technician who has visited the site can attest to, is a maddening labyrinth of articles, blogs, notes, and documentation files that seemingly have little connection or relevance to each other in terms of their placement within the site let alone the aging nature just mentioned.

Installation then from a source-code package, which most professional developers would select, if for nothing else curiosity, is basically well-done but has issues with minor aspects of the installation process that could affect such an installation along with the sanity of the developer doing it.

Several months ago, I wrote a technical memorandum to the DNN team clarifying these installation issues, while demonstrating that by adding just some minor re-organization to the installation information along with some minor clarifications, a source-code package installation could be made much easier and less fraught with issues that could literally cancel out any promising endeavor for the use of this framework.

For your benefit, this document has now been posted here for developers who are looking to install DNN on their company site’s servers or their own. The technical notes included should make any such installation a rather easy process without any of the potential headaches…

The document that follows was accepted by the people at DNN Corporation and I was placed on their list for additional assistance with their documentation projects.

Black Falcon

Re: Installing DNN 5.01.01 From The Source Code

Hello…

I have just finished about 9 hours worth of in-depth analysis on the DotNETNuke Framework in terms of installation issues with both your source package as well as the standard installation package… and I have a number of comments to make.

As a senior software engineer with over 35 years in the field I have done just about everything there is to do in the business application arena so I have seen a wide swath of issues with scores of applications and frameworks.  So if you would allow, I speak here from extensive experience in the IT field/

First and foremost, DotNETNuke is an incredible framework given the breadth of its capabilities and the community that supports it. And for once something of this scale is written in VB.NET and not C#.

I have been researching the use of this framework for years and have finally been able to propose it to my client as a consideration for the document management functionality they would like to offer both the corporate environment as well as the many subsidiaries this client owns.  This proposal is going into some very serious business environments that have nothing to do with current web fads, startups and the like.  As  a result, if this proposal is accepted, The DotNETNuke community just may see an interesting uptick in their installations that involve some very serious business concerns.

That being said, there are a number of installation issues that have to be addressed; there are simply too many issues that come up without immediate answers available.  This contention is corroborated by the many installation problems reported in your forums.

Most often technical personnel will be doing DNN installations for their sites with a lesser number being installed by end-users with some technical knowledge (ie: web hosting DNN installations).  Thus the installation support should be first and foremost towards the technician and not the administrator who may or may not be competent technically.   And though you have made a good attempt at performing a non-technical installation, I have found  from my own attempts at running the installs (and I have done several) that there are too many questions that a technical person would naturally pose that aren’t clarified with any supporting information to help him or her make informed judgments as to why they are selecting a certain option or updating some installation code.

For example, your installation to SQL Server 2008 Express, though it works just fine, actually goes against the “grain”, more or less, as to how database development professional would view such an installation.  DNN makes use of the new “User Instance” in the express versions of SQL-Server but what database developer would use such an attribute?  I researched the use of this new addition to SQL Server and found it to be very similar in nature to typed-datasets, designed for less technical personnel but highly limiting to well trained personnel.  I certainly would never use it but try setting up DNN with SQL Server 2008 Express without the “User Instance=True” and you get a minefield of issues that are not readily explained or apparent.

I run SQL Server Express 2008 on my laptop and workstation at home.  My laptop supports my work at my client.  On my personal workstation it is simply there for quick work when I do not want to power up my database server for the full versions.  I connect to SQL Server 2008 Express the same way I connect to my server databases.  It should be that way with DNN or at least an option that DNN understands right out of the box making connection string updates easy and without any issues.

In terms of the DNN source-package installs, this can be a nightmare of potential pitfalls for the technician.  And yet it doesn’t have to be.  Like many .NET web-based applications that are designed for distribution to the public, the solution structure can often be a determining factor in the success or failure of such an installation.  Some solutions are built in such an arcane fashion that one small change to its setup can blow the entire installation out of the water.  To some extent this is true of DNN, maybe not so much as a result of the solution structure but from the lack of detail and information as to why it is structured in the way it is and the variety of dependencies that exist.  In addition, installing the source-package for a SQL Server 2008 Express environment has some different aspects to it than that of a server environment as noted above.  All of this should be clearly spelled out for a developer who is tackling such an installation.

For starters, your “README” file is in the wrong place.  It should be placed at the top-most level of your source package where the solution files reside.  It should also scream “READ ME BEFORE DOING ANYTHING WITH THIS SOURCE CODE!!!

Second, to make this file more prominent it should be as nicely setup as your PDF manuals are to further the impression on the new developer that this information is critical to a successful source-package installation.

In addition, I have made some notes, which I believe will resolve numerous installation issues which you may want to elaborate on and include in this file.  They are as follows…

• Rename the “Development.config” file in the “Website” directory to “web.config” (You say this in your own Notes but as a result of the placement of the file such information is not readily significant.)
• Place the updated\renamed “web.config” in both the top-most directory where the solution “.sln” files are andkeep it as well in the “Website” directory.  This is probably not required in terms of placing this file in bothdirectories but it certainly will avoid any issues while running an installation.
• Create a Virtual Directory in IIS called DotNetNuke which points to the “Website” directory where theDotNetNuke.webproj file exists.  It is preferable to place the DotNETNuke directories and files in a separatedirectory structure that is not part of “inetpub\wwwroot” so that no potential conflicts may arise during compileand installation.
• Compile the entire DotNETNuke solution and make sure that there are no errors.  If errors are listed this means that the web.config files have not been properly updated and placed.  Go back to items 1 and 2…
• If using SQL-Server 2000, 2005, or 2008, create ONLY the database structure on SQL-Server 2000, 2005, or 2008 before attempting to run a source-package installation; obtain the proper connection information and update the connection strings in bothweb.config files with the added connection-string parameter of “User Instance=False”
• If using SQL-Server 2005\2008 Express, DO NOT CHANGE EXISTING CONNECTION STRINGS except for database name; leave the login credentials alone. User Instance=True”  (this is required when using SQL-Server Express editions for DNN

If you prepare the “README” file and these notes are followed in the order they are listed you should see a substantial reduction in with reported installation issues.

Finally, I would recommend preparing a detailed source-package manual for the current version of DNN that not only details the notes I have mentioned but the many details that comprise the understanding of the source-package such as what each module does, why it is included, and what issues can come up if the appropriate references are not left intact.

Thank you for your consideration and time in reviewing this information.