The project is designed to address a common usability concern with the default DotNetNuke control panel, which is perhaps best illustrated pictorially:

A Scary DotNetNuke Menu with Many, Many Options

As users of the framework have surely noted, the list of modules available to an administrator is lengthy and highly-confounding.  While experience mitigates this difficulty, it remains a significant challenge for new administrators to understand which module to select from this imposing list.

This project attempts to group this set of modules into manageable containers where each module is grouped by function (e.g. administrative modules, e-commerce modules).  By way of example, a clean DotNetNuke 5.1.4 install with ALL core modules installed (and grouped into logical containers) would be reduced to a very understandable list:

A compact, minimized DotNetNuke control panel module list with groups by function. Note that the image above continues to utilize the default DotNetNuke control panel; the containers do not require any adjustment to that component.

After a container is selected and instantiated, a user is prompted to select from one of the modules contained therein:

Interactive selection of a module within a grouping after selecting the group from the control panel.

The selection process utilizes jQuery, minimizes the number of post-backs, and (in my opinion) greatly increases overall usability.

This module is expected to be released sometime in mid-to-late November for public consumption.  A limited beta may be made available prior to this date, subject to interest.

Your feedback is appreciated.  Does the lengthy DotNetNuke module list bother you?  Would you (or your administrators) find a solution of the type outlined above useful?  Please leave a comment and share your thoughts.

B

Some additional screenshots:

To remedy this issue, I have developed an adapter that converts the Entity Framework model generated by the designer into a DotNetNuke-compatible model that uses both the object qualifier and database owner specified by an end-installation.  This adapter is based off of the more generalized model adaptation framework that I recently released.

My goals for any satisfactory solution were as follows:

This solution extends the Entity Framework runtime model adapter to operate within a DotNetNuke extension, allowing a developer to design against an unqualified, dbo-owned DotNetNuke instance and be assured that it will deploy (and operate) correctly on any configuration that an end user might have deployed. Adaptation is largely inexpensive, and since the models are cached by type, performance is not significantly affected.

Click here to access the project site for additional details and downloads.  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

As always, feedback is greatly appreciated.

B

The ObjectContext is a base class for all Entity Framework models.  While there exists a rich API for interacting with a model, the ability to adapt the underlying schema to the (potentially varying) run-time environment presents a serious shortcoming for many production applications.  These variances can potentially involve myriad considerations, from a change in database owner to modified table names (often by a production-specific prefix).  This can have a serious impact on large-scale deployment of applications using the Entity Framework (those familiar with my DotNetNuke-related work will immediately understand this consideration, where a run-time environment may be configured to use an arbitrary database owner or table prefix).

To remedy this issue, I have developed an adaptive framework that converts an Entity Framework model generated by the Visual Studio designer into a highly configurable result.  This framework is designed to be flexible, extendable, and highly customizable.

My goals for any satisfactory solution were as follows:

• Run-time adjustment of an Entity Framework EDMX model, including:
  • Connection-based adaptation (e.g. use of a runtime-specified connection string)
• Run-time adjustment of model schema, including:
  • Adjusting data-level table prefixes or suffixes
  • Adjusting the owner of database objects
• Continued use of the Visual Studio Model designer
• No tedious changes in the compiler-generated code
• Continued use of an assembly-embedded EDMX model (and thereby no additional or external schema deployment files)

It is unfortunate that the object model exposed by the Entity Framework is so frustratingly difficult to extend.  The underlying metadata are overwhelmingly read-only (and, frustratingly, many potentially useful classes are either internal or sealed).  Indeed, it seemed that there was no simple remedy to the problem at hand.

My solution utilizes the following approach:

• A Connection adapter is used to walk a model (and optionally adapt a connection string based upon a run-time environment) [Goal 1].
• During the model walk, a dependency-injected model adapter is utilized to adapt various attributes of the model (currently storage, mapping, and association) [Goal 2].  Walking is reasonably inexpensive, and since the models are cached by type, performance is not affected.
• The framework requires only a change in base class to an AdaptingObjectContext (which itself derives from an ObjectContext).  This allows the Visual Studio editor to continue to be utilized, and no direct EDMX manipulation is required (though, frustratingly, the base class of an entity model is not adjustable through the Visual Studio UI, necessitating a change in the code-generated file) [Goal 3, 4, 5].

I use dependency injection to adapt attributed entities (database, table, and function names) into their adapted counterparts.  Additional adapters could easily be constructed for other domains, should any arise (to illustrate this point, a NonTransformingAdapter is included in the release, which performs no transformations).

Click here to access the project site for additional details and downloads.

As is all of my DotNetNuke-related work, this framework is available under a liberal open-source license for ready public consumption (and extension).  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

As always, feedback is appreciated.

B

As one of my goals is reasonable provider-independence (via adaptation), this is not about realizing any particular vendor (despite the fact that I address one specific such vendor herein).  That said, I have been asked by several parties to share a bit more about where this stands; it is with this in mind that I present an initial update.

In selecting a set of third-party providers, it was of some importance to deal with an e-commerce system that was reasonably foreign to the .NET universe (within which DotNetNuke lives).  With this in mind, I selected the Magento framework as an initial target for review.  In addition to being PHP-based, it boasts a reasonably sophisticated API, a beautiful interface, and solid overall architecture.

Integration in conformance with my internal architectural specifications was largely straightforward.  However, Magento currently lacks any meaningful cart-API.  This means that, inter alia, there is no API method by which an external consumer may retrieve a customer’s current basket (without resorting to screen-scrapes and other such horrors).  As such, it remains incomplete as an option for fully satisfactory externalization — though it is tantalizingly close.  It is my hope that this omission might be corrected in some subsequent Magento release, though I have no inside information about plans for future API development.

I present the screenshots below — designed to closely emulate the Magento model store — as a point of discussion about the potential future of DotNetNuke and e-commerce.  All components displayed therein are actual, working modules.  In my opinion, this is what e-commerce on the DotNetNuke framework should look like.

Note that, in the area of e-commerce, I am largely constrained by contractual IPR constraints, and this significantly affects my ability to release the constituent modules.  However, as my architectural research continues, it is my hope that these data might be partitioned and released in an open-source manner (as is all of my other DotNetNuke-related work).

As always, comments are appreciated.

DotNetNuke and Magento Integration Screenshots

Attribution Notice:  These screenshots above are derived from Magento IP released under an Open Source License (”OSL”) version 3.0.  As such, I am required per §1.C to license these images under the same; all other rights (including rights over the accompanying text) are reserved per the notification below.

This paper is intended for all audiences who might have an interest in overall DotNetNuke installation security, and is designed to assist management in identifying an appropriate level of authentication-related risk.

• Download the Multi-Factor Authentication in DotNetNuke Whitepaper
• Learn more about the Multi-Factor Authentication Provider
• Learn more about the DotNetNuke Web Application Framework

The DotNetNuke web application framework offers multiple file persistence options out-of-the-box, including file-system storage (both unsecured and secured by ACL), along with ACL-secured database storage. When creating a link to a resource, the DotNetNuke UI provides a convenient list of these files, and also allows direct input of arbitrary URI.

However, there exists no ready method by which an administrator might link to a known set of files persisted external to the installation. While direct URI input might be used here, it requires knowledge of these data, and does not allow for enumeration and management of the external objects themselves.

This project attempts to bridge that gap by integrating resources persisted on the Amazon S3 into the DotNetNuke framework. Resources stored there are enumerable via the File Manager and selectable via the URL control. Throughout the core framework, these external resources are treated identically to database-secured resources, including observance of Amazon S3 ACL, automatic synchronization, and (reasonably friendly) 301 Redirects to the Amazon S3 when accessed via LinkClick.aspx.

This is effectuated via customization of two providers: authorization and data. The authorization provider integrates Amazon S3 ACLs for external resources, and the data provider allows enumeration of and details about the external resources themselves.

Project Goals

• Integration with the Amazon S3 for data storage external to the DotNetNuke framework.
• Seamless integration into the DotNetNuke UI, both at the File Manager and URL controls. For example:
  • Amazon S3 objects should appear in the File Manager just like any other internal files,
  • Amazon S3 objects should appear in the core URL control, and
  • Insofar as is feasible, Amazon S3 files should be indistinguishable from their secured storage counterparts.
• No external Amazon S3 UI or kludgy link generation
• Whenever possible, utilization of 301 Redirects to Amazon S3 resource URIs.
• Full observance of the external Amazon S3 bucket ACLs.
• Require no core changes and utilize only existing DotNetNuke extension points

Configuration and Usage

After installation, two new profile properties will be automatically created across all portals:

• S3Key, and
• S3Secret

The names of these properties may be changed in the web.config near the configuration/dotnetnuke/permissions node). To enable a portal for Amazon S3 integration, the key and secret for the portal administrator must be configured with valid values.

Any user may submit his or her own key and secret information at the profile level; these data will be used to circumscribe the set of available Amazon S3 objects for that user.

After a portal’s administrator account is configured with a valid Amazon S3 key and secret, the file manager will display those buckets and objects stored on the service:

A screenshot demonstrating Amazon S3 cloud-based integration on the DotNetNuke platform

The list of available buckets will be circumscribed by the permissions granted by the administrator’s S3 account. Because DotNetNuke does not support file-level ACLs, objects within an Amazon S3 bucket are assumed to have an ACL identical to that present on the bucket itself (though a more restrictive policy will still be enforced by the S3 service).

Similarly, the DotNetNuke URL control will display a list of buckets accessible by the accessing user, and allow selection of the objects therein:

Amazon S3 Demonstration Displaying URI Selection

Discussion

Overall Authorization Model

There are a number of areas in which the authorization policy enforced by the provider might be improved. In its current form it is minimally complete, but could easily be made more robust and sensitive to user context (in particular, no attempt is made to deal with Amazon S3 user-specific ACL assignment). The provider is largely aimed at objects intended to be made available to “everyone.”

File-based ACLs

DotNetNuke does not support file-based ACLs, but these are allowed and enforced by the Amazon S3 service.

Generated URIs

The 301 redirect URIs created by the data provider are not per-user, and thereby require read-permission on the “everyone” group for the S3 object in question. A stronger model might generate a valid read URI for the accessing user, so long as that user has read permissions on the object itself.

CRUD

Only read access is implemented for Amazon S3 buckets and objects; while it remains quite straightforward to implement the other access characteristics, these are left to the (many) other S3 managers that exist for these purposes.

Shared secret storage

Shared secrets are stored in plain-text on a user’s profile; this is generally a horrible security policy (Alex Shirley will certainly yell at me for doing this after I strongly discouraged him from doing so in a similar project). Because federated authentication is not possible with the Amazon S3 service, this secret cannot be made application-specific and must be stored somewhere.  The solution here is an encrypted profile property type; this is clearly outside the scope of this project, but is on my radar for a future complimentary project.

Performance

A number of internal operations are O(n*m). While some of these are cached by the underlying DotNetNuke framework, the integration implementation itself could be improved via additional caching and lookup tables.

Your Feedback is Needed!

As this project moves toward an initial production release, it will rely heavily on the feedback provided by the community.  Any such feedback — including comments, ratings, and constructive criticism — is greatly appreciated.

B

However, subsequent to my original posting detailing this approach, I experienced some IPR issues that required my removing the download links to the actual assembly and source code.  While the information in the entry itself was largely sufficient to recreate this adapter, it required a reasonably significant amount of expertise to do so.  As a result, I suspect that many were unable to utilize the material therein.

I am pleased to announce that I have reached resolution on the relevant IPR issues that precluded my releasing the associated code, and have re-enabled the download links in the original post.  For convenience, I am also including them below.

For those not familiar with this project, the introduction from the original entry reads:

“… [T]he UpmMembershipProvider membership provider, … is a part of Microsoft’s Commerce Server 2007 product, and is the only provider that offers interoperability with Commerce Server.  It replaces the older AuthManager functionality from Commerce Server 2002.  More importantly, it provides an implementation of the System.Web.Membership.MembershipProvider class, and may thus be used in any ASP.NET application that utilizes the standard membership system.  Read more about the UpmMembershipProvider inMicrosoft’s MSDN documentation.

DotNetNuke (DNN) is one such application that uses the ASP.NET membership system.  Because I’ve been working so much with it lately, I decided to investigate whether these two strangers might be successfully introduced — and indeed they can.  Google tells me that I am the only person to date who has successfully accomplished this task (not that surprising, given its relatively esoteric nature).

Attachments

• Sample web.config for UpmMembershipAdapter and DotNetNuke
• UpmMembershipProviderAdapter C# Project

B

Among the many improvements present in DotNetNuke version 5.1, this latest release includes authorization as a first-class extension point. This allows customization previously impossible without core modification. Additionally, the permission model (and the internal use thereof) has been significantly streamlined and centralized, allowing for great flexibility across myriad use scenarios.

In this session, we explore the new permission provider in detail. This includes a discussion of how (and why) authorization services were centralized and abstracted, the overall design and structure of the provider, and available points of access control. Finally, we examine some concrete ways in which the provider might be extended to meet real-world policy requirements.

In accordance with some requests I’ve received, I am making the presentation materials available to the public.  These materials are available here: Advanced Authorization in DotNetNuke 5.1.

This presentation included a demonstration detailing how data and authorization provider decoration may be used to integrate the framework with Amazon S3 Services (screenshots of this in action are displayed right).  The code for this demonstration will be made available later this month on its project homepage at CodePlex.

B

Epilogue: The Amazon S3 Integration providers are now available for public consumption.

Among the many improvements present in DotNetNuke version 5.1, this latest release includes authorization as a first-class extension point.  This allows customization previously impossible without core modification.  Additionally, the permission model (and the internal use thereof) has been significantly streamlined and centralized, allowing for great flexibility across myriad use scenarios.

In this session, we explore the new permission provider in detail.  This includes a discussion of how (and why) authorization services were centralized and abstracted, the overall design and structure of the provider, and available points of access control.  Finally, we examine some concrete ways in which the provider might be extended to meet real-world policy requirements.

When presenting architectural or theoretical material, I always strive to include a demonstration of how the material might be applied to a real-world scenario.  In this case, I will be demonstrating how a custom authorization provider can be used to enable full DotNetNuke integration with cloud-based Amazon S3 webservices.  A screenshot of the file manager in an Amazon S3-enabled installation is displayed below.

This session should appeal to a wide audience; I cover enough theoretical background for individuals new to security theory, and delve deep enough into the 5.1 authorization architecture to satisfy those that have high familiarity with the platform.  If you are interested in learning more about the internals of the framework — and how 5.1 authorization might be utilized — be sure to stop by!

Epilogue: The presentation materials are now available here, and the Amazon S3 Integration providers may be found here.

I am pleased to announce the 1.00.00 release of a new templated mega-menu provider. It is based on, and derives its functionality from, the default DNNMenu.

The provider allows for the marking of one or more pages as being templated; during instantiation these templates are dynamically inserted into the page. The templates are highly flexible and may be deployed at the site, skin, or portal level. This allows for great flexibility in user experience.

Goals

• Allow website administrators to select from one or more pre-defined menu templates for any page
• Allow templates to be deployed at the installation, portal, and skin level
• Allow specification of both rendered HTML and CSS file attachment on a per-page basis
• Allow templates to be fully search engine friendly and utilize modern XHTML and CSS design
• Rely on default DNNMenu implementation for all other behavior
• Require no core changes and utilize only existing DotNetNuke extension points

Background

The DotNetNuke content management system is a mature, robust, and widely-adopted web application framework. While the framework allows for the use of myriad menu systems (through the application of the provider pattern), to date there is no way to effectuate per-page templated (”mega”) menus.

This project attempts to bridge that gap by extending the DotNetNuke-default DNNMenu system to render custom templates in place of any node in the menu hierarchy. These templates are easy to create and extend, and allow for a wide variety of final user experiences. Several such templates are included out-of-the-box, demonstrating the flexibility of this provider extension. For maximum flexibility, templates may be deployed by a host across an entire installation, provided as a part of a skinning package, or deployed on a per-portal basis.

What this project is…

This project is a derivative of the popular and DotNetNuke-included DNNMenu system included with the DotNetNuke Webcontrols project. All the functionality present in that menu system may be utilized by using this provider.

What this project is not…

This project is NOT a new menu system for DotNetNuke. It merely extends a small part of the functionality that already exists in the DNNMenu system. Although it is very likely that this method may be used to extend other menu providers (I have already verified this with the Telerik’s RadMenu), it does not yet do so.

If any developer wishes to extend the method used herein to any other popular DotNetNuke navigation provider and would be interested in donating the code to the project, it would be greatly appreciated.

More Information

For more information about this provider, including additional screenshots, please visit the project homepage (http://dnntemplatedmenu.codeplex.com) located on CodePlex.  The software itself is licensed under a liberal New BSD license for wide community utilization.

The provider allows for marking one or more pages as being templated; during instantiation these templates are dynamically inserted into the page.  The templates are highly flexible and may be deployed at the site, skin, or portal level.  This allows for great flexibility in user experience.

The project is hosted on CodePlex and is located here.

By way of example, the default templates available allows styling of the DotNetNuke administrator menu as:

DotNetNuke DNNMenu Templated-Menu Provider Screenshot with Wide Rendering

A screenshot of the prototype DotNetnuke DNNMenu Templated-Menu Navigation Provider

As always, feedback is greatly appreciated!

B

DotNetNuke Multifactor Authentication Requiring Password, One-Time SMS PIN, and X.509 Certificate

I am pleased to announce an initial release of a multi-factor provider for the DotNetNuke content management system.

This authentication provider allows a host to configure enhanced authentication (including SMS, SMTP, YubiKey, and X.509 certificates) for any number and combination of portal roles. Each factor must be fulfilled prior to authentication being granted, increasing overall security.

This package may be downloaded from it’s project site, located at http://dnnmultifactor.codeplex.com.

Goals

• A robust, extensible multi-factor authentication framework for the DotNetNuke content management system.
• Complete integration into the framework using existing extension points, with no core modifications or recompilation required.
• Support for host-, administrator-, and user-level configuration, with the ability to vary required factors across an arbitrary set of roles.
• A robust set of included factor providers, including SMS, secure SMTP, YubiKey (www.yubico.com), and X.509 certificate.
• Extension points in the authentication system allowing for development of custom factors by third parties.
• Reliance on the existing ASP.NET membership subsystem for existing (first-factor) authentication.
• Minimization of “custom security” risk by relying, insofar as is possible, upon existing security infrastructure  ASP.NET membership, DotNetNuke portal security, password generation, et cetera.
• As small an overall surface area as is possible, and an absolute reliance upon the existing ASP.NET membership system as a first-factor fallback, should any unforeseen vulnerability exist.

Background

The DotNetNuke content management system is a mature, robust, and widely-adopted web application framework. It offers role-based authentication and authorization using the ASP.NET membership subsystem, and allows for multiplexing across any number of websites per installation. Read more about DotNetNuke security-related functionality on their website.

DotNetNuke Multifactor Authentication Requiring Password and One-Time SMS PIN

However, DotNetNuke does not offer an out-of-the-box multi-factor authentication story. This is especially unfortunate, especially as the platform is more widely relied upon as a line-of-business portal for enterprise-scale applications such as high-volume e-commerce and banking. These applications, along with the fact that the platform offers cross-website “host” accounts, require a higher-than-normal level of authentication than a simple username/password combination is able to offer.

This project attempts to bridge that gap by extending existing DotNetNuke functionality to offer multi-factor authentication to those roles, users, and hosts configured to require it. Available factors include, in addition to the first-factor ASP.NET membership subsystem (which is always required), SMS, secure SMTP, and X.509 certificate-based authentication. The package is designed to be flexible and easily extended, allowing any arbitrary additional factors to be introduced by third-party developers.

Usage

This authentication extension has been designed for, tested against, and requires DotNetNuke version 5.0.1 or later. Details about core installation and the downloads therefor, are located on the DotNetNuke website.

Installation instructions

1. Download the latest release.
2. Backup all data associated with your installation, including both files and database.
3. Sign in as a host account.
4. The default configuration is designed, for demonstration purposes, to enable a SMTP factor for host accounts. Ensure that your installation has specified valid SMTP settings and that your host account has been configured with an active e-mail account.
5. Install the authentication extension via the Host->Extensions menu option.
6. After installation, visit your site’s login page (after logging out of your host account) to ensure the provider is functioning properly.
7. Configure your web.config to select those factors and roles you wish to augment with additional security (see below).
8. When satisfied with your ultimate configuration, disable the default DotNetNuke authentication system through the Host->Extensions->Default Authentication menu option.

Configuration

The DotNetNuke multi-factor authentication provider currently requires modification to the web.config file when specifying those roles that are to be authenticated with additional factors. This may be changed in the future and effectuated through the settings page.

The default addition to the installation’s web.config file includes a node located at configuration/brandonHaynes. It is here that the factors — and the roles that map thereto — are defined:

<brandonHaynes>
  <authenticationFactors>
    <factor name="Membership" type="BrandonHaynes.Membership.Factors.MembershipFactor..." />
    <factor name="SMTP" text="Enter your one-time password:"
        type="BrandonHaynes.Membership.Factors.SmtpFactor..." />
    <factor name="SMS" appId="3165534" userName="..." password="..."
        text="Enter your one-time password:"
        type="BrandonHaynes.Membership.Factors.SMSFactor..." />
    <factor name="X.509" text="A valid certificate is required to access this account."
        type="BrandonHaynes.Membership.Factors.ClientCertificateFactor..." />
      <factor name="YubiKey" text="Activate your YubiKey now:" id="..." key="..."
        type="BrandonHaynes.Membership.MultifactorMembershipProvider..." />
  </authenticationFactors>
  <authenticationMap>
    <role name="host">
      <factor name="YubiKey" />
    </role>
    <role name="Administrators">
      <factor name="SMS" />
    </role>
  </authenticationMap>
</brandonHaynes>

Here, we have five factors defined  ASP.NET membership, SMTP, SMS, YubiKey, and X.509 certificate) as children of the brandonHaynes/authenticationFactors node. Additional factors may be defined therein.

Under the brandonHaynes/authenticationMap node, we map roles to factors. In the example above, the host role requires a valid YubiKey one-time password and those in an administrator role requires a SMS-dispatched one-time-password. Additional roles and factors may be added (or removed) to enable virtually any configuration. Note that, regardless of configuration, the ASP.NET membership factor is always required.

Factors Included in this Distribution

The following factors are included in this distribution:

• SMS. This factor utilizes the Clickatell SMS gateway for secure one-time password delivery. Factor configuration requires account id and password; this may be encrypted for additional protection (see this for details).
• X.509. This factor utilizes the certificate presented by the client when making an authentication decision. The factor utilizes the built-in ASP.NET subsystem (which, itself, relies upon IIS) in making decisions related to the presence and validity of a client certificate. Assuming both, the certificate subject is compared to a (configurable) user property (by default the username). Alternate profile properties may be used as a basis for comparison by including a profileProperty attribute in the factor definition. For example, to compare a user’s e-mail address, configure the factor as:

    <factor name="X.509" profileProperty="email" text="..."
         type="BrandonHaynes.Membership.Factors.ClientCertificateFactor..." />

• SMTP. This factor utilizes the SMTP server configured for the current DotNetNuke website for transmission of one-time password. Though these settings may be configured to transmit this information securely, in most situations this configuration should not be relied upon for true out-of-band one-time-password transmission (an exception might exist for delivery to a SMS or handheld device external to the authenticating computer system).
• YubiKey. This factor requires activation of a valid YubiKey (www.yubico.com) to authenticate. By default, the factor authenticates againsthttps://api.yubico.com/wsapi/verify, but this may be changed by including a verifyUri attribute on the factor node. Note that by default if no YubiKey is associated with an authenticating account, it will be associated upon first use. Subsequent authentication requires the same YubiKey to be presented. This feature may be deactivated with an associateOnFirstUse=”false” attribute. Note that if automatic association is disabled, accounts requiring YubiKey authentication must be manually associated (by a host). If possible, it is a good idea to disable automatic association after all accounts have associated for the first time.

Custom Factors

This authentication provider is designed to be highly extensible and to allow for additional factors to be added with relative ease. Developers may deploy their own factors by:

• Including a constructor having the prototype of the form:

MyFactor(IDictionary<string, string> attributes);

• Implementing the BrandonHaynes.Membership.IAuthenticationFactor interface, defined as:

public interface IAuthenticationFactor
	{
	string Name { get; }
	void Authenticate(UserInfo user, Credential credential);
	Control PromptControl { get; }
	}

Note that the PromptControl property above is a control that handles the input of whatever additional credential (one-time-password or otherwise) is desired. Three are provided for use in custom development:

1. MessagePrompt (to display a simple message),
2. StringPrompt (to input a one-time-password), and
3. NullPrompt (does not display or require any additional input).

Though any control may be used here, note that because of the way they are instantiated, much of the control life cycle is omitted (in particular ViewState and automatic IPostBackDataHandler handling is not activated). These controls must remain as simple as possible.

Custom SMS Gateways

The SMS factor is designed to be extendable and allow for integration with alternate SMS gateway providers. This may be effectuated by deriving from BrandonHaynes.Membership.SmsFactor and overriding one or more of the following methods:

// Override this method to send a specific one-time password to a telephone 
// number for a particular user using whatever custom SMS gateway is desired.
protected void SendSms(UserInfo user, string telephone, string onetimePassword);

// Override this method to format a given telephone number for transmission to a 
// custom SMS gateway service.  Note that the default implementation is 
// (unfortunately) US-centric and does not perform a robust E.164 formatting (code 
// submissions for this facet would be greatly appreciated!).  
string FormatTelephoneByCountry(UserInfo user, string telephone);

In Case of Emergency…

As with any authentication system, any failure that might occur has a high risk of locking a host out of his or her account. As such, I strongly recommend deploying this package to a staging server prior to production deployment, along with other reasonable precautions.

Should an unrecoverable lockout occur, please note that the default DotNetNuke authentication system may be re-enabled through modification to the dbo.Authentication table of your database. The following SQL will effectuate this (and at the same time disable all other authentication systems that might be available). Use it as an emergency escape.

UPDATE dbo.Authentication
SET IsEnabled =
	CASE WHEN AuthenticationType = 'DNN' THEN 1 ELSE 0 END

Note that you will need to recycle your application pool to realize this change; this may be most easily effectuated by recycling your IIS application pool, restarting IIS, or by making any change to your web.config file (thanks to Mitchel Sellers for pointing out this oversight!).

Feedback Appreciated!

Feedback about your experiences is needed, and greatly appreciated!

To date, a number of people have successfully used these builds in correcting a number of reasonably arcane problems.  As such (and after some delay), I have elected to deploy debug-build version of the core DNN assemblies for the recently-released 4.9.2 and 5.0.1 version.

Please see this entry for downloads and usage patterns for these versions.

Herein I describe with more specificity the use of the adapter generator and the resultant adapters, and announce the release of the first production-ready version of the adapter generator software.

To introduce the use of the IDataReaderAdapter generator, consider a hypothetical software package with a data-layer defined as:

Business-process code interacts with this data logic exclusively through the IDataLayer interface; this not only creates a clean separation of concerns, but also allows for run-time specification of arbitrary IDataLayer implementation (typically a la dependency injection).  This might be concretely implemented as:

For those developers wishing to move to Microsoft’s Entity Framework (EF), this presents a problem.  There is no ready method by which one may convert an EntityObject into an IDataRecord (and, similarly, an IEnumerable<EntityObject> into IDataReader).  Without such a conversion, it is not possible to transition to the EF without breaking the IDataLayer interface contract.  For those applications that are widely deployed (or have strong third-party augmentation), this is a very real problem indeed.

The IDataReaderAdapter generator allows for such a conversion in two ways:

1. Compile-time adaption an EF schema into a set of IDataRecord-implementing wrappers without the use of reflection (and of O(n) property-lookup performance), or
2. Run-time adaption of an EntityObject (or any) object to an IDataRecord-implementing counterpart through the use of reflection.

Note: The adapter generator may be used to adapt any objects into IDataRecord/Reader-implementing objects.  Though the functionality described herein largely deals with the EF, the generator may be applied against any arbitrary object.

Method 1: Compile-Time Adaption of an Entity Framework Schema

To produce IDataRecord/Reader-implementing adapters at compile-time, we execute the adapter generator utility and point it at our EF schema.  The utility is executed in one of two ways, with syntax as:

IDataReaderAdapterGenerator
        /entities:[.NET Entity Framework EDMX file]
        /output:[output class filename]
        [/entities:[entity regex]
        [/language:vb|c#]

IDataReaderAdapterGenerator
        /assembly:[source assembly filename]
        /output:[output class filename]
        [/objects:[entity regex]
        [/language:vb|c#]

• Entities/Assembly: Here, the first parameter may either be an EF Entity Data Model XML (EDMX) file or an arbitrary assembly.  The adapter generator will, assuming the former, parse the EDMX, extract entity objects, and create adapters.  If an assembly is specified, adapters are generated for each publicly-exposed object in that assembly.
• Output: This parameter specifies the output file for the generated adapters (i.e.; “Samples.cs” or “Samples.vb”).
• Entities/Objects: This setting specifies the particular entities or objects that are adapted.  This is specified as a regular expression (to adapt all entities or objects containing the word “Data” one would use the pattern “.*Data.*”).  By default, all available objects are adapted.
• Language: This allows specification of the target language for the generated adapters, either VB.NET or C#.

Method #2: Run-time Adaption of Objects

As an alternative to compile-time generation of IDataRecord/Reader-implementing objects, arbitrary objects may also be adapted at run-time.  Note, however, that this flexibility is achieved at the expense of the additional overhead required for the reflection used during access.  Consider this cost carefully — it is likely that compile-time adaption should be utilized wherever possible.

Utilizing IDataRecord/Reader Adapters

Irrespective of the method selected above, the resultant adapters are used in much the same manner.  By way of example, consider the data model that would result when the concrete DataLayer above were converted to utilize the EF.  This model would likely contain two entities, SomeData and SomeOtherData, and would be structured as follows:

If this EDMX existed in a file named SampleDataModel.edmx, we would adapt the model as:

IDataReaderAdapterGenerator /entities:SampleDataModel.edmx /output:AdaptedSample.cs

And we would implement our modern IDataLayer-implementing layer as:

Note the use of BrandonHaynes.Data.DataReaders.SomeDataDataReader and BrandonHaynes.Data.DataReaders.SomeOtherDataDataReader to adapt returned EntityObjects (context.SomeData and context.SomeOtherData.Where(…)) into IDataReader-implementing interfaces.

To adapt objects at run-time using reflection, we would substitute these per-object adapters with the use of BrandonHaynes.Data.ReflectedDataReaderAdapter (or ReflectedDataRecordAdapter).  This would, for example, read as:

   return new ReflectedDataReaderAdapter(context.SomeData);

Conclusion

Herein we described the command-line use of the IDataReader Adapter generation tool to produce IDataRecord and IDataReader-adapting objects.  These objects may be used to modernize provider-based data layers that heavily rely on these interfaces, without breaking the existing contract. 

The project site, in addition to the source for both generators, includes two samples that should be reviewed by those interested in implementing these techniques in a production environment.  The first includes a sample model similar to that described herein, while the second includes a sample DotNetNuke data provider.  We will revisit this latter sample in subsequent entries as we explore advanced applications of the generated objects.

This entry will be followed by an exploration in more detail of the actual generated IDataReader and IDataRecord-adapting objects, including a review of the actual generated code.  For compile-time generated objects property conversion is performed in O(n) time with the mere addition of a constant-time hash (and lazy-loaded initialization).

As always, comments and feedback are greatly appreciated.

B

Indeed, it would be advantageous to provide adaptation for entities within an EF/LINQ to Entity (L2E) model that was usable in such a legacy system. New code could directly utilize entity classes, while legacy interfaces could function as before. Such a system could be incrementally converted to a full EF implementation. This incremental approach has many practical advantages.

Herein (and over the next few related entries) is described an approach that resolves this shortcoming.  In its current form, it exists as a new layer at the top of the EF stack, as depicted in Figure 1 (right).  This layer is responsible for adapting EF entities to objects that implement the IDataReader¹ interface.

The resultant adapted IDataReaders may be used in any way, include across layers, so long as the underlying entities expose those properties expected by a consumer (including exposure through direct entity relationship).

Accordingly, the primary goals for this project include the following:

• Provide a per-entity adapter for each entity in a model, where each adapter implements the IDataReader and IDataRecord interfaces for use in legacy systems.
• The resultant IDataReaders should be internally strongly-typed and performant (and thereby not use reflection²).
• Model adaptation should be straightforward and easy to update as the model itself changes.
• Adapters should expose all entity properties, including “flattened” properties established through entity relationships (as exposed through conceptual model NavigationProperties).

These objectives are best accomplished through code generation.  This has the attractive characteristics of: compile-time validation, multiple-language targeting, model synchronization on a per-compile basis, performance gains, and strongly-typed code (an advantage given that an entity contains an arbitrary set of unknown properties).

Once adapted, we may construct a function that converts an entity (or set of entities) to an IDataReader-implementing construct, with code of the following general form: 

Over the next few entries, we (i) describe use of the IDataReaderAdapter generation tool, (ii) investigate the generated IDataReader-implementing adapters in more detail, (iii) generate and discuss performance metrics, and (iv) implement a case-study utilization of adapter generation (demonstrating a database-agnostic DotNetNuke hybrid data provider).

This project is available for public evaluation and consumption here³.  It is distributed with a liberal source license for use in production environments. 

For any that find this approach useful, or for those with additional questions, comments, or constructive criticism, I ask that you provide feedback here (or at the CodePlex site).  Your assessments and observations are an important part of any continued development.

B

² For types not known at compile-time, we include a reflection-enabled adapter.  Note that such an adapter may be used to adapt any object, including non-EF entity objects.  This additional flexibility is achieved at the expense of overall performance.

³ Project is expected to go live on or about December 15th, 2008.

As my research on the recently-released Linq to Sql Adapter (currently hosted on CodePlex) wound down, I decided to investigate a new approach to solving the problem.  In my opinion, an optimal solution would fulfill the following requirements:

1. Require no core changes
2. Be side-by-side compatible with the existing DotNetNuke localization services
3. Require little configuration by a hosting user
4. Allow strongly-typed per-portal and per-culture access to existing global DotNetNuke resources
5. Minimal additional in-memory footprint and reasonable performance
6. Enable use of the meta:resourcekey attribute in DotNetNuke modules
7. Be fully compatibility with third-party modules

I am pleased to announce a preview release of a custom BuildProvider that, to my knowledge, accomplishes all of these goals.

For those not familiar with the issue at hand, I strongly recommend reading my previous entry for the relevant background information.  The remainder of this discourse will assume such familiarity.

The previous approach failed in satisfying two of the more important requirements above (specifically (1) and (7) above).  A core change was necessary to keep portal-specific localization files out of the App_GlobalResources directory where ASP.NET would choke during automatic compilation.  This core change caused trouble with pre-compiled third-party modules because of the compile-time linking of publicly exposed constant values.  Clearly unsatisfactory, and clearly a dead-end.

This time around, I elected to utilize a different approach.  This revision includes a  custom BuildProvider which handles the full compilation life cycle for ResX files; in this manner such files may continue to exist in the App_GlobalResources directory and be fully side-by-side compatible with the DotNetNuke localization system.  Further, custom extensions allow portal-specific resource customizations to extend to the ResourceManager (including both strongly- and weakly-typed access).

For example, the strongly-typed variable (enabled via this BuildProvider) Resources.GlobalResources.Error_Text will consistently yield the same value obtained through a DotNetNuke.Services.Localization.Localization.GetString(”Error”, Localization.GlobalResourceFile). 

Similarly, a meta:resourcekey attribute on an appropriately named control will yield the same value obtained through a call to UserModuleBase.GetLocalResourceObject(…).

Configuration

Configuration is straightforward, requiring only a single additional node in the web.config file (highlighted below):

<buildProviders>

<remove extension=".resx" />

  <remove extension=".resources" />

  <add extension=".resx"    

type="BrandonHaynes.DotNetNukeResXBuildProvider.ResXBuildProvider, 

BrandonHaynes.DotNetNukeResXBuildProvider" /> 

</buildProviders>

Here, we keep the existing DotNetNuke <remove> elements and add the new BuildProvider to the list.  During startup, ASP.NET will utilize this BuildProvider to compile all files with the .ResX extension.  This BuildProvider will handle strongly-typed class generation, ResourceManager decoration, and enable full ASP.NET localization within the application.  That’s it!

CodePlex Project

As I gather feedback on the approach, I am initially releasing the BuildProvider project as a beta release.  Please understand that it is preview software, has undergone limited testing, and may break existing installations.  Though I am not currently aware of any outstanding issues, please use caution in a production environment.  Note that any custom BuildProvider, including this one, requires deployment in a Full Trust environment.

The project is available on CodePlex.  Click here to access.  Full source is available.

As I work to confirm that this BuildProvider works properly across a wider variety of installations, I would appreciate any and all feedback about the experiences of those using it.  It is greatly appreciated.

B

* Installation of this module will still require the manual web.config modifications outlined above; at some point I will likely release a 5.0-compatible package that performs this task automatically.

Here I describe the steps necessary to use Linq to Sql within a DotNetNuke module in a reliable, distributable manner.

1. Connect to your DotNetNuke database and add a set of Linq to Sql classes to your project

There exist thousands of tutorials regarding this part of the process.  I suggest starting out with Scott Guthrie’s excellent introduction. 

2. Download the DotNetNuke Linq to Sql Model Adapter

The model adapter is located on the CodePlex project site and may be downloaded here.  The debug and release versions will contain a single assembly (BrandonHaynes.ModelAdapter.dll); copy this library to your project directory and include a reference to it in your project.

A sample module (source and install versions) and additional documentation are also available on the CodePlex site.

3. Update your DataContext to derive from BrandonHaynes.ModelAdapter.DotNetNukeDataContext

To use the adapter, you must change the base class of your DataContext to the specialized DotNetNuke adapter.  This is most easily accomplished by opening your Linq to Sql classes, right-clicking anywhere within the designer area, and selecting “Properties.”

Locate the Base Class line and change to “BrandonHaynes.ModelAdapter.DotNetNukeDataContext”.  Since the adapter will automatically override the connection string specified in your DataContext properties, I suggest leaving the original value therein.  Doing so will cause a parameterless constructor to be automatically generated, preventing you from being required to supplying a useless connection string during instantiation.

4. Compile and Enjoy!

That’s all there is to it.  At runtime, the adapter will automatically detect the existing metamodel constructed by your metasource (by default via attributes on your classes, properties, and members) and adjust them to reflect the DotNetNuke object qualifier and database owner.  No further intervention is required by the developer.

Closing Comments

This project is the result of an informal experiment; having heard that runtime meta-model manipulation was not possible, I wanted to verify and determine if this was indeed the case.  I expect that issues will arise, and would appreciate feedback about implementation experiences.  I am particularly interested in hearing from anyone who is actually successful using this library.  Specific issues should be logged in the CodePlex issue tracker.

B

To rememdy this issue, I have developed an adapter that converts the attributed meta model generated by the designer into a DotNetNuke-compatable model that uses both the object qualifier and database owner specified by an end-installation. 

My goals for any satisfactory solution were as follows:

• Allow run-time adjustment of an attributed MetaModel based on DotNetNuke database owner and object qualifier (no irksome additional meta-schema)
• Continued use of the Visual Studio Linq to Sql designer (no need to support a custom designer)
• No tedious changes in the compiler-generated code
• Continued use of an attributed-meta model (and thereby no external schema deployment files)

It is unfortunate that the object model exposed by Microsoft is so frustratingly difficult to extend.  The Linq to Sql meta-objects are overwhelmingly read-only (and, frustratingly, the AttributedMetaModel subclasses are internal and sealed).  Indeed, it seemed that there was no simple remedy to the problem at hand.

My solution utilizes a two-step approach:

• An AttributedMetaModel is generated based on the attributes automatically created through the designer (Goal 2 and 4). This model is walked to generate an adapted schema (Goals 3).  Walking is reasonably inexpensive, and since the models are cached by type, performance is not affected.
• This schema is transformed into an adapted model, which is cached and returned (Goal 1).  Models are thread-safe; caching is an easy performance improvement.

I use dependency injection to adapt attributed entities (database, table, and function names) into their adapted counterparts. A DotNetNukeAdapter is included for this particular domain. Additional adapters could easily be constructed for other domains, should any arise (to illustrate this point, a NonTransformingAdapter is included in the release, which performs no transformations).

Click here to access the project site for additional details and downloads.  Though the content herein is protected under the license below, be sure to consult the project license (New BSD) for integration-related details.

B

Note

This project is still in an embryotic, beta form.  I have performed limited testing, and have distributed an alpha version to a selected few (thanks especially to Michael Washington for taking a look).  Until satisfactory results have been achieved with a wider audience, I caution against production deployment.  Proceed with caution.

In pre-5.0 versions, despite being persisted to the database like any other page, the admin menu is restricted to one level.  This was a hardcoded limitation; though one could change the verbiage, order, or visibility of the items in the menu, one could not introduce additional levels of organization (without several changes to the core framework).

With DotNetNuke 5.0, however, because administrator pages are treated on-par with any other page on a site, an improvement in organization becomes possible.  Herein I discuss the changes necessary to, in my opinion, improve the overall organization of the DotNetNuke administrator menu.

My goal was to group several of the less-used administrator menu options and place them under a new “Advanced” menu option.  The process for creating this tab was straightforward, with title “Advanced,” the “Disabled” checkbox selected, and “Admin” selected as the parent page.  It was also necessary to specify an icon.

Using the “Pages” tab, I next organized those pages that I felt were rarely used (or had only advanced application).  In my opinion, those pages were in the set { Site Settings, Log Viewer, Security Roles, Vendors, Extensions, and Solutions }.  Naturally, different sites have different requirements, and the list of pages falling into this category might vary.  The “Site Settings” option required particular consideration, but ultimately I felt that since it was only accessed initially that it was safe to tuck away and de-clutter the interface.

My page organization ultimately resulted in the following hierarchy*:

* Astute readers will note that the “Site Wizard” option has been removed.  I generally prefer to remove this option after a customer has initialized his or her site.

These changes resulted in an administrator menu that is, in my opinion, significantly more streamlined, intuitive, and user-friendly:

Addendum

I encountered one difficulty with this process of which readers should be aware.  When organizing the page hierarchy, I initially visited page settings and explicitly set the new page parent from the dropdown list.  However, this caused the icon to disappear.  Because the icons for administrator pages are located outside the portal directory (specifically, in “/images”), it became impossible to restore these icons.

This behavior does not appear to manifest when using the arrow links on the “Pages” tab (image above).  Therefore, until this behavior is corrected (or declared by design), I strongly suggest using this method as your exclusive means by which to organize the administrator hierarchy.

For those interested, the work item for this issue is located here.

B

Fortunately, it does turn out to be possible.

Firing up the IE developer toolbar, I immediately noted that (a) parameter controls were rendered outside the document hierarchy (in this case at the end of the FORM), (b) there was no class specified anywhere within the internal ReportViewer tag hierarchy, and (c) styles were hard-coded directly on the DIV tag which held the drop-down list (implemented as a TABLE).  Indeed, the width attribute on this DIV was hard-coded at 184px.  By default, the parameters dropdown appears as:

Fortunately, while there was no specific class to hang a custom width from, it turns out that the id of this DIV was reliably predictable.  As such, a judiciously constructed style could indeed target (and thereby style) this tag.

The form of the id on the DIV in question is [Viewer ClientId]_ctl00_ctl03_divDropDown.  Here, ctl00 is the automatically-generated id of the Microsoft.Reporting.WebForms.ParametersArea control, and ctl03 is the id of the Microsoft.Reporting.WebForms.MultiValueValidValuesControl.

Putting this together, an initial style would read as:

<style type=”text/css”>
     DIV#<%= Viewer.ClientID %>_ctl00_ctl03_divDropDown
          {
          width: 320px !important;
          }
</style>

<rsweb:ReportViewer ID=”Viewer” runat=”server” Width=”100%” Height=”600px” ProcessingMode=”Remote” />

Here we use the ClientID the ReportViewer (and its constituent ctl00 and ctl03 child and grandchild, respectively).  We also use an “!important” declaration to override the inline styling.  After our style is applied, the ReportViewer dropdown may be set to any size.

Note that it would be of better form to create a custom function that recurses the ReportViewer control hierarchy to locate the divDropDown control (and use its ClientID).  This would make the solution a bit more forward-looking and upgrade-friendly.  I leave this as an exercise to the reader (there are plenty of tutorials out there about recursing the control tree).

Hope this helps anyone needing to resize this particular control.

B

To date, a number of people have successfully used these builds in correcting a number of relatively arcane problems.  As such, I have elected to deploy debug-build version of the core DNN assemblies for the recently-released 4.9 version.

As before:

THIS SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Also, DotNetNuke Corporation requires that I receive consent to the following licence as a precondition to use of its software.  Downloading any of the assemblies provided below indicates binding consent to these term:

DotNetNuke is provided free, as open-source software, and licensed under a BSD-style agreement.  The licensing agreement reads as follows: 

DotNetNuke® – http://www.dotnetnuke.com
Copyright (C) 2002-2008
by DotNetNuke Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

For instructions in the use of the following assemblies, please see this entry.

Debug-build assemblies:

• DotNetNuke.dll (4.9)
• DotNetNuke.HttpModules.dll (4.9)

B

Since my existing PageFlow navigation provider-related modifications became obsolete with this change, I thought I’d spend a few minutes porting my changes to the new block.  I actually completed this task a couple of months ago, but have just now found the time to post it publicly.  Thanks to those who persevered in prodding me to put it online!

WCSF Changes

The web.config setting is identical to the original setting, marked up as:

<pageFlowProvider providerType="WCSFContrib.PageFlow.Xml.XmlPageFlowProvider, WCSFContrib.PageFlow.Xml" navigationType="[Fully Qualified Assembly Name]" />

This change is picked up through an addition to Configuration/PageFlowProviderSection.cs, as:

        /// <summary>
        /// Defines the concrete type of the INavigator.
        /// </summary>
        [ConfigurationProperty("navigationType", DefaultValue = "WCSFContrib.PageFlow.Services.NavigationService", IsRequired = false)]
        public string NavigationType
            {
            get { return (string)base["navigationType"]; }
            }

Next, the BuildProvider method of PageFlowDirectory (PageFlowDirectory.cs) must be augmented to pick up the specified provider and load it (changes in bold):

        private static IPageFlowProvider BuildProvider()
        {
            PageFlowProviderSection configSection =
                (PageFlowProviderSection) ConfigurationManager.GetSection("pageFlow/pageFlowProvider");
            PageFlowInstanceStoreProviderSection storeSection =
                (PageFlowInstanceStoreProviderSection) ConfigurationManager.GetSection("pageFlow/pageFlowInstanceStoreProvider");
            PageFlowInstanceCorrelationTokenProviderSection tokenProviderSection =
                (PageFlowInstanceCorrelationTokenProviderSection)ConfigurationManager.GetSection("pageFlow/pageFlowInstanceCorrelationTokenProvider");
            Type providerType = Type.GetType(configSection.ProviderType);
            Type navigationType = Type.GetType(configSection.NavigationType);

            if (navigationType == null)
                throw new InvalidOperationException("Invalid navigationType specified: " + configSection.NavigationType);

            Services.INavigationService navigationService = (Services.INavigationService)Activator.CreateInstance(navigationType);
            _provider = (IPageFlowProvider)Activator.CreateInstance(providerType,
                                                                    BindingFlags.CreateInstance,
                                                                    null,
                                                                    new object[] { navigationService, storeSection, tokenProviderSection },
                                                                    CultureInfo.CurrentCulture);
            return _provider;
        }

Finally, each concrete provider must be modified to accept the appropriate navigationService as a constructor parameter. In the case of the XmlPageFlowProvider, this would result in the following changes (highlighted in bold):

        public XmlPageFlowProvider(INavigationService navigationService, ...)
        {
            if (pageFlowInstanceStoreProviderSection == null)
                throw new ArgumentNullException("pageFlowInstanceStoreProviderSection");

            if (pageFlowCorrelationTokenProviderSection == null)
                throw new ArgumentNullException("pageFlowCorrelationTokenProviderSection");

            IDictionary<string, NavigationGraph> navigationGraphs = new WebConfigStore().GetXmlPageFlowNavigationGraphs();

            _pageFlowFactory = new XmlPageFlowFactory(navigationGraphs, navigationService);
            //_pageFlowFactory = new XmlPageFlowFactory(navigationGraphs, new NavigationService());

            Type tokenProviderType = Type.GetType(pageFlowCorrelationTokenProviderSection.ProviderType, true, true);
            IPageFlowCorrelationTokenProvider _tokenProvider =
                (IPageFlowCorrelationTokenProvider)Activator.CreateInstance(tokenProviderType);

            Type storeType = Type.GetType(pageFlowInstanceStoreProviderSection.ProviderType, true, true);
            _store =
                (IPageFlowInstanceStore)Activator.CreateInstance(storeType, BindingFlags.CreateInstance, null,
                                                                  new object[]
                                                                      {
                                                                          pageFlowInstanceStoreProviderSection.ConnectionStringName,
                                                                        _tokenProvider
                                                                      },
                                                                  CultureInfo.CurrentCulture);
            PopulateDirectory(navigationGraphs);
         }

As a footnote, I did consider modifying the NavigationService directly to instantiate and decorate an underlying custom NavigationProvider. While this might have resulted in one less code change, I do not feel that it is of optimal design. Concrete PageFlow providers should not be responsible for instantiation of their navigationProviders; these objects should be injected, for maximum flexibility. 

Downloads

• WCSFContrib.PageFlow.DLL and WCSFContrib.PageFlow.Xml.DLL
• WCSFContrib.PageFlow and WCSFContrib.PageFlow.Xml Source (Modified files only!)

For the complete (pre-modification) package, visit the project homepage at http://www.codeplex.com/wcsfcontrib.  For those keeping score, I’ve created a work item for this change here.

Coming Soon: Using the PageFlow Application Block within DotNetNuke

The WCSF PageFlow package continues to be an excellent application block.  It is a shame that it continues to be so ASPX-centric.  The modifications herein are a first step toward removing this limitation and allowing it to be used in more flexible circumstances, such as an ASCX-based state machine or within the DNN framework.

For anyone who is interested, I am now using this application block successfully (soon to be in production) within the DotNetNuke framework, using:

• The block-level modifications outlined above
• A custom navigation service (currently SelfRedirectingNavigationService, though, as I will blog about sometime soon, I have some enhancements in store in this area)
• A web.config-defined XmlPageFlow provider state machine
• A module shell with some custom wire-up code
• One ASCX control for each state in the XmlPageFlow state machine

I will continue to blog about this topic, most likely addressing a concrete navigation service that may be used with DNN next.  Stay tuned!

B

Instructions for using debug assemblies

1. Back up your entire DotNetNuke installation, including ALL files and databases.  You will especially need copies of your core production assemblies, because they will need to be restored after debugging is complete.  I recommend executing these steps on a non-production machine.
2. By downloading any files from this site, you must agree to the following (in addition to any subsequent licensing agreements below):

THIS SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

1. Download relevant files below, and copy them into the bin directory of your DotNetNuke installation (i.e.; if you are having trouble with httpModule functionality, you need only to download DotNetNuke.HttpModules.dll).
2. Navigate to your DotNetNuke site, and reproduce the error.
3. Locate the relevant exception in your event viewer (while logged in as an Administrator, select Admin->Event Viewer and click on the most recent exception).
4. Ensure that you’re actually generating a call stack with filenames and line numbers (see below: How do I know if it worked?)
5. Copy and paste this exception, along with background information, into your request for help on the DotNetNuke forums.
6. Restore your backed-up assemblies over the assemblies you downloaded here.  This is important — debug builds are significantly slower than their production counterparts.  You may optionally choose to remove the .pdb files; they are not required for release functionality, and are ignored.
7. Navigate to your website and ensure continued functionality.

Downloads

DotNetNuke licensing guidelines require that I provide the following verbiage.  Note that downloading any of the assemblies provided below indicates binding consent to these terms. 

DotNetNuke is provided free, as open-source software, and licensed under a BSD-style agreement.  The licensing agreement reads as follows: 

DotNetNuke® - http://www.dotnetnuke.com
Copyright (C) 2002-2008
by DotNetNuke Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Debug-build assemblies:

• DotNetNuke.dll (5.0.1)
• DotNetNuke.HttpModules.dll (5.0.1)
• DotNetNuke.dll (4.9.2)
• DotNetNuke.HttpModules.dll (4.9.2)
• DotNetNuke.dll(4.9)
• DotNetNuke.HttpModules.dll (4.9)
• DotNetNuke.dll (4.8.4)
• DotNetNuke.HttpModules.dll (4.8.4)

How do I know if it worked?

Call stacks involving assemblies with debug information will read similar to the following:

System.Net.Mail.SmtpException: The operation has timed out. at System.Net.Mail.SmtpClient.Send(MailMessage message) at DotNetNuke.Services.Mail.Mail.SendMail(String MailFrom, String MailTo, String Cc, String Bcc, String ReplyTo, MailPriority Priority, String Subject, MailFormat BodyFormat, Encoding BodyEncoding, String Body, String[] Attachment, String SMTPServer, String SMTPAuthentication, String SMTPUsername, String SMTPPassword, Boolean SMTPEnableSSL) in C:\…\DotNetNuke\Library\Components\Mail\Mail.vb:line 315

Note that the filename(s) and line number(s) (highlighted above) are present in the call stack.  This additional information is what you are looking to provide to those assisting.

Final Words

I have tested this procedure on a local DotNetNuke deployment, and it appears to work correctly.  However, I would appreciate feedback from those using this method in the wild, and especially how I might clarify the instructions to be more accessible to less experienced users and developers.

I hope this helps those out there with difficult-to-diagnose DotNetNuke issues!

B

I’m getting a very vague general exception error, and I’m not sure what is causing it.  There doesn’t seem to be anything visible in the application . . . [and] no errors as I’m navigating the site. Any and all help is greatly appreciated!

StackTrace: [NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.UI.Skins.SkinDefaults..ctor(SkinDefaultType DefaultType) +189
   DotNetNuke .Common.Globals.get_DefaultSkin() +31
   DotNetNuke.Entities.Portals.PortalSettings.GetPortalSettings(Int32 TabId, PortalAliasInfo objPortalAliasInfo) +2797
   DotNetNuke.Entities.Portals.PortalSettings..ctor(Int32 tabId, PortalAliasInfo objPortalAliasInfo) +82
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +3303
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Experienced DNN developers will recognize the general area in which the error is occurring (missing skinningDefaults in DotNetNuke.config) and probably some general guidance to rectify the error (check that DotNetNuke.config exists, and correctly contains the proper skinningDefaults element).

This is fine for exceptions that occur frequently, but how does an experienced developer guide a novice in finding a solution to this issue?

[NullReferenceException: Object reference not set to an instance of an object.]
   DotNetNuke.HttpModules.UrlRewriteModule.RewriteUrl(HttpApplication app) +378
   DotNetNuke.HttpModules.UrlRewriteModule.OnBeginRequest(Object s, EventArgs e) +1180
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +92
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +64

Even a sophisticated developer would need to explore several avenues in finding a solution.  Assisting a relatively novice forum user in performing these tasks is problematic — such assistance would require a number of back-and-forth exchanges.  With regret, I unfortunately observe many problems go unremedied for this reason (as, to date, is the exception posted immediately above).

A Better Way to Debug

Clearly, for difficult-to-diagnose problems, a call stack is not sufficient to identify a solution.  Fortunately, there is a relatively easy way to augment this stack with information that greatly aids in diagnosis — assemblies with debugging symbols.  A debug build provides line numbers that may be used to target with much greater accuracy the particular problem that a user is experiencing. 

For a non-developer experiencing a difficult problem, he or she could replace existing production-build assemblies with their debug-symbol counterparts, reproduce the error, and post the augmented call stack for analysis.  I argue that this would (a) significantly increase error resolution, and (b) decrease debug time per issue for both assistor and assistee.

Unfortunately, at this time the DNN team seems to have little interest in providing such assemblies to the public at large (arguing that users can build these themselves).  I respectfully disagree, and would suggest that most capable of producing such assemblies would not need the additional forum assistance that such the debug builds would allow.

Fortunately, the DotNetNuke license allows me to both recompile core assemblies with debug symbols, and to publish these builds to the general public.  I intend to do so, and thereby (hopefully) aid others in solving some of the more difficult problems encountered in the wild.

To this end, my next entry will contain major DotNetNuke assemblies with debugging symbols.  I decided to split off the deployment instructions and downloads into a separate post so that downloading users can skip the preamble and get straight to the instructions and downloads.

For those who have feedback regarding the philosophy and feasibility of this approach, I’d appreciate both.

B

DotNetNuke (DNN) is one such application that uses the ASP.NET membership system.  Because I’ve been working so much with it lately, I decided to investigate whether these two strangers might be successfully introduced — and indeed they can.  Google tells me that I am the only person to date who has successfully accomplished this task (not that surprising, given its relatively esoteric nature).

It turns out that this integration consists of three tasks: (1) configuring Commerce Server appropriately, (2) the routine tasks that one would expect in using the new provider, (3) and a small integration gotcha.  Herein I address these in order.

Configuring Commerce Server

Commerce Server uses the GeneralInfo.email_address value of the UserObject profile object by default for authentication.  This is great, except that DotNetNuke uses a generic login name during registration.  While it’s possible to configure DNN to use e-mail addresses throughout its registration system, that’s a topic for a later date and beyond the scope of the task at hand.

We are thus forced to move Commerce Server away from e-mail addresses in favor of a more generic login name.  If you haven’t already configured your Commerce Server installation to use such a login name, you’ll need to do so.  Amy describes this process in her newsgroup post here.  Thanks Amy!

Web.Config Integration

Most developers will know that the first task in installing a new provider is updating the application’s web.config file with details about the provider.  Accordingly, we add the following to our web.config:

        <membership defaultProvider="UpmMembershipProviderAdapter"
                    userIsOnlineTimeWindow="15">
            <providers>
                <clear/>
                <add name="UpmMembershipProviderAdapter"
                     enablePasswordReset="true"
                     logonNameProperty="GeneralInfo.login_name"
                     enableCreateDate="true"
                     enableEmailAddress="true"
                     enableLastLoginDate="true"
                     profileDefinition="UserObject"
                     requiresApproval="true"
                     minRequiredPasswordLength="5"
                     minRequiredNonalphanumericCharacters="0"
                     maxInvalidPasswordAttempts="5"
                     passwordAttemptWindows="15"
                     passwordLockoutPeriod="10"
                    type="BrandonHaynes.Membership.UpmMembershipProviderAdapter"/>
            </providers>
        </membership>

Two comments about this entry:

1. Most attributes are straightforward and default here, including: enablePasswordReset, loginNameProperty, enableCreateDate, enableEmailAddress, enableLastLoginDate, profileDefinition.  Note that the UpmMembershipProvider does not support many of the attributes available in the AspNetSqlMembershipProvider; see the MSDN documentation for more details.  This can be a source of frustration, as the provider does not complain when an unsupported attribute is supplied.
2. I did not directly use the UpmMembershipProvider class located in the Microsoft.CommerceServer.Runtime assembly.  The reason for this is discussed below as a gotcha.

Additionally, you’ll need to copy over all the required Commerce Server files to your DNN installation.  These can come from the StarterSite or CSharpSite (obviously this choice will impact your mappings, and any production application will likely have customized these files).  These files include:

• All files in the pipelines subdirectory
• bin/CommerceMessageManager.dll,
• The de-DE, EN, en-us, fr-fr, and ja-JP subdirectories of the bin folder.
• OrderObjectMappings.xml
• OrderPipelineMappings.xml
• csapp.ini

Naturally, the default DotNetNuke web.config must have the required Commerce Server sections added.  This includes {sectionGroup[@name = 'CommerceServer'], compilation/assemblies, system.web/httpModules, and  CommerceServer} elements.  Look to the Commerce Server SDK StarterSite for a model web.config, or use the one that I provide below.

That’s it with the trivial part.  Not so bad at all!

Adapting the Provider

As mentioned above, the UpmMembershipProvider does not support some of the configuration properties available in its MembershipProvider base class, and throws a NotSupportedException when any of these methods/properties are called.  Unfortunately, DotNetNuke makes calls to one of these unsupported properties — PasswordQuestion — regardless of the provider configuration.  Without modifying the core, there is no way to declaratively remedy this problem.

Because of this issue, we are forced to decorate the UpmMembershipUser object so that it does not throw, and adapt the UpmMembershipProvider such that it returns our newly decorated user objects.

Decorating the UpmMembershipUser

Our decoration is very straightforward and by-the-book:

    class UpmMembershipUserAdapterDecorator : MembershipUser
        {
        private MembershipUser decoratedMembershipUser;

        internal UpmMembershipUserAdapterDecorator(MembershipUser decoratedMembershipUser)
            {
            this.decoratedMembershipUser = decoratedMembershipUser;
            }

        internal MembershipUser DecoratedMembershipUser
            {
            get { return decoratedMembershipUser; }
            }

        #region Decorated Overrides

        public override string PasswordQuestion
            {
            get
                {
                if (System.Web.Security.Membership.Providers[decoratedMembershipUser.ProviderName].RequiresQuestionAndAnswer)
                    return decoratedMembershipUser.PasswordQuestion;
                else
                    return null;
                }
            }
        #endregion

        #region Delegated Overrides ...
        }

Here we decorate the PasswordQuestion property such that it relies on base implementation when RequiresQuestionAndAnswer is activated in the web.config, and null if it is unsupported (instead of throwing).  The “Delegated Overrides” region implements the rest of the MembershipUser methods, passing the call to the decorated MembershipUser as per the pattern.

Adapting the UpmMembershipProvider

Next, we adapt the UpmMembershipProvider class so that it returns DecoratedMembershipUsers (instead of UpmMembershpUsers):

    public class UpmMembershipProviderAdapter : UpmMembershipProvider
        {
        public UpmMembershipProviderAdapter() : base() { }

        #region Overridden Functions

        public override MembershipUser CreateUser(string username, string password,
        string email, string passwordQuestion, string passwordAnswer, bool isApproved,
        object providerUserKey, out MembershipCreateStatus status)
            {
            return DecorateUser(base.CreateUser(username, password, email,
                 passwordQuestion, passwordAnswer, isApproved, providerUserKey,
                out status));
            }

        public override MembershipUser GetUser(object providerUserKey, bool userIsOnline)
            {
            return DecorateUser(base.GetUser(providerUserKey, userIsOnline));
            }

        public override MembershipUser GetUser(string username, bool userIsOnline)
            {
            return DecorateUser(base.GetUser(username, userIsOnline));
            }

        public override void UpdateUser(MembershipUser user)
            {
            base.UpdateUser(ExtractDecoratedUser(user));
            }
        #endregion

        #region Private Functions

        private static MembershipUser DecorateUser(MembershipUser decoratedUser)
            {
            if (decoratedUser != null)
                decoratedUser =
                new UpmMembershipUserAdapterDecorator(decoratedUser);

            return decoratedUser;
            }

        private static MembershipUser ExtractDecoratedUser(MembershipUser user)
            {
            UpmMembershipUserAdapterDecorator decoratedUser =
                user as UpmMembershipUserAdapterDecorator;

            if (decoratedUser != null)
                user = decoratedUser.DecoratedMembershipUser;

            return user;
            }

        #endregion
        }

This adaptation is also very straightforward.  The methods that return MembershipUsers (CreateUser, GetUser, UpdateUser) decorate the UpmMembershipUser returned by the base implementation.  Note that I included a private ExtractDecoratedUser helper function to aid in debugging, but as it is not called internally it may be safely omitted at a developer’s discretion.

Closing Comments

Despite a few configuration hassles, coaxing the UpmMembershipProvider to play nicely with DotNetNuke was surprisingly easy.  I’ve made the relevant files available as a download for anyone desiring to duplicate this integration.

I’d appreciate feedback and comments (and of course questions!) for anyone who chooses to duplicate my efforts.  Good luck!

B

Attachments

• Integration Sample web.config for UpmMembershipAdapter and DotNetNuke
• UpmMembershipProviderAdapter C# Project

DotNetNuke provided rich localization support (in the DotNetNuke.Services.Localization namespace) long before ASP.NET caught up in version 2.0. Indeed, the core DotNetNuke libraries and UI continue to heavily rely upon this custom implementation to this day.

However, after ASP.NET 2.0 was released, there were apparently a number of issues revolving around the new localization, backwards compatibility, and the existing DotNetNuke localization. As a result, the core team chose to disable all ASP.NET 2.0 localization at the application level and to rely exclusively upon its internal implementation. This is unfortunate, but understandable — the core team has a lot of audiences, and must balance the act of pleasing them all.

DotNetNuke localization is excellent, and for almost every scenario, I strongly recommend using this API.  However, there do exist some niche circumstances that lend toward using ASP.NET 2.0 localization.
Fortunately, with a few small changes, it is possible to restore limited ASP.NET 2.0 functionality to your DotNetNuke installation. Herein I discuss these changes and their system-wide impact.

Before I begin, all the usual warnings apply: back up your data, attempt this only on a development machine, thoroughly test before entering production, et cetera, et cetera. Caveat lector!

With that, let’s get started.

Restore .resx compilation

DotNetNuke disables ASP.NET 2.0 localization by explicitly removing .resx and .resources from the set of custom buildProviders. This is accomplished in the web.config as follows:

<buildProviders> <remove extension=”.resx”/> <remove extension=”.resources”/> </buildProviders>

Perhaps obviously, we’ll first need to re-enable .resx compilation by deleting “<remove extension=”.resx”/>”.

Warning: Because DotNetNuke uses the .resources extension for a number of other purposes (including to prevent IIS from serving sensitive files), I neither recommend enabling this extension, nor have performed ANY testing with regards to files having this extension. I strongly suggest leaving it alone.

Dealing with Portal-Specific Resources in App_GlobalResources

Once the .resx extension has been re-enabled, ASP.NET will begin compiling existing .resx resource files. However, this will cause a problem for those resources that have been localized for a specific portal. DotNetNuke creates these files with a [FileName].Portal-[PortalId].resx format (e.g. “SharedResources.Portal-0.resx”). When the ASP.NET resource compiler attempts to compile these files, it will generate an error. This is because ASP.NET expects the “Portal-[PortalId]” token to be a valid language (e.g. en-US). Obviously, “Portal-[PortalId]” is not a valid language, and the resource compiler chokes with: “CS0101: The namespace ‘Resources’ already contains a definition for ‘SharedResources’”

If you never expect to localize any of your resources (never!), then you will not encounter this situation, and may skip this step.

Otherwise, we are thus forced to prevent the ASP.NET resource compiler from compiling these files. Although I am not fully happy with this solution, to date the best method that I have found to accomplish this is to rename the App_GlobalResources directory.

This requires two changes:

1) Rename your App_GlobalResources directory to GlobalResources.

2) Update the DotNetNuke core to look in the new GlobalResources directory. This value is set on or about line 73 of Library/Components/Localization/Localization.vb:

Public Const ApplicationResourceDirectory As String = “~/App_GlobalResources”

Changed to:

Public Const ApplicationResourceDirectory As String = “~/GlobalResources”

I have requested that this value be settable via external configuration so that a core compilation is not required, but this is yet unimplemented.

Restore resheaders and schema to invalid DotNetNuke resource files.

 ASP.NET 2.0 localization requires a valid set of resheaders and schema for its resource files. Since DotNetNuke treats .resx files as simple xml files, it does not need this additional information. As a result, some language pack designers have intentionally omitted these data. DotNetNuke itself provides ASP.NET 2.0 localization-friendly .resx files for the most part, but there are random and frustrating omissions.

You’ll know you’ve encountered one of these problematic .resx files when a page fails with the following exception: DotNetNuke.Services.Exceptions.ModuleLoadException: ResX input is not valid. Cannot find valid “resheader” tags for the ResX reader and writer type names. Note that that since ASP.NET 2.0 compiles all resources in App_LocalResources at once, the problem could be in ANY of the files, not just the one being accessed.

Unfortunately, these values must be manually added to those ASP.NET 2.0-invalid .resx files. Admin/Host/App_LocalResources/Solutions.ascx.resx is a continual culprit. Open with any text editor and paste the following schema and resheaders under the element:

<resheader name=”resmimetype”> <value>text/microsoft-resx</value> </resheader> <resheader name=”version”> <value>2.0</value> </resheader> <resheader name=”reader”> <value>System.Resources.ResXResourceReader, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089<value> </resheader> <resheader name=”writer”> <value>System.Resources.ResXResourceWriter, System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</value> </resheader>

Note: After publishing, I discovered that only the resheaders are required; the schema remains optional.  For those that wish to include schema, I will include it as a comment below.

Once you save the resource file with the expected data, the exception should go away. I have requested that these data be added to all standard DotNetNuke resources files, but the core team has disagreed with me. Charles Nurse indicated that:

…We have for historical reasons used the resx language files as standard xml files. This is how they are processed – in fact the resx file extension is eplicitly disabled from the BuildManager in web.config.

While the schema is added automatically to the resx files by the resource editor in Visual Studio, it is our intention to remove the headers as they affect performance in our implementation.

The fact that you have decided to compile those resources in your modules means that your requirements conflict with the core requirements. We cannot address this.

He has an excellent point, and though my requirements do differ, I completely agree with his conclusion. Read the full details here.

Compile and Enjoy

These changes will allow you to use ASP.NET 2.0 localization at the App_LocalResources level – including .ascx syntax (via the <%$ %>or meta:resourcekey methods) and by code (via the strongly-typed Resources object, or by a GetLocalResourceObject call.

GlobalResources should also be accessible, provided a new App_GlobalResources directory is created and resources are placed within. However, the DotNetNuke GlobalResources and SharedResources values will need to be accessed via the DotNetNuke localization API (as they probably should be).

If anyone actually chooses to go this route and implement the changes I’ve outlined above, I’d appreciate feedback and information about any problems encountered. Eventually I’m sure that DotNetNuke will move to support ASP.NET 2.0 localization, and this is a good step in that direction!

B

1. The installer created a CRM website, but failed to configure it as an application. I have a very specific server configuration, so this may have caused the problem. Nonetheless, I had to visit IIS and configure my CRM website as its own application and enable Windows Authentication. I believe it was also necessary to configure default.aspx as a default document as well.
2. It was a requirement that the system be exposed via a single SSL port, and this caused some headaches. Obviously, I had to configure the SSL port in IIS. Because this port was different than the non-SSL port configured at installation, there were some registry and database changes required. Specifically:
   1. Under HKLM\Software\Microsoft\MSCRM, the ServerUrl key needs to be updated.
   2. In the DeploymentProperties table of the MSCRM_CONFIG database, the rows with ColumnName in {’AsyncSdkRootDomain’, ‘ADSdkRootDomain’, ‘ADWebApplicationRootDomain’, and ‘ADRootDomainScheme’} need to be updated. The column to update is NVarCharColumn. Value is of the format ’server:port’ (e.g.; ‘microsoft.com:5556′). If running under SSL, you’ll need to update the last key, ADRootDomainScheme, to ‘https’ (also using the NVarCharColumn column).
3. Once I had executed the above changes, the client tool still complained about being able to connect to the server. Using Fiddler, I was able to determine that there was an authentication problem. Modifying the registry keys under HKCU\Software\Microsoft\MSCRMClient did the trick. Apparently the organization was appended to the web application directories, which resulted in a 404 upon connection. I modified WebAppUrl and IntranetServerUrl, but I recommend reviewing all the keys.
4. Apparently the client requires anonymous access to be enabled on the _imgs subdirectory of the CRM installation. This corrected my final authentication issue. Thanks to the poster here for this solution.
5. Finally, after the client installed and connected properly, I received an error when loading outlook which read “An error occurred loading Microsoft Dynamics CRM functionality.” This was apparently due to a conflict between an old 3.0 installation and the 4.0 software. 3.0 failed to fully clean up after itself. Manually removing the duplicate CRM menu did the trick; I used View->Toolbars->Customize, right clicked on the depreciated 3.0 menu, and selected Delete. Restarted Outlook and I was up and running.

That’s a lot of work to get things up and running, but FAR less of a hassle than I experienced in tinkering with the 3.0 version.

B

So, instead of kludging and compiling my own custom PageFlow libraries, I decided to modify the framework itself and allow customization of the INavigationService at the web.config level.  Required only a small number of code changes, and ultimately the navigation service interface is configured as:

I created a work item in the WSCF project which discusses my changes in a little more detail.  It essentially boiled down to adding a new string attribute (NavigationType) to the provider section class (defaulting to the existing Microsoft.Practices.PageFlow.Services.NavigationService), modifying the BuildProvider method to use this configuration value, and adding the extra parameter to the provider constructor.

Work item is located here.
Patch is located here.

Hope this helps anyone who needs a custom navigation service for the PageFlow block in the WCSF.  I’ll be continuing to blog about my attempts to integrate this block into a DNN module and  have it play nicely with the DNN framework.

B