››› an open-source .net remoting solution ›››

Much of the work done by AMF.NET is trying to map between the types passed between .NET and flash. All three steps (deserialization, execution and serialization) participate in the mapping process. It's vital for any AMF.NET user to fully understand how types are mapped.

Strings are mapped directly as you'd probably expect. The only current limitation is the size of the string coming into AMF.NET or leaving AMF.NET.

Boolean values are mapped directly to and from AMF.NET.

Null is mapped directly to and from AMF.NET.

Numbers represent the first special case. The next section describes the special function matching AMF.NET does. For now, inputs can be either doubles (System.Double) ints (System.Int32), or longs (System.Int64). Other types aren't supported (floats, decimals, unsigned values, 16 bit ints). Support for these other might be added in future releases of AMF.NET - or you can add it yourself by reading the next section and seeing how Int32 is supported.

Any numeric value can be returned, but AMF.NET will convert it to a double (converting from decimal to double might result in very slight loss of precision). The double-only support is a limitation of AMF.

Enums are another special case. If the enum is of type Int32 (the default), AMF.NET will try and convert any inputted integer to it.

AMF Data objects map directly to .NET DateTimes. I'm still unhappy with the time and time zone returned from AMF.NET.

Any XML object inputted into AMF.NET will be converted to an System.Xml.XmlDocument, whereas returned XmlDocument's will be outputted as a string.

The next 3 types we'll look at are objects, arrays and hashtables. While all three types are supported, the values they hold must be a supported type. For example, since Guid's aren't supported, you can't have an array of them.

As of 0.3, AMF.NET supports the input of custom (or typed) objects. AMF.NET can automatically try to map the input to a custom object, or you can extend AMF.NET to create your own mapping code (recommended). Check out the How To section for further details.

Ouputting custom objects works as expected. A hashtable is created with the key being the name of the object's properties, and the property value being the value of the hashtable. In Flash, hashtable keys can be accessed like properties, creating the illusion that an actual object was returned. A future version of AMF.NET is likely to require the class to implement the ISerializeable interface or be marked with the SerializableAttribute.

If a function returns an object, you cannot invoke a method on that object and expect it to be executed on the server. Rather, a proxy is created on the client (or the server when input of objects is supported). (methods aren't even serialized back)

Arrays represent the third special case. Arrays are initially converted to ArrayLists, but if possible and necessary, they will be converted to typed arrays (string[]). More information is available in the next section. There currently isn't support for a generic list (ETA: unknown).

Hashtables are mostly supported as-is. The key must be a string, the value has to be another supported type.

Outputting datasets/datatables/dataviews will be supported in a future version (ETA: unknown).