Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Implementing IUpgradable on later Module versionsImplementing IUpgradable on later Module versions
Previous
 
Next
New Post
11/26/2008 12:47 AM
 

I built a Module whose Business Controller Class did NOT implement IUpgradable in the first version (01.00.00).

The Module then went through a series of incremental upgrades. I recently finished work on a major upgrade to the Module with breaking changes from older versions.

The installation of this upgrade required performing some actions that lay outsie the normal DNN Upgrade process (DataProvider files, clean-up txt files) etc.

So, I implemented IUpgardable on the BusinessControllerClass in this version. However, to my surprise, when I uploaded the new version into a test DNN install, no Upgrade logic was executed. I checked the Module Definition, and there was NO check mark in front of the IUpgradeble module capability.

So, does that mean that if a BusinessControllerClass does not implement IUpgradable in the first version, no later version could do so?? Is there any way of getting the Upgrade logic of this new version executed during the install process???

 
New Post
11/26/2008 9:07 AM
 

I recall that when IUpgradable was first added to the DNN framework there was a problem with its use in later versions of a module when it had not been implemented in the first version. AFAIK this and several other problems with IUpgradable was fixed many DNN versions ago.

Here are several things to check (and I suspect your already are aware of them):

1. Properly implemented the IUpgradable interface by adding Implements DotNetNuke.Entities.Modules.IUpgradable after the class declaration and Public Function UpgradeModule (ByVal version As String) As String Implements DotNetNuke.Entities.Modules.IUpgradable.UpgradeModule to the business controller class.

2. Added a <businesscontrollerclass> node to your .dnn manifest file and included the fully qualified class name in that node. If this is a WAP/compiled module, the content of the node should include the assembly name: <businesscontrollerclass>MyCompany.MyModuleNamespace.MyControllerClass, MyModuleAssemblyName</businesscontrollerclass>

3. Included in the zip package and referenced in a file node of the .dnn manifest an "xx.xx.xx.SqlDataProvider" file with xx.xx.xx representing the version number of the new upgrade. Note that even if you do not need an SqlDataProvider file for this version to make database modifications, a blank one must be included to properly trigger UpgradeModule - which will be called for each version there is a corresponding SqlDataProvider file.

4. Have you tried (after installing the new module version on the test site), opening the module's definition then clicking Update to see if IUpgradable is now properly checked?

BTW, against what version of DNN was the module developed and what is the version of DNN running on the test site?


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
11/26/2008 11:01 AM
Accepted Answer 

Thanx for the reply. The Module was originally built against 4.8.2 and now running on 4.9.0.

And I double checked your checklist, and I was doing everything right. So, I later decided to dig deeper into the core onto what happens when a module is installed and how does the core checks which interfaces are implemented.

I found that the core creates through Reflection an object of the specified BusinessController Class, and checks the object for implemented interfaces. And trying to create an object of my BusinessController class was throwing an exception.

And there, I had it. My Controller did NOT had a parameterless constructor. It had a Parameterized constructor only. And that was where the problem lied.

So, I added a parameterless constructor, and voila, everything was back to normal.

As a passby, I would suggest the Code team NOT to catch & ignore the execption generated trying to create an object of the Controller class during Module installs and upgrades, but add an Event entry for it. Creating object via Reflection might fail due to a variety of reasons, and creating a Log Entry would help the developer to determine what exactly went wrong.

 
New Post
11/26/2008 2:25 PM
 

An excellent catch! I recall now that quite a while back a developer had a similar problem with not having a parameterless constructor for his BusinessController class. I would suggest entering in Gemini as an enhancement your suggestion that such an exception not be eaten but at least logged.


Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Implementing IUpgradable on later Module versionsImplementing IUpgradable on later Module versions


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out