Code Authority recently published a customized website template on the DotNetNuke platform for one of our customers who was already using MailEnable WebMail on their existing web site.

After launching the site we discovered the virtual directory /MEWebmail failed with the following error.

File or assembly name DotNetNuke, or one of its dependencies, was not found

            Additionally The offending assembly was:

            “DotNetNuke.HttpModules.UrlRewrite”.

Clearly the two applications were not playing nice together. I quickly identified that several custom HttpModules found in the DNN web.config file were not compatible with MailEnable Webmail, because the DLLs for these modules were not in the /bin folder of the /MEWebMail virtual directory root location.

I wanted to avoid just copying these files into the folder, so that during future MailEnable upgrades I would not have inter-application dependencies. I found a few other postings on the Internet by people with similar problems and goals, and also the MSDN web.config reference documentation.

One such article authored by Tom Lucas implied my perfect solution was inherently part of the design of web.config. Beware, the article example has a typo, because web.config is case sensitive and the author apparently forgot that before publishing his sample code.

However I found that in order for the web.config tags or to work the DLLs still had to reside in the bin folder of the sub application (“/mewebmail” in this case). In another article, author K.Scott Allen and visitors discuss this “catch 22” in more depth.

I then found more information indicating that the tag’s dependency on the file existing has been removed in the .NET Framework 2.0, but that it was an inherent flaw in .NET 1.1. So the only solution for now, while the MailEnable webmail application is a .NET 1.1 application,  is to define a new physical folder in which a copy of the web application code for MailEnable will be placed, and modified to include the DotNetNuke httpModule DLLS. I am optimistic this won’t be necessary once the MailEnable web application is upgraded to .NET 2.0.

If you are implementing this solution, copy the following DLLs from the DNN /bin subfolder to the special “DotNetNuke” compatible copy of MailEnable webmail source /bin subdirectory.

DotNetNuke.HttpModules.DNNMembership.dll

DotNetNuke.HttpModules.Exception.dll

DotNetNuke.HttpModules.Personalization.dll

DotNetNuke.HttpModules.UrlRewrite.dll

DotNetNuke.HttpModules.UsersOnline.dll

MemberRole.dll

Now add the following to the MailEnable web.config file to remove the actual execution/usage of these modules within the webmail application boundary.

Now set the ‘Local Path’ value within IIS of the /MEWebMail virtual folder to the path where you have put the modified, DNN compatible source code.

On my box this was:

\Program Files\Mail Enable\Bin\DNNCompatible\NETWebMail

If your website also includes the /MEWebAdmin” virtual you will need to repeat all of the above steps. Create a separate folder for the NetWebAdmin code, and note you will have to copy one additional DLL into the /Bin folder.

FreeTextBox.dll

FreeTextBox.lic

I sincerely hope this helps some of you DotNetNuke developers out there who might also happen to be hosting MailEnable!.

Note: The versions which applied to my case were:

MailEnable Enterprise 2.11

DotNetNuke 3.02.02