Overhauled saving document state.

[Tristyn]

A while ago, I made this same pull request but it seemed impossible to get git to behave so i could resolve conflicts. Here I am again with all the conflicts resolved.

There are a few issues with saving the layout of documents and tools. Consider the following.

// 1: Gemini can save this ViewModel
[Export(typeof(HomeViewModel))]
public class HomeViewModel : Document

// 2: This doesn't work
[Export(typeof(IHomeBase))]
public class HomeViewModel : Document, IHomeBase

// 3: This also doesn't work (!!)
[Export]
public class HomeViewModel : Document

// 4: This works, but the ambiguity between the two attributes causes Gemini to use the first attribute
[Export(typeof(IMessage))]
[Export(typeof(IHomeBase))]
public class HomeViewModel : Document, IHomeBase, IMessage

All of these have been fixed. In cases 2 and 3, Gemini should now save the proper type name used to create the ViewModel.

In case 4, you have to change one [Export] to a [GeminiExport]:

[Export(typeof(IMessage))]
[GeminiExport(typeof(IHomeBase))] // Gemini will use this one
public class HomeViewModel : Document, IHomeBase, IMessage

Gemini wont fail silently like it did before.

Dude, listen to this

[Tristyn]

I just wanted to fix this. It is extremely slow to create a delegate from an interface method. I changed another bit of code for the same reason.

[4ux-nbIx]

I don't think adding another export attribute is a good idea. First, it definitely shouldn't inherit from export attribute, because it doesn't relate to MEF import\export in any way. Second, it's redundant since the save state code can figure out the correct exported type name itself. If someone has decorated it's class with multiple Export attributes, just choose a contract type that implements ILayoutItem. If multiple export contracts implement ILayoutItem (should never happen, actually), then throw an exception.

[tgjones]

Thanks, @Tristyn.

@4ux-nbIx The state serialization code is mostly from you - does this change (including the last 2 commits (although 0a7b443 is actually empty)) look okay to you?

[4ux-nbIx]

@tgjones, the code looks good. Great job @Tristyn, but there's a bug. I have commented on the corresponding code lines in Tristyn@6eed10d

[Tristyn]

@tgjones I remember 0a7b443 was committed unintentionally. It didn't contain any changed.

[tgjones]

I'm finally getting some time to work on Gemini. I want to pull this in - before I do, can @4ux-nbIx or @Tristyn remind me why we don't just use the type of the attributed class, instead of looking at the ContractType or ContractName from the [Export] attribute? It seems to me like that would be a lot simpler, but I must be missing something obvious.

[4ux-nbIx]

@tgjones, because we need to use MEF here and it needs the correct exported type to construct an instance.

[tgjones]

Ah, thanks - that makes sense. So we could avoid having to do all that if we could find an MEF equivalent to Activator.CreateInstance? Container.SatisfyImportsOnce sort of does it, but doesn't work if you have an ImportingConstructor. I'll keep looking. Would be nice not to require that you [Export] a view model just to be able to save its state.

[4ux-nbIx]

Well, you can still use Activator.CreateInstance if Export attribute is missing. You just need to put a corresponding flag in the state file data.

[tgjones]

I've merged this - thank you very much @Tristyn. (Sorry for the long delay!)

[tgjones]

@Tristyn, looking at Tristyn/MCFire, you seem to be one of Gemini's more active users! I notice you downgraded from the AppVeyor feed to the NuGet version - just wanted to check if there's any particular reason for that? I know there are some breaking changes, but was there something else preventing you using the trunk version?