MvvmCross plugin with specific windows phone version specifications - mvvmcross

Question

I'm writing a plugin but I need a specific implementation for each Windows Phone version.
The problem is that the plugin system will try to load the platform plugin assembly based on a convention. In this case, "WindowsPhone".
We may try to override CreatePluginManager but then it will affect the rest of the plugins you may need.
I'm thinking of generating two different projects with different names but the same assembly and namespace. This, I think, would solve the problem of loading the specific plugin but I don't really know how to face an eventual publication to Nuget.
Best regards,
Roberto.

Answer 1

Generating assemblies with the same name is a viable way to go - it is something that the Microsoft Pcl teams do quite frequently - it is how the reference assemblies work.
The nuget distribution of these shouldn't be an issue - but would be a "faff" - as the nuget zip file would use different folders for the different files. There might, however, be some work to do at the .targets level if you want a single project to build both wp7 and wp8 configurations (this is similar to the effort needed for x86/x64/arm variants of assemblies in winrt nuget packages).
In fact, the main reason I can think for not using the same name is the very simple reason that it's far too easy to get in a muddle that way.
If for this one plugin, you wanted to override the plugin manager during setup, you could provide custom loading functionality based on
inheriting from https://github.com/slodge/MvvmCross/blob/v3/CrossCore/Cirrious.CrossCore/Plugins/MvxFilePluginManager.cs
and then overriding protected virtual string GetPluginAssemblyNameFrom(Type toLoad) to add a special based on some property of toLoad - eg if (toLoad.Name.EndsWith("Foo")) toReturn += PlatformPostfix
If this pattern becomes common - whether for wp or for the other versioned platforms - then we could include something back into the framework - it would be easy enough to try a version-neutral load followed by a version-specific load for every plugin.
There are also other ways you could go about this too...
E.g. Another possibility/opportunity is that your plugin core file could try loading multiple platform adaptions itself - eg using code like
public void EnsureLoaded()
{
var manager = Mvx.Resolve<IMvxPluginManager>();
manager.TryEnsurePlatformAdaptionLoaded<PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub1.PluginLoader>();
manager.TryEnsurePlatformAdaptionLoaded<Sub2.PluginLoader>();
}
This would try loading three child assemblies for that plugin - MyPlugin.WindowsPhone, MyPlugin.Sub1.WindowsPhone and MyPlugin.Sub2.WindowsPhone although you would only package one of these on each platform.