A project I'm working on requires serializing a data structure before shutting down and restores its state from this serialized data when it start up again.
Last year, we were building for .NET 1.1, and ran into a tricky issue where
This particular issue was "resolved" by barring that particular software upgrade, and shouldn't be a problem now that we're targeting the .NET 2.0 framework (so we can't possibly run on 1.1).
What is the chance that this serialization could again change incompatibly between, 2.0 and newer frameworks? If we use <supportedVersion> to fix our code to 2.0.50727, what are the chances of changes between 2.0.50727.1434 and 2.0.50727.nnnn (some future release)? The data structures being serialized are arrays, maps, strings, et cetera from the standard class libraries.
Additionally, is it guaranteed that a 2.0.50727 framework will be always installed even after further .NET upgrades? Pointers to Microsoft documentation welcome.
The chances are low (but not zero!) that there will be changes between framework versions. The intention would be that you should be able to use binary serialization and remoting to communicate between a client and a server running different framework versions. The incompatibility between .NET 1.x and 2.0 is a bug for which a patch is available.
However binary serialization has other issues, especially poor support for versioning of the structure you're serializing. From the use case you've described, Xml serialization is the obvious choice: DataContractSerializer being more flexible than XmlSerializer if you don't mind the dependency on .NET 3.x.
You can't guarantee that the .NET framework 2.0 will always be installed on future versions of Windows. But I'm sure Microsoft will work hard to ensure that most .NET 2.0 apps will run unchanged on .NET 4.x and later versions. I don't have any references for this: any such commitment would in any case only really apply to the next version of Windows (Windows 7).