By Shaun Walker
Project Founder

As much as DotNetNuke is an open source software application written for the Microsoft ASP.... more

By Shaun Walker
Project Founder

As much as DotNetNuke is an open source software application written for the Microsoft ASP.NET platform, it is also a vibrant community with developers, end users, vendors, and
volunteers — all working together collaboratively in a rich and diverse ecosystem. This chapter attempts to capture the essence of the project, expose its humble beginnings, provide insight into its evolution, and document its many achievements, but not shy away from some of the hard lessons learned in the process. The lifeblood of any community is its people; therefore, it is a distinct honor and privilege to be able to share some of the emotion and passion that has gone into the DotNetNuke project so that you may be able to establish a personal connection with the various stakeholders and perhaps precipitate your own decision to join this burgeoning ecosystem.

In 2001–2002, I was working for a medium-sized software consulting company that was providing outsourced software development services to a variety of large U.S. clients specializing primarily in e-Learning initiatives. The internal push was to achieve CMM 3.0 on a fairly aggressive schedule so that we could compete with the emerging outsourcing powerhouses from India and China. As a result there was an incredible amount of focus on process and procedure and somewhat less focus on the technical aspects of software engineering. Because the majority of the client base was interested in the J2EE platform, the company primarily hired resources with Java skills — leaving me with my legacy Microsoft background to assume more of an internal-development and project-management role. The process improvement exercise consumed a lot of time and energy for the company, attempting to better define roles and responsibilities and ensuring proper documentation throughout the project life cycle. Delving into CMM and the PMBOK were great educational benefits for me — skills that would prove to be invaluable in future endeavors. Ultimately the large U.S. clients decided to test the overseas outsourcing options anyway, which resulted in severe downsizing for the company. It was during these tumultuous times that I recognized the potential of the newly released .NET Framework (beta) and decided that I would need to take my own initiative to learn this exciting new platform to preserve my long-term employment outlook.

For a number of years, I had been maintaining an amateur hockey statistics application as a sideline hobby business. The client application was written in Visual Basic 6.0 with a Microsoft Access backend and I augmented it with a simplistic web publishing service using Active Server Pages 3.0 and SQL Server 7.0. However, better integration with the World Wide Web was quickly becoming the most highly requested enhancement, and I concluded that an exploration into ASP.NET was the best way to enhance the application, and at the same time acquire the skills necessary to adapt to the changing landscape. My preferred approach to learning new technologies is to experience them firsthand rather than through theory or traditional education. It was during a Microsoft Developer Days conference in Vancouver, British Columbia in 2001 that I became aware of a reference application known as the IBuySpy Portal.

... less

Traditionally, web applications are deployed via xcopy (the process of copying multiple files from one place to another)... more

Traditionally, web applications are deployed via xcopy (the process of copying multiple files from one place to another) and the execution of structured query language (SQL) scripts to initialize and upgrade the appropriate database schema. Advanced web applications such as DotNetNuke contain powerful installers that automate this process, improving the user experience and reducing the risk of missing an install step.

This chapter presents a step-by-step guide to using the automated installer packaged with DotNetNuke and provides guidance in selecting a version of the software that is suitable for your organization. The objective of the chapter is to provide you with a working installation of DotNetNuke.

Specifically, this chapter covers the following areas:

• What version of DotNetNuke should you use?

• Installing DotNetNuke v3.x.

• Upgrading an existing installation to v3.x.

• Installing DotNetNuke v4.x.

• Upgrading an existing installation to v4.x.

... less

DotNetNuke is capable of serving many sites from a single installation. The term portal is often used to describe each site... more

DotNetNuke is capable of serving many sites from a single installation. The term portal is often used to describe each site, although the term is somewhat narrow in its definition. So you might ask, what is a portal? The American Heritage Dictionary defines a web application portal as “a web site considered as an entry point to other web sites, often by being or providing access to a search engine.” This can be true of DotNetNuke portals, but they really are more than just doorways to other applications or search engines — they also perform a host of other functions associated with displaying information to your users.

In DotNetNuke, a portal is one site, of n possible sites, in a single instance of DNN, with data and functionality completely discreet from other portals in the same instance. For the purposes of this discussion, a portal can be defined as the related data for one web site hosted within your DotNetNuke installation. The application natively provides the capability to host multiple web sites from the same code base, each containing different information and presented to the user at runtime based on the URL the user enters to access the code base. Exactly how the application accomplishes this task is covered later in the book.

As the portal administrator, you may set up hundreds of various web sites on the same portal. These can be a combination of parent and child portals (discussed later in this chapter), and at
runtime the application will determine the proper content to display to the user based on the PortalID of the portal accessed. This is one of the most powerful features of DotNetNuke and has contributed to the rapid growth of the application since its inception.

... less

Chapter 3 introduced basic concepts that define a portal in DotNetNuke. This chapter details the rich features and functions... more

Chapter 3 introduced basic concepts that define a portal in DotNetNuke. This chapter details the rich features and functions available to customize the look, feel, and function of your DotNetNuke portal and how to maintain it throughout its life.

To make this information more practical, examples in this chapter illustrate a real-world scenario of building a site for a pee-wee soccer team named the Gators. Where applicable, you’ll not only learn how to accomplish tasks, but also when and why to do them. As the administrator of a DotNetNuke portal, you hold the keys to a powerful resource and you’ll want to know how to manage it well.

In Chapter 3, you learned about the concept of hosting multiple portals on a single installation of DotNetNuke. This chapter assumes no knowledge of any portal in the installation other than the one you are currently administering. As far as the Portal Administrator is concerned, his portal exists alone in its own corner of cyberspace separate from any other.

... less

In Chapter 4, you learned just about everything there is to know about administering a DotNetNuke portal. In this chapter... more

In Chapter 4, you learned just about everything there is to know about administering a DotNetNuke portal. In this chapter, you’ll learn everything there is to know about administering a collection of portals, their environment, and runtime features.

As the Host, you function essentially as the “creator” of the DotNetNuke universe in which the portals exist. This is a lofty sounding role, but it is an accurate description because the Host has absolute sway over what portals can and cannot do within their installation. Each Portal Administrator is subject to the “laws of nature” established by the Host, and the Host has complete authority to change those laws at will. Some of those laws apply universally to all portals in the installation, but others apply discretely to individual portals.

Understanding the Host role is essential. Each Portal Administrator considers his or her portal to be alone in its own corner of the cyber-universe, but the Host knows otherwise. Host options provide for differentiation between one installation of DotNetNuke and another. Configuration choices made by the Host can affect function and performance of all portals and must therefore be made wisely and with deliberate intent.

When you complete this chapter, you’ll know everything you need to know as a Host to effectively configure and manage a DotNetNuke installation.

... less

Now that you are familiar with the Host and Portal Administration capabilities available within DotNetNuke, this chapter... more

Now that you are familiar with the Host and Portal Administration capabilities available within DotNetNuke, this chapter looks at a concept familiar to most portals — modules.

A module is a pluggable user interface component that processes requests and generates dynamic content. This definition is similar to that of an ASP.NET page, with the exception that a module can appear only on an ASP.NET page, and a page may contain any number of module “instances.”

DotNetNuke provides a number of modules out of the box. Each module provides its own unique functionality, such as discussion boards, picture galleries, and document management. Developers can also create their own modules that provide alternate functionality.

By the end of the chapter, you should have a good understanding of the architecture surrounding modules and how they relate to the DotNetNuke portal system. This chapter also discusses the practical aspects such as management and installation. An introduction is also given to each of the modules included within DotNetNuke.

... less

The architecture of DotNetNuke has evolved from a simple rewrite of the IBuySpy Portal into a best-practice example of enterprise-level... more

The architecture of DotNetNuke has evolved from a simple rewrite of the IBuySpy Portal into a best-practice example of enterprise-level design patterns and coding standards that can be applied in the real world. This chapter explains the components of the architecture behind DotNetNuke and how they work together to form an enterprise-worthy web application framework.

Before tackling the architectural overview, however, you should understand some key technologies that DotNetNuke employs.

... less

DotNetNuke provides significant capability straight out of the box. Just install and go. Sometimes, however, you may need... more

DotNetNuke provides significant capability straight out of the box. Just install and go. Sometimes, however, you may need to extend the base framework. DotNetNuke provides a variety of integration points: from HTTP modules to providers to custom modules. To fully take advantage of the framework, it is important to understand some of the base services and APIs provided by DotNetNuke.

This chapter examines some of the core services provided by DotNetNuke. You can use these services from within your own code. Because most of the core services are built using the Provider design pattern, it’s also possible to swap out the base functionality. If you need your events logged to a custom database or the Windows Event Logs, then just create your own provider.

The second part of this chapter covers several HTTP modules that are installed with DotNetNuke. They provide features like Friendly URLs, Exception Management, and Users Online. Many of the providers installed with DotNetNuke use HTTP modules to hook into the request-processing pipeline. By examining the code used in the core HTTP modules, you can build your own custom extensions that can be used in DotNetNuke as well as other ASP.NET applications.

The final section examines some of the core interfaces that you can implement in your own modules. These interfaces simplify the process of adding common features to your module, whether it is the module menu, searches, importing and exporting, or even custom upgrade logic. By using these interfaces in your modules, you can provide some of the same features you see in the core DotNetNuke modules with very little coding effort.

... less

In December 2004, Microsoft made available its ASP.NET v1.1 Membership Management Component Prototype. This was distributed... more

In December 2004, Microsoft made available its ASP.NET v1.1 Membership Management Component Prototype. This was distributed as an SDK which, when used by a developer in a project, was referenced as an assembly named MemberRole.dll. Microsoft defines it as “a collection of classes and sample scripts that allows a developer to more easily authenticate users, authorize users, and store per-user property data in a user profile.” MemberRole.dll was simply a backport of a series of classes, from the then ASP.NET 2.0 Beta 2 framework, compiled under the 1.1 framework. This backported version conforms to the same API as is found in ASP.NET 2.0.

Just before releasing the SDK, Microsoft informed the DotNetNuke Core Team of its intentions with this backport. The Core Team discussed the pros and cons of taking advantage of the backport and, after much debate, decided to implement it at that time, using the backport, rather than waiting eleven months to prepare for a future upgrade of DotNetNuke to the ASP.NET 2.0 framework. When it was time to upgrade to the ASP.NET 2.0 framework with DotNetNuke’s 4.0 release, the upgrade task was less complicated because of this decision. The majority of the changes required replacing the DLL reference with a reference to the new classes within the 2.0 framework.

Other factors that weighed in this decision included what MemberRole.dll offered in addition to the easier migration path. In adapting MemberRole.dll, DotNetNuke was also preparing itself for exposure to the hosting market through Microsoft’s Shared Hosting Initiative. This initiative not only placed DotNetNuke in front of a new audience, but also helped DotNetNuke form a solid relationship with Microsoft. That relationship allows DotNetNuke to work closely with Microsoft and reap additional benefits, such as the special license for MemberRole.dll usage that extends the length this DLL can remain in production use. For example, the typical MemberRole.dll license was only permitted for production usage for a period of 90 days after the release of the ASP.NET 2.0 framework. The MemberRole.dll included in framework version 1.1 DotNetNuke releases does not contain this restriction.

For developers, it’s important to understand that the MemberRole.dll referenced in the DotNetNuke 3.x versions, which use the ASP.NET 1.1 framework, is now part of the ASP.NET 2.0 framework. In DotNetNuke 4.x versions, which use the ASP.NET 2.0 framework, it is referenced from the System
.Web.Security namespace.

Before discussing the details of how DotNetNuke uses Member Role, it is first essential that you understand how security works in ASP.NET 2.0.

... less

One of the main goals in developing a web site is to provide the best possible experience for the site’s users. To achieve... more

One of the main goals in developing a web site is to provide the best possible experience for the site’s users. To achieve that goal, the site developer must do many things, including but not limited to creating a pleasant look and feel for the site, making the site intuitive for the end users, and finally, keeping the time it takes to communicate between the client and server as limited as possible. That last item has been a challenge for web site developers for years.

When a user goes to a web site, the remote web server performs a series of events. It receives the request, processes events required by the web application, and then sends the rendered HTML to the client browser. The events are processed on the server side, and what this means is the server must use valuable resources to parse each page and then send it to the client browser as HTML, which is often seen as a disadvantage. One of the major advantages of using server side is that it is browserindependent, so you don’t have to worry about variations between browsers. Everything done by the ASP.NET framework is done on the server side.

When events are rendered on the user’s machine instead of on the remote server, they are rendered on the client side. The major advantage of using client side is that each web browser uses its own resources to execute the code found on the web page, thus taking the workload away from the remote web server. The main disadvantages are that a developer cannot use client-side code to access local files, directories, or databases. In addition, various browsers may not be able to support all methods received from the server. Probably the best general example of something being done on the client side is JavaScript.

Over the years, developers have found that a combination of both client-side and server-side scripting is often best to achieve the desired results. One of the disadvantages of this combination is that it requires the developer to understand how to write code for both the server side and the client side. For example, a DotNetNuke developer would be required to understand one of the .NET languages, probably VB.NET, and JavaScript in addition to HTML. This can be difficult for a developer because a solid understanding of all three programming languages in this example would be required to achieve the best possible result.

... less

The World Wide Web is an international network that must accommodate users from hundreds of cultures, speaking many different... more

The World Wide Web is an international network that must accommodate users from hundreds of cultures, speaking many different languages. This poses a significant challenge for every web application that is targeted at a worldwide audience. To address this challenge, DotNetNuke
provides a built-in localization framework that addresses many of the issues required to make DotNetNuke useable by a global audience. This framework is built to take advantage of the ASP.NET localization features while tackling some of its shortcomings.

This chapter examines DotNetNuke’s core localization API, which can be used from within your own code to allow your modules to be usable by the widest audience. The declarative programming framework is also discussed. It simplifies the localization task for module developers, thereby removing a major barrier to acceptance and usage by module developers.

... less

This chapter begins the tour of module development in DotNetNuke. As you have read, DotNetNuke provides a large amount of... more

This chapter begins the tour of module development in DotNetNuke. As you have read, DotNetNuke provides a large amount of functionality right out of the box, but we also realize that each user is going to have separate business requirements that DotNetNuke may not meet. Fortunately, DotNetNuke provides developers and third-party independent software vendors (ISVs) the capability to extend the core framework by developing modules.

This chapter focuses on the architecture of one of those modules: the Events module. (Chapters 13 through 15 cover various other aspects of module development.) You’ll begin by setting up DotNetNuke to interface with your module development in Visual Studio .NET 2005, exploring some configuration issues along the way.

Although Visual Studio 2005 is used in this book, you can still use Visual Studio 2003 to develop modules for DotNetNuke. The core team evaluated this situation extensively and made every effort to ensure the development process would be similar for developers employing either
platform.

With the release of ASP.NET 2.0 and the new line of development tools, Microsoft has attempted to bring low-cost tools to the developer community. This suite of tools is known as the Express edition of Visual Studio. The Visual Web Developer is a free IDE that you can use to develop modules in DotNetNuke or for other ASP.NET projects. You can obtain the VWD download from http://msdn.microsoft.com/vstudio/express/vwd/default.aspx.

The Visual Web Developer interface is essentially the same as the Visual Studio 2005 interface that is illustrated in this chapter.

... less

Now that you understand the concept of modules and are getting ready to develop your own, this chapter guides you on how... more

Now that you understand the concept of modules and are getting ready to develop your own, this chapter guides you on how to begin development starting with the database layer. As in most application development, you want to build a database structure for your application. This chapter covers some basic database development and how to expose your data to a DotNetNuke module.

Chapter 7 introduced the concept of the Provider Model and how DotNetNuke uses it to abstract the business layer logic from the physical database. In this chapter, you develop your modules by modeling the three-tier architecture of DotNetNuke.

The sections on creating tables and stored procedures review some basic SQL Server development concepts. From there, you learn how to expose the stored procedures through a custom Data Provider that you will develop for your module. Extending on the DotNetNuke architecture, you develop an abstraction layer for the module to provide a separation from the physical database for your module.

Developing with SQL Server is beyond the scope of this book, but this chapter covers how you expose your database’s structure to DotNetNuke. It covers table structure and stored procedures as a reference on how the structure relates to your module development.

Again, the Events module is used in the example for this chapter and the next two chapters on module development. The Events module project is located within the DotNetNuke.DesktopModules solution in the Solutions directory contained off of the root of the DotNetNuke distribution package.

... less

Previous chapters covered how to create a physical database provider for your module, and how all the methods contained in... more

Previous chapters covered how to create a physical database provider for your module, and how all the methods contained in the provider directly correlate to stored procedures within the database. After the provider was completed, you created an abstraction class that abstracts the methods contained in the provider to be used by the Business Logic Layer (BLL).

In this chapter, you will transform the record set returned by the provider into a collection of objects that is provided by the Business Logic Layer within your module. This chapter continues with concepts that were introduced in Chapter 7 on the DotNetNuke (DNN) architecture, because module architecture mirrors the architecture provided by DNN.

The idea here is to totally separate the physical database from the module or application logic that you create. Separating the two enables plug-and-play extensibility when you want to change a database provider. Because the provider is abstracted from the actual business logic, you can use the same code, but different data stores, and because they’re compiled separately, there is no need to recompile the application to change database providers.

You will now extend this provider architecture to the business logic of the application. Here you create a collection of objects with specific properties that will be exposed to your user layer, which is covered in Chapter 15.

... less

Now you’re at a point where you can start making your presentation layer for your desktop module. You have learned how to... more

Now you’re at a point where you can start making your presentation layer for your desktop module. You have learned how to pull data from the database, provide abstraction, and then transform the data to a collection of objects from your Controller class. This chapter provides you with examples on how to display, modify, and work with the various controls that make up your desktop module in DotNetNuke (DNN).

The examples in this chapter first show you how to make a call to the business object to obtain the information, and then you’ll create an Edit control to update the data and to specify settings that are specific to the module instance.

From there, the chapter moves on to the various user controls and interfaces that you can use to your advantage in your module development.

... less

The capability to skin DotNetNuke was introduced in version 2 of the application and was a much-anticipated addition. The... more

The capability to skin DotNetNuke was introduced in version 2 of the application and was a much-anticipated addition. The term “skinning” refers to an application’s ability to change the look of the design by a setting in the application. This allows for the separation of the application logic from the user interface or object abstraction. As you learned in previous chapters, DotNetNuke uses a three-tier object-oriented design approach, with the user interface segmented as its own tier. This is what enables skinning to work and what enables the framework to present a unique feel depending on the parameters passed to the page. This chapter looks at the finer points of skinning and provides you with the tools to start building your own skins for DotNetNuke.

... less

This chapter examines how DotNetNuke add-ons can be distributed and installed. As DotNetNuke has progressed, functionality... more

This chapter examines how DotNetNuke add-ons can be distributed and installed. As DotNetNuke has progressed, functionality has been added to enable developers to package and distribute extensions to the DotNetNuke framework. These add-ons enable the administrators and users to customize the portal to suit their particular needs. Add-ons can provide additional functionality or can alter the visual presentation style for the portal. DotNetNuke uses zip files to package and redistribute add-ons. Each add-on type defines the specific files that can be included in the package. The custom add-ons are divided into three major categories:

• Code add-ons
• Modules
• Skin objects
• Providers
• Skinning add-ons
• Skins
• Containers
• Language add-ons
• Language packs

There are many aspects to consider in the distribution of add-ons, and this chapter answers the following questions as you look at each of these add-on types:

• What is the format of the manifest or configuration files for the add-on?

• How do you package all of the elements that go into a single add-on?

• How do you install the add-on?

... less

There are numerous effective resources that bring value to the development or business aspects of using DotNetNuke. Table... more

There are numerous effective resources that bring value to the development or business aspects of using DotNetNuke. Table A-1 describes a number of great developer tools, many of which are used by the DotNetNuke community and Core Team members. Some of these developer tools are free and others have fees.

... less

System tokens were introduced in Chapter 4... more

System tokens were introduced in Chapter 4

... less