From the Desk of Brandon Haynes

Editor’s note: This approach has been obsoleted in favor of the more straightforward, core-friendly ASP.NET 2.0 Localization approach outlined here.

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. (more…)

In installing Microsoft Dynamics CRM 4.0, I ran across a couple of installation issues. These were mostly circumventable, but I thought I’d aggregate them here in case anyone out there has similar problems:

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

I was dismayed to discover that one could not configure a custom INavigationService at the web.config level.  As part of my experiments to integrate PageFlow into a DotNetNuke module, I needed such customization, and wanted to continue to configure the providers in the web.config.

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