Question

I am porting a .NET Framework C# class library to a Portable Class Library. One recurring problem is how to deal with classes decorated with the [Serializable] attribute, since this attribute is not part of the Portable Class Library subset. Serialization functionality in the Portable Class Library subset instead appears to be covered by DataContractAttribute.

• To preserve as much of functionality as possible in the Portable Class Library, is it sufficient to replace [Serializable] with the [DataContract] attribute (with the implication that all fields and properties subject to serialization would need to be decorated with [DataMember] as well)?
• What (if anything) will I not be able to do with this approach that I can do with [Serializable] applied?
• Is there a less intrusive approach?

Given that [DataContract] and [DataMember] are used, I am considering to change the code along the following lines. Are there any obvious flaws with this approach? Is there any way to formulate the same thing less verbose?

#if PORTABLE
    [DataContract]
#else
    [Serializable]
#endif
    public class SerializableClass : SerializableBaseClass
    {
       ...
#if !PORTABLE
        protected SerializableClass(SerializationInfo info, StreamingContext context)
             : base(info, context)
        {
        }
#endif
        ...
#if PORTABLE
        [DataMember]
#endif
        private Type1 _serializableField;

#if PORTABLE
        [DataMember]
#endif
        private Type2 SerializableProperty { get; set; }

        ...
    }

Answer 1

Portable Class Libraries (PCLs) now officially deprecated [16 August 2017]

If you’re sharing code between different .NET implementations today,
you’re probably aware of Portable Class Libraries (PCLs). With the
release of .NET Standard 2.0, we’re now officially deprecating PCLs
and you should move your projects to .NET Standard.

Source: Announcing .NET Standard 2.0

Portable Class Library (PCL) now available on all platforms [14 Oct 2013]

Prior to today’s release, there was a license restriction with the PCL
reference assemblies which meant they could only be used on Windows.
With today’s release we are announcing a new standalone release of the
PCL reference assemblies with a license that allows it to be used on
any platform – including non-Microsoft ones. This enables developers
even more flexibility and to do great things with .NET.

Source: Portable Class Library (PCL) now available on all platforms

Download: Microsoft .NET Portable Library Reference Assemblies 4.6 RC

Just for the reference the allowed set of assemblies are:

mscorlib.dll

System.dll

System.Core.dll

System.Xml.dll

System.ComponentModel.Composition.dll (MEF)

System.Net.dll

System.Runtime.Serialization.dll

System.ServiceModel.dll

System.Xml.Serialization.dll

System.Windows.dll (from Silverlight)

As far as I know you need to mark the fields with DataMember attribute, and add the DataContract attribute.

UPDATE

Yes.

You can look how Json.NET portable class library solution is implemented. You can find the solution in the Source\Src\Newtonsoft.Json.Portable when you download the project from here Json.NET 4.5 Release 10 (source + binary).

Basically they are using an approach with a custom attribute provider

//don’t use Serializable

#if !(SILVERLIGHT || WINDOWS_PHONE || NETFX_CORE || PORTABLE)
  [Serializable]
#endif

//use custom provider

#if NETFX_CORE || PORTABLE
using ICustomAttributeProvider = Newtonsoft.Json.Utilities.CustomAttributeProvider;
#endif 

And if project is PORTABLE

#if !PocketPC && !NET20
      DataContractAttribute dataContractAttribute = GetDataContractAttribute(objectType);
      if (dataContractAttribute != null)
        return MemberSerialization.OptIn;
#endif

where OptIn description is:

 /// <summary>
    /// Only members must be marked with <see cref="JsonPropertyAttribute"/> or <see cref="DataMemberAttribute"/> are serialized.
    /// This member serialization mode can also be set by marking the class with <see cref="DataContractAttribute"/>.
    /// </summary>
    OptIn,

Hope it helps.

UPDATE 2

Am I losing any abilities using [DataContract] instead of
[Serializable], or will I still be able to do everything that
[Serializable] supports?

You can do everything that Serializable supports except
control over how the object is serialized outside of setting the name and the order.

Using DataContractSerializer has several benefits:

serialize anything decorated with a [DataMember] even if it’s not public visible

can’t serialize anything unless you specifically tell it to (“opt-in”)

you can define the order in which the elements are serialized using the [Order=] attribute on the [DataMember]

doesn’t require a parameterless constructor for deserialization

is 10% faster than XmlSerializer.

Read more here: XmlSerializer vs DataContractSerializer

Also for the reference:

DataContract supports serialization of the following kinds of types in the default mode:
CLR built-in types

Byte array, DateTime, TimeSpan, GUID, Uri, XmlQualifiedName,
XmlElement and XmlNode array

Enums

Types marked with DataContract or CollectionDataContract attribute

Types that implement IXmlSerializable

Arrays and Collection classes including List, Dictionary and
Hashtable

Types marked with Serializable attribute including those that
implement ISerializable

Types with none of the above attributes (POCO) but with a default
constructor