In the .ascx components you inherit from PortalModuleBase so PortalId is always visable and it's easy to use to populate business objects that require it.

When importing/exporting from the module controller that is not the case. The Import/Export provides the ModuleId, but not the PortalId. When you have Portal based modules you need the PortalId to do the ListAll functions for export, and to populate the business objects during the Add on import.

Is something like:

            Dim mi As New Entities.Modules.ModuleInfo
           colObjects = ListObjects(mi.PortalId)

considered kosher?

Thank you for the reply, that solves 95% of my problem. The last 5% will require a core change.

Currrent DNN assumes Module centric only import/export. Portal centric will only work if you use the method you described while logged into the portal in question.

If you're logged in to a "Host" account and do an Export Portal Template on another portal on that installtion you will retrieve the portalid of the portal you're currently logged in to and it doesn't match if you export something different.  On the import side I want to be able to template a portal complete with data. I'll have to see how reacts when I get to that point.

On import/export the ModuleId, but not PortalId is retrieved from the calling parameters. It would be nice if the iPortable interface supported PortalId but the workaround about logging into the portal you're templating is not a crisis.