`System.Runtime.Serialization.ISerializable` doesn't exist in target framework


I found System.Runtime.Serialization.SerializationInfo and System.Runtime.Serialization.ISerializable doesn't exist in wp8 api.
But the game I want to build use this to save data, it has some custom classes to save.
I search it all the afternoon, but I didn't find any alternative implementation.
so does anybody have solution for this?


ISerializable and SerializationInfo do not exist in WP8 or WinRT. If you show the code that's using it and what it's doing, maybe we could help provide an alternative. Otherwise you could look at my JSON .NET serialization asset that works on WP8 and WinRT (as well as Standalone, WebPlayer, iOS and Android)


Another think you'll need to be aware of, if your class implements ISerializable like this:

public class SomeClass : ISerializable


You'll need to change it to something like:

public class SomeClass
  : ISerializable


For some bizarre reason Unity decided to add the "UNITY_WINRT" symbol for both Windows Phone and Windows Store Apps even though it's not technically correct since Windows Phone is not WinRT but I submitted a bug report and they just basically said: "Documentation is wrong.. use UNITY_METRO for Windows Store Apps instead.". Anywho, UNITY_WINRT will get both WinRT and WP8. If you want to detect both separately you can use:


Last time I checked, WinRT stands for Windows Runtime.. and whole Windows phone runs on it :).

1 Like

Actually it doesn't. Windows Phone is the Windows Phone version of the Windows Runtime which contains some of the Windows Runtime components. But they are not equivalent. Microsoft actually calls it WinRT but it's an entirely separate API which confuses many people. This is why you can't directly port Windows Store Apps over to Windows Phone 8. You can't even use some of the same basic core functionality, such as differences in Reflection.

Here's a nice comparison of the full WinRT vs the Windows Phone platform:

API wise, that may be the case. But underneath, it's the same COM wrapper that makes C#/C++ interop.

Yes, however there's a big difference... I can have blocks of code that if I say:



They will work perfectly fine on Windows Phone 8 but will puke in WinRT... so it's not just an on the surface thing.

UNITY_WINRT is made so you can use common code for both WP8 and Windows Store Apps. Internally, there's loads of such code, and by using this define, you can write such code as well. Possibility to write such code is much higher than you make it seem.

Use UNITY_WP8 and UNITY_METRO if you need functionality that works on only one and one build target.

You make a good point about the interop bits. I certainly don't mean to make it sound difficult and I pointed out the UNITY_METRO define in my first post. It's really not difficult at all. And it's certainly not specific to Unity. A lot of Microsoft devs were bitten by the big promise of WP8 being WinRT and expected their apps to be a snap to port over and it turned out to not be the case. :) I see the Windows Phone 8 version of WinRT to be just as the Windows Phone 7 version was to .NET. WP7 was really a version of the Compact Framework... so it was .NET but with a lot of bits missing. Although, you couldn't exactly call it the compact framework because it wasn't exactly the same either. Just as XNA was based on the compact framework.. it still had many differences. It was really only the core that was the same.

And I'm not knocking you guys at all. I think you do a pretty fantastic job getting Unity to run cross platform and it's really pretty amazing. The AOT issues with iOS are certainly frustrating but that's not a Unity issue. Windows Store Apps can be challenging as well but that's because it's a different framework version. I've had to duplicate functionality and have one version that compiles in the editor and another that compiles in Windows Store Apps just to get the build process going but that's something that you guys can't control. It's just the nature of the beast. :)