7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

This document specifies version-specific details in the Microsoft .NET Framework. For information about which versions of .NET Framework are available in each released Windows product or as supplemental software, see [MS-NETOD] section 4.

• Microsoft .NET Framework 1.0

• Microsoft .NET Framework 2.0

• Microsoft .NET Framework 3.0

• Microsoft .NET Framework 3.5

• Microsoft .NET Framework 4.0

• Microsoft .NET Framework 4.5

• Microsoft .NET Framework 4.6

• Microsoft .NET Framework 4.7

• Microsoft .NET Framework 4.8

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.2.1: Windows uses this value locally to contain a count of modifications to _items.

<2> Section 2.2.1: Windows writes a Null Object for any elements of the _items Array with an index greater than or equal to the value of the _size field.

<3> Section 2.2.2: Windows sets the value of this field to Null Object.

<4> Section 2.2.2: Windows uses this field locally to hold implementation-specific objects. Windows provides an extension mechanism for the higher layer to provide the value of this field. The default value of this field is an instance of the ContextLevelActivator (section 2.2.3) class.

<5> Section 2.2.2: Windows provides an extension mechanism for the higher layer to associate a collection of values with a Server Type that is activated by the client.

<6> Section 2.2.2: Windows provides an extension mechanism for the higher layer to associate a collection of values with a Server Type that is activated by the client.

<7> Section 2.2.5: Windows sets the value of this field to Null Object.

<8> Section 3: In Windows, the higher-layer protocol can provide an implementation of ISponsor to participate in the lifetime management of the Server Object.

<9> Section 3.1.4.1: Windows determines the Server Type in the following ways:

• If the __ActivationType field is not a Null Object, the value of the __ActivationType field is the Server Type.

• If the __ActivationType field is a Null Object, the __ActivationTypeName field is used to identify the Server Type.

Windows uses the constructor specified by the __MethodName and __MethodSignature fields to construct a Server Object from the Server Type. Windows throws a RemotingException (specified in [MS-NRTP] section 2.2.2.9) in the following cases:

• The specified Server Type is not available.

• The specified constructor is not available.

• The values in the __Args field cannot be used to call the specified constructor.

<10> Section 3.3.3: Windows allows InitialLeaseTime, RenewOnCallTime and SponsorshipTimeout values to be overridden by the higher layer. The default values are as follows:

In the case of a Marshaled Server Object, Windows sets the MSO's TTL to double the InitialLeaseTime configured by the higher layer. So, if the InitialLeaseTime was configured as 5 minutes (the default), the MSO's initial TTL would be 10 minutes.

<11> Section 3.3.6.3: Windows does not modify the Lease when a Server Object is unmarshaled. The Lease will continue its lifetime as specified in Lease TTL Timer (section 3.3.5.1), expiring when the Lease TTL Timer fires and all registered Sponsor objects fail to respond or return 0.