Beginning Module Development-Planning Your Module Project

Planning Your Module Project

Of course, to succeed in any project, you should plan it out before you start writing even one line of code. Planning includes considering the answers to any number of questions as well as readying your resources.

Business Considerations

You're going to have to ask yourself or your project team a few questions before beginning your application development. For example:

Q	Can the development effort justify the savings that your application will provide?
A	Many factors can come into play: skills of in-house staff, costs associated with obtaining the skills, and many others that you will have to account for.
Q	Can the module be purchased from a third party?
A	DotNetNuke has grown in popularity over the past couple of years, and the outlook is for continued growth. More independent software vendors are developing modules, so more than likely there is no need to develop a module to accomplish a specific task — you can purchase it for very little cost. As of this writing, more than 250 modules are currently available for sale, and many more are available as free downloads. Some of these modules are written specifically for the 1.1 version of DotNetNuke, but there is an increasing number specifically targeting the ASP.NET 2.0 platform and DotNetNuke 4.0. If the module developer has written the module to conform to the same standards as the DotNetNuke core modules, the module will function in either the 3.2 version for ASP.NET 1.1 or the 4.0 version developed for ASP.NET 2.0.
Q	Is training required for developers?
A	Module development does require some additional skills. You develop modules in DotNetNuke using the standard tools you would use to do any ASP.NET development, but knowing how to take advantage of the available interfaces requires some understanding of the framework's inner workings. In addition to this book, many resources are available for learning about DotNetNuke if you want to investigate further. You may develop modules in any language supported by the .NET framework, including C#, J#, and VB.Net. This discussion sticks with VB.Net, the language in which DotNetNuke is written.
Q	Should you hire an outside resource to do the development?
A	Training becomes less of an issue when you have your development done by an outside resource. DotNetNuke's popularity has increased at such a phenomenal rate that many solution providers specialize in module development.
Q	What infrastructure issues are there?
A	How many developers are going to be working on the same code base? The more developers working on the same code, the more there is a need for source control. Scalability also may be something to consider. In addition, if you have to access resources over the Web, you need to read some of the application settings configured at a host level in DotNetNuke.
Q	Do you need to develop multiple data providers for the module?
A	What database are you going to use for the backend? DotNetNuke supports a Provider Model that enables developers to abstract out the physical database interaction, allowing the actual DotNetNuke core and module logic to be separate from the database logic. DotNetNuke supports SQL Server out-of-the-box, but a provider can be developed for basically any database backend. How many physical databases you need to support will determine how many providers you need to develop. Module development closely mirrors the DotNetNuke architecture, and you should create a provider for each platform you want to support. If you're going to distribute your module on various DotNetNuke installs with different databases like SQL Server, Oracle, or MySQL, you need to develop a provider to support those individual databases.
Q	Do you need to support different versions of DotNetNuke?
A	DotNetNuke is a mature product with several released versions. There have been many major architectural changes going from version 1.x to 2.x and to 3.x. DotNetNuke 4.x uses essentially the same provider model as DotNetNuke 3.x. At the time of this writing, the latest release was DotNetNuke 4.0.2. If you are developing on a later version, verify that there have not been any changes to the provider model for your version. If your module needs to be available on these various versions of DotNetNuke, you will need to manage the various code bases to accommodate all the required versions.

Note

Modules developed for version 3.2 (on ASP.NET 1.1) will run on version 4.02 (on ASP.NET 2.0) unaltered because of their binary compatibility.

Q	What resources are needed for ongoing support of the module?
A	This may not be as much of an issue for modules purchased or developed by an outside party. You may be able to obtain adequate support from the vendor. If you develop in-house, you'll need to set aside resources to provide ongoing support of the module.

Of course, this list is not all-inclusive, but the example questions should be enough to help you determine the questions you need to ask regarding your own application.

Ready Your Resources

Now that you have decided to begin module development, you need to prepare your development environment. The source and project files are available in the DotNetNuke distribution file that you can download from www.dotnetnuke.com. Just as you installed DotNetNuke on the production server in Chapter 2, you need to configure a development machine with the source code — and the process is the same.

Ensure that your development environment is configured with Visual Studio .NET 2003/2005, SQL Server 2000/2005, or MSDE/SQL Server Express (or your specific data provider). In addition, if you are working with your source files in a location other than the DotNetNuke default (c:\dotnetnuke), you may need to change the solution file (dotnetnuke.sln) and the web information contained within the solution (dotnetnuke.webinfo) to point to the location of the virtual directory for your environment. That will ensure that you can open the solution correctly in Visual Studio .NET.

You may want to consider installing Visual Source Safe, or some other source control to ensure integrity of your project source code. Installing Source Safe is beyond the scope of this book, but it is recommended that you use some sort of source control to protect your development.

Another item to note is the publishing process from your development environment to your production environment. Because DotNetNuke is ASP.NET-compiled into several assemblies, the most it takes to publish to production is simply copying the development assemblies, user controls, associated ASPX, and resource files. Before you compile your module for production, ensure that the build configuration in Visual Studio.NET is set to Release, not Debug.

In many environments, an extra stage in the development process is added by placing a sandbox or testing server between development and production. The testing server should mirror your production environment as closely as possible — install your module to the testing server and test first. After the business units review the functionality and ensure it meets the requirements, publish the module to the production servers.

--
Happy day, happy life!