I wanted to follow up to say that as I thought about it last night, this is probably a bad idea:
ReadOnly Property RoleUsers()
As IRoleUserCollection Implements IUser.RoleUsers
If _ruleUsers Is
_roleUsers = PartCreator(Of IRoleUserCollection).CreatePart()
It accesses the container for a simple import fulfillment. It is probably a better idea to make a public importing constructor.
But this does highlight a challenge that SL presents to MEF, and that's passed on to us as we design with MEF on SL. Because SL locks down reflection to private members, the design needs to relax scope. In general, making changes to the surface of objects
due to an internal decision breaks black box design and specifically expanding scope because of an internal technique is unfortunate. But SL has special rules to keep it safe, which is essential.
Thus, you either make your public properties read/write, or you make a backing field public (the worst approach, imo), or you offer a public constructor when you wish the part only to be constructed via MEF - all of which allow MEF to work as it was
Or, you use a hack to preserve the object surface but directly or indirectly access the container. It's better to access the container indirectly, and if the code sits only in SL, you can use code like this here (which is air code so may not be quite right).
If the code is linked between SL and .NET it has to hit the lowest denominator, which is currently .NET. Therefore, you have to expose the container and hit it via GetExports.
It was not obvious to me how to build the container, so I'll add this in case its also not obvious to someone else. SL has a Deployment class which exposes the assemblies of the current package via AssemblyParts. Not that SL assembly parts have nothing to
do with MEF parts, just a vague word used a different way. WIth a surface area the size of .NET its actually surprising this doesn't happen more often.
So, I wound up working through this problem here publically, so I thought I should include a summary of where I wound up with this.
Thanks again to Glenn and Nick for thier help.