Much of the integration work on the Membership API and usability improvements were fueled by a much larger hosting initiative that Microsoft was preparing to unleash in May 2005. This initiative included a comprehensive program aimed at increasing awareness for Windows-based hosting solutions on an international level. Based on its strength as a framework for building consumer web sites, Microsoft invited DotNetNuke to participate in the program as long as it could meet a defined set of technical criteria, including Membership API integration, Medium Trust CAS compliance, localization, and usability improvements. Nearly all of the enhancements were already identified on the product roadmap, so the opportunity to be included in the hosting program was really a win-win proposition for the project and the community. In addition, we believed that the benefit of participating in such a large-scale initiative would be enormous in terms of lending credibility to the DotNetNuke product, introducing the project to influential new stakeholders, and helping to build brand equity.
Core Team members made significant contributions during the development of DotNetNuke 3.0. Scott McCulloch, with the assistance of Jeremy White, implemented a full-featured URL rewriting component that allowed DotNetNuke to use standard URLs. Vicenc Masanas was instrumental in working on localization, templating, and stabilization tasks. Joe Brinkman implemented search-engine architecture, enabling content indexing across all modules in a portal instance. Jon Henning introduced a Client API library, enabling powerful client-side behavior in DotNetNuke modules. Perhaps the greatest code contributions were made by Charles Nurse. Realizing the massive amount of work that would be required to deliver the enhancements for the hosting program (and knowing that using only volunteer efforts would not hit the schedule deadlines), I hired the first full-time DotNetNuke contract resource. Charles was immediately put to work abstracting all of the core modules into independent private assemblies. At the same time, he reorganized entry fields in all application user interfaces and added full localization capabilities, including field-level online help.
The concept of localization was one the most commonly requested enhancements for the DotNetNuke application. Localization actually has multiple meanings when it comes to software applications because there is a distinct difference between static and dynamic content. Static content is information that is delivered as part of the core application typically implemented by developers. Dynamic content is information that is provided by users of the application and is typically entered by knowledge workers or webmasters. In DotNetNuke 3.0, we delivered full static localization for all administrative interfaces. This meant that all labels, messages, and help text could be translated and displayed in different languages based on the preference of the user. Developing a scalable architecture in this area turned out to be a challenging task because the solutions offered by Microsoft as part of the ASP.NET 1.x framework were better suited for desktop applications and had serious deficiencies and limitations for web applications. Instead, we decided to target the ASP.NET 2.0 localization architecture, which better addressed the web scenario. However, due to the specific business requirements of DotNetNuke, we soon realized that we were going to have to take some liberties with the proposed ASP.NET 2.0 localization architecture to enable us to achieve our goals for runtime updatability and scalability in a shared hosting environment. In the end, we were able to deliver a powerful solution that satisfied our business needs and provided forward compatibility to the upcoming ASP.NET 2.0 release.
The optional interface architectural model described earlier reaped rewards in DotNetNuke 3.0 in a number of key application areas. Registration of module actions in earlier versions of DotNetNuke was always less than optimal because they were dependent on page life-cycle events that were difficult to manage in a variety of scenarios. Optional interfaces finally provided a clean mechanism for the core framework to programmatically call into modules and retrieve their module actions. Other new features based on optional interfaces included content indexing, import, and export. In each of these cases, the core framework could rely on modules to provide content in a specific format that then allowed the core framework to provide advanced portal services.
After multiple beta releases (some of which were deemed not fit for public consumption), DotNetNuke 3.0 was officially released on March 12, 2005. Although there were breaking changes between DotNetNuke 2.0 and DotNetNuke 3.0, a number of modules were immediately available for DotNetNuke 3.0 due to the success of a pilot program named "30 for 3.0." This program was the shrewd strategy of Scott Willhite, and allowed a serious group of commercial module developers to have early access to beta releases of the DotNetNuke 3.0 product, enabling them to deal with any compatibility issues before the core framework became publicly available. Aside from the obvious benefits of having "applications" immediately available for the new platform, this program also provided some excellent business intelligence. It proved one of Scott's earlier assumptions that the vocal forums community represented only a small portion of the overall DotNetNuke user community. It also exposed the fact that DotNetNuke had found its way into Fortune 500 companies, military applications, government web sites, international software vendors, and a variety of other high-profile installations.
DotNetNuke 3.0 was released with two supported languages: English and German. Delivering two complete language packs adhered to one of our newer philosophies of always attempting to provide multiple functional examples to prove the effectiveness of a particular extensibility model. Before long, community members began submitting new language packs in their native dialects that were posted on the dotnetnuke.com site for download. The total number of supported language packs soon surpassed 30. This resulted in incredible growth and adoption for the DotNetNuke framework on an international basis.