Yet another day of the CAB... I was using a customized Window-Workspace with my own derived SmartPartInfo. This SPI included a key-string which I usually filled with a primary key of an entity for which the window was shown (simple edit dialog). I used the key to check if the window is already opened so it was impossible to open/edit the same Entity twice. So far so good, but finally my key was always null in one of my dialogs. The only thing that was different to another (working) dialog was that I tried to change the title of the window after it was shown and I did this by giving it just a simple SmartPartInfo. So it was some older code but I was still wondering why it did not crash anyway - I thought wether the ApplySmartPartInfo-Method would have recognized that its "only" a SmartPartInfo or it wouldn't and a cast to my derived type would have failed.
Well, as often .NET Reflector solved the mystery.. turned out that CAB looks at both types - the Template-Argument for the SmartPartInfo-Type and the type of the given SPI-instance and uses Type.IsAssignableFrom to determine if the given instance is -or at least inherits from- the template-Type. If not -and thats the catch- it uses Workspace.ConvertFrom which will create a fresh new Template-Type SmartPartInfo (with all its default values set of course) and copies only the two things that it knows from ISmartPartInfo to the new instance: Title and Description. And so my key was rewritten and the whole stuff didn't work but also did not crash or anything other wrong...