DotNetNuke Portal Private Assembly Development

DotNetNuke PortalPrivate Assembly Development • Stan Schultes • Enterprise architect / application developer • Conference speaker, mentor, trainer • Contributing Editor, Visual Studio Magazine • Founder - .NET Pub Club (netpubclub.net) • Microsoft MVP • www.vbnetexpert.com • stan@vbnetexpert.com

Presentation Outline • Portal Review and Requirements • Private Assembly Installation • Technical Overview & Architecture • Data Provider Architecture • DNN in Design Mode • Private Assembly Development Process • Development Topics • Links and Resources

DNN – Portal Review • DotNetNuke = Open Source portal • Tabs = portal organizational units • Modules = information containers • Info access controlled by Roles and Users • Data providers = implement storage in a variety of databases

DNN - Portal Requirements • Current portal version: v2.1.2 • Requires: • Win2K, WinXP, or Win2K3 • IIS installed and operational • .NET Framework V1.1 • Access or SQL Server 2000 / MSDE • SMTP configured if you want to use mail • VS.NET 2003, or custom build environment (no SDK version available today) • DNN is written in VB.NET, but you can write modules (.DLLs) in any .NET language

DNN - Installation Process • Installation Process: • Unzip the code to a directory, give ASPNET/Network Service account permissions to that directory • Create a virtual directory in IIS Manager • [ Create an empty SQL database, set up DB account ] • Edit web.config – set data providers up • Browse to http://localhost/vdir • Change Host and Admin passwords! • Upgrade Process: • Back up your current configuration • Unzip the new code into the directory structure • Browse to the vdir

Demo – PA Installation • PA = Private Assembly (aka Custom Module) • Four PAs are distributed as samples: • PageTitle • Survey • Users Online • Whois • Installation with Host  File Manager • Config with Host  Module Definitions • Control Types, Multiple Controls

DNN - Technical Overview • Framework application • Modular, extensible construction • Dynamically loaded user controls • Provider model • Business logic / UI layers separated • Online portal configuration by role • Multi-portal: parent or child configuration

Provider Model • Data access based on the Whidbey Provider model (see Resources) • Databases supported: • Access (default), SQL Server 2000/MSDE • (future) mySQL, Oracle • Provider model: • Rich Text editing • Exceptions / Logging • Scheduling • Authentication (future)

DotNetNuke Portal • Portal provides plumbing and services: • Membership • Role-based security • Personalization • Management • Navigation • Data access • Site & exception logging

DotNetNuke Architecture

Data Provider Architecture • Data Store – MS Data Access Application Block • Concrete Data Providers – built as separate .DLLs (SqlDataProvider.dll, AccessDP, etc.) • Abstract Data Provider – DataProvider.vb • Business Logic Layer – SuggestionsDB.vb: • Abstracts the data layer from the portal • Custom Business Object (CBO) helper • User Interface Layer – user controls (.ascx)

Concrete Data Providers • Implemented as separate components • Use MS Data Access Application Block • SqlDataProvider.vb:

Abstract Data Provider • Located in the Data Access Layer • Instance method is the Data Factory • DataProvider.vb:

Business Components • Located in the Business Logic Layer • Interface structures between DB & app

Business Components (cont’d) • Controller classes provide the app/DB conversion interface

Data Layer Topics • Instance method – data factory • Configuration • Database scripts • {databaseOwner} and {objectQualifier} • Data transport via DataReaders • Custom Business Object Helper (CBO) • Null Handling • Caching

DNN in Design Mode • DNN v2 built with VS.NET 2003 • Change .sln and .webinfo file if not default DotNetNuke vdir • Release mode vs. Debug mode • All standard modules are integrated in .sln • Build private modules in any language – as separate project.

Project Organization • Directory structure: • Root – few .aspx’s, http handler, global.asax • Admin – user controls for all system pages • Components – business logic for portal • Controls – title, header, footer, skin controls • DesktopModules – module add-ins • Portals\n\ – content directories by portal • Providers – separate projects

PA Development • PA = Private Assembly / Custom Module • Develop PAs in any .NET language • Development Overview: • Project Setup • Build the Data Layer • Create the User Controls • Package the PA for Installation • Deployment

PA Dev – Project Setup • Tip: find a similar module and copy it • Create a new directory under DesktopModules: • VBNetExpert.Suggestions • Create new project in that directory: • Clear Root Namespace • Set build output path to DNN \bin directory • Set References • Create \Providers\DataProviders subdirs: • \SqlDataProvider • \AccessDataProvider • These will also become separate projects

PA Dev – Build the Data Layer • Design your module’s logic • Build one data provider at a time • Create the required database table(s) • Create and test all Stored Procedures • Create abstract data layer (DataProvider.vb) • Create & build project for concrete data provider (SqlDataProvider.vb) • Create business objects (SuggestionsDB.vb)

PA Dev – Create User Controls • This is the portal Presentation Layer • DNN V2 allows multiple user controls per module (V1 allowed two: Edit & Display) • In control sources: Imports DotNetNuke • All controls inherit from PortalModuleControl: • Main control (Suggestions) • Edit control (EditSuggestions) • Module options (EditSuggestionsOptions) • Other as required (DisplaySuggestions)

PA Dev – Packaging for Install • Create DB install & uninstall scripts • Create .dnn file (installation manifest) • Folder contents & module strings • Modules & Controls • Files deployed (ascx, dll, sql, etc.) • Package additional files in .zip (images & icons, help & readme files, etc.) • Package everything into master .zip for upload to portal • Test!

PA Dev – Deployment • PA deployed & managed through the Host account • All related Modules are included as “definitions” in Host  Module Definitions • Portal database tables affected: • DesktopModules • ModuleDefinitions • ModuleControls • Sql files need to be in UTF-8 format…

Converting Modules from V1 • Convert data calls to Provider model • No longer share edit & module options with panel controls • Don’t include DesktopModuleTitle control • Module registration changes: • Module tables have changed • No .sql script for controls registration • .dnn file structure defines module registrations • PMC.Actions.Add for referencing controls • ArrayLists for data binding • Use EditURL and NavigateURL methods

Development Topics • Roles & Permissions – how to detect them in the code • PortalModuleControl • ModuleID, TabID • Components\configuration.vb • ObjectBrowser is your friend!

Development Topics (cont’d) • Development tools: • CodeSmith with templates • Skinning • Security • Modifying the core code

Questions?

Resources • DotNetNuke: www.dotnetnuke.com • FW 1.1: http://www.asp.net/download-1.1.aspx • Provider Model: http://msdn.microsoft.com/library/en-us/dnaspnet/html/asp02182004.asp • My V1 modules column: http://www.fawcette.com/vsm/2003_12/magazine/columns/gettingstarted/ • DNN docs: site documentation subfolder • DNN help: http://www.dotnetnukehelp.com • Resource portals: http://www.dnn.com.au, http://dnnjungle.vmasanas.net/ • Developer portal: http://www.dotnetnuke.dk • Free modules list: http://www.cathal.co.uk/Default.aspx?tabid=28

DotNetNuke Portal Private Assembly Development