Bugfix: Allow support for screen types with extremely long full type names

[eric-winkler]

Because the screen identifier is later used to build a filename, extremely long type names (such as those from generic types) end up exceeding the 260 char limit on windows and tend to crash a test when disposing a ScreenRepository.

The test is a little ugly (relies on knowledge of the WindowItemsMap internals) as in the current implementation, it's essentially an integration issue between the ID generated by the ScreenRepository and the filename generated in WindowItemsMap.

A couple of approaches that could allow for this issue to be managed at a unit test level;

• Changing the Identifier type on InitializeOption from string to Guid
• Changing the Identifier type on InitializeOption from string to Type

[eric-winkler]

The CI run has fallen over, appreciate if you could take a look Jake.

[JakeGinnivan]

Seems to be fine now, and looks good

Are there any issues with existing WindowItemMap files then reading this is? Does it just fail and delete the current one?

[eric-winkler]

Any existing WindowItemMap file will effectively be orphaned (it will look for an existing file name based on a GUID, not find it and just assume there is no file to restore from). I can't see any cleanup code for these files so I imagine they just hang around forever - but that's probably not a problem (ie same behavior as when a screen type is renamed).