6 Appendix A: 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. The following versions of .NET Framework are available in the following released Windows product or as supplemental software, see [MS-NETOD] section 4.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
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 1.3.2: Windows allows applications to plug in extensions called Envoy Sinks that are run when a Remote Method is invoked. The actual interface of the extension is beyond the scope of this protocol. Windows uses the Envoy Sink Information to send a list of Envoy Sinks from the server to the client to carry out any client-side behavior such as validating parameters. If there is no application-provided data, this field is a NullObject in Windows.
<2> Section 2.1.1.1.1: Windows maintains a pool of connections for a given ServerObject (identified by its address). Each pool has a receive time-out and a connection time-out. Connections are preserved until the connection time-out expires. A new connection is created if there are no cached connections or if the connection is configured to do SPNEGO authentication.
<3> Section 2.1.1.1.1: Windows never writes chunked messages. However, it can consume chunked messages.
<4> Section 2.1.1.1.1: Windows with .NET Framework 1.0 or Microsoft .NET Framework 1.1 retransmits a message once upon failure. Windows with .NET Framework 2.0 and later versions allows users to configure the number of retransmissions. The default count is 1.
<5> Section 2.1.1.1.2: A Receive time-out can be configured by the higher layer.
<6> Section 2.1.1.2.1: If the serialization format is SOAP, then the SOAPAction in the CustomHeader of a request message is processed as specified in the first Windows behavior note in section 3.2.5.1.4.
<7> Section 2.1.1.2.2: Windows never writes chunked messages. However, it can consume chunked messages.
<8> Section 2.1.2.1.1: In Windows the client always sends request in HTTP/1.1. The request has the following request headers set:
Host request header is set to the host and the port number of the server.
Expect request header is set to 100-continue.
Connection request header is set to Keep-Alive.
<9> Section 2.1.2.1.1: IPv6 address is supported only on .NET Framework 2.0 and later versions.
<10> Section 2.1.2.1.1: Windows sets the User-Agent to "Mozilla/4.0+(compatible; MSIE 6.0; Windows <Windows-Ver>; MS .NET Remoting; MS .NET CLR <.NET-Ver> )" where "Windows-Ver" refers to the version of Windows and ".NET-Ver" refers to the version of .NET Framework.
<11> Section 2.1.2.1.1: Windows never sends messages by using chunked transfer coding.
<12> Section 2.1.2.1.2: The response time-out can be configured by the higher layer.
<13> Section 2.1.2.1.2: Windows supports HTTP redirection (status code specified in [RFC2616] section 10.3). The higher layer can configure to disable HTTP redirection. If disabled, the higher layer is notified of the error. The informational codes (the status code specified in section [RFC2616] 10.1) are handled as specified in [RFC2616] and are not propagated to the higher layer.
<14> Section 2.1.3.1.1.1: Windows sets the User-Agent to "Mozilla/4.0+(compatible; MSIE 6.0; Windows <Windows-Ver>; MS .NET Remoting; MS .NET CLR <.NET-Ver> )" where "Windows-Ver" refers to the version of Windows and ".NET-Ver" refers to the version of .NET Framework.
<15> Section 2.1.3.1.1.2: Windows supports HTTP redirection (status code specified in [RFC2616] section 10.3). The higher layer can configure to disable HTTP redirection. If disabled, the higher layer is notified of the error. The informational codes (status code specified in [RFC2616] section 10.1) are handled as specified in [RFC2616] and are not propagated to the higher layer.
<16> Section 2.2.1.2: TypeParameterList is always empty in .NET Framework 1.0 and .NET Framework 1.1.
<17> Section 2.2.2.7: This field is localized in Windows.
<18> Section 2.2.2.7: The Data field is present only in .NET Framework 2.0 and later versions.
<19> Section 2.2.2.12: A UnityType value of 8 is valid only in .NET Framework 2.0 and later versions.
<20> Section 2.2.2.13: The GenericArguments field is present only in .NET Framework 2.0 and later versions.
<21> Section 2.2.2.15: Windows names the target Member as specified by the following format.
|
Format for target Member name |
||
|---|---|---|
|
TargetMemberName |
= |
'Target' Index |
|
Index |
= |
1*('0'-'9') |
For a given DelegateSerializationHolder, the Index value starts from 0 and increases by 1 for each target Member. The Index value matches the index of the DelegateEntry for the Remote Method in the linked list.
<22> Section 2.2.2.15: The Method Member is present only in .NET Framework 2.0 and later versions.
<23> Section 2.2.3.2.2: IPv6 addresses are supported only on .NET Framework 2.0 and later versions.
<24> Section 2.2.3.3: Windows never writes chunked messages. However, it can consume chunked messages.
<25> Section 2.2.4.1: Windows allows the application to associate a SOAP action with a Remote Method. In the absence of such an association, Windows derives SOAPAction from the Remote Method name by concatenating the XML namespace of the Server Type and the Remote Method name separated by a number sign ('#').
SoapAction = XML namespace of Server Type '#' Remote Method Name where XML namespace of a Server Type is constructed as specified in section Remoting Type Name Encoding.
<26> Section 2.2.4.2: Windows allows the application to associate an XML namespace and a local name with a Remoting Type. In the absence of such an association, Windows derives the qualified name from the Remoting Type name and the Library name.
If the Library name of the Remoting Type is "mscorlib", then the XML namespace is defined as follows.
|
XML namespace definition |
||
|---|---|---|
|
SystemNamespace |
= |
CLRNSPREFIX '/' ClrNamespace( TypeName ) |
|
CLRNSPREFIX |
= |
'http://schemas.microsoft.com/clr/ns' |
|
ClrNamespace( TypeName ) |
= |
ClrNamespace nonterminal token in TypeName in the Common Patterns section |
If the Library name of the Remoting Type is not "mscorlib", then the XML namespace is defined by using the ABNF syntax specified in [RFC4234] as follows.
|
XML namespace definition |
||
|---|---|---|
|
NonSystemNamespace |
= |
CLRNSASSEMPREFIX '/' ClrNamespace( TypeName ) '/' UriEncoded( LibraryName ) |
|
CLRNSASSEMPREFIX |
= |
'http://schemas.microsoft.com/clr/nsassem' |
|
ClrNamespace( TypeName ) |
= |
ClrNamespace nonterminal token in TypeName in the Common Patterns section |
|
UriEncoded(LibraryName ) |
= |
LibraryName as defined in the Common Patterns section with characters ' ' (SPACE) replaced with '%20', '=' replaced with '%3D' and ',' replaced with '%2C' |
If the application did not explicitly define it, the local name is defined by the LocalName nonterminal token in TypeName in the Common Patterns section.
<27> Section 2.2.4.3: Windows allows the application to associate an XML namespace and a local name for the request and response. In the absence of such an association, Windows derives the XML namespace from the Server Type name and the Library name by using the ABNF syntax defined in [RFC4234], specified as follows.
|
How Windows derives an XML namespace from the Server Type name and the Library name |
||
|---|---|---|
|
MethodNamespace |
= |
CLRNSASSEMPREFIX '/' ClrNamespace( TypeName ) '/' LibraryIdentifier( LibraryName) '/' LocalName( ) '/' LocalName( TypeName ) |
|
CLRNSASSEMPREFIX |
= |
'http://schemas.microsoft.com/clr/nsassem' |
|
ClrNamespace( TypeName ) |
= |
ClrNamespace nonterminal token in TypeName in the Common Patterns section |
|
LibraryIdentifier ( LibraryName ) |
= |
The LibraryIdentifier nonterminal token in LibraryName as defined in the Common Patterns section |
|
LocalName( TypeName ) |
= |
The LocalName nonterminal token in TypeName in the Common Patterns section |
The LocalName of the request is the same as the name of the Remote Method.
The LocalName of the response is the name of the request appended with the string "Response".
<28> Section 2.2.5: TypeArgumentList is always empty in .NET Framework version 1.0 and .NET Framework version 1.1.
<29> Section 3.1.1: In Windows a Library is called an assembly.
<30> Section 3.1.1: The name of the System Library in Windows is "mscorlib".
<31> Section 3.1.1: In .NET Framework 1.0 and .NET Framework 1.1, the DateTime value supports only Unspecified. UTC and Local are supported only in .NET Framework 2.0 and later versions.
<32> Section 3.1.1: In Windows, the Generic Remote Method is supported only on .NET Framework 2.0 and later versions.
<33> Section 3.1.5.1.1: Windows allows extensions of its implementation to participate in the serialization of a message. It allows the extensions to provide a collection of DictionaryEntry items that are serialized as Message Properties.
<34> Section 3.1.5.1.2: Windows allows extensions of its implementation to participate in the serialization of a message. It allows the extensions to provide a collection of DictionaryEntry items that are serialized as Message Properties.
<35> Section 3.1.5.1.6: Windows always writes using the ClassWithMembersAndTypes for Classes that are not in the System Library. Windows can read all the versions. Windows uses the ClassWithId record to write subsequent instances of a Class unless the Members that are serialized vary from one instance to another; in that case, Windows uses the Class records with Member information.
<36> Section 3.1.5.1.6: Windows always writes using the SystemClassWithMembersAndTypes for classes that are in the System Library and ClassWithMembersAndTypes for Classes that are not in the System Library. Windows can read all the versions. Windows uses the ClassWithId record to write subsequent instances of a Class unless the Members that are serialized vary from one instance to another; in that case, Windows uses the Class records with Member information.
<37> Section 3.1.5.1.7: Windows always writes:
ArraySingleString for single-dimensional string Arrays with a lower bound of 0.
ArraySinglePrimitive for single-dimensional primitive Arrays with a lower bound of 0.
ArraySingleObject for single-dimensional System.Object Arrays with a lower bound of 0.
<38> Section 3.1.5.2.1: Windows allows extensions of its implementation to participate in the serialization of a message. Windows allows the extensions to provide a collection of name-value pairs. The name is written as the local name of the header element. The namespace of the header element is "http://schemas.microsoft.com/clr/soap/messageProperties". The value is encoded as specified in Mapping Remoting Data Model to SOAP Format (section 3.1.5.2).
<39> Section 3.1.5.2.2: Windows allows extensions of its implementation to participate in the serialization of a message. It allows the extensions to provide a collection of name-value pairs. The name is written as the local name of the header element. The namespace of the header element is "http://schemas.microsoft.com/clr/soap/messageProperties". The value is encoded as specified in the Data Values Encoding section.
<40> Section 3.1.5.2.2: Windows gets the name of the response struct (child of the SOAP Body element in the response message) by appending the name of the request struct (child of the SOAP Body element in the request message) with the string "Response". The name of the Return Value accessor in Windows is "return".
<41> Section 3.1.5.2.11: Windows server implementation never writes the faultactor field. However it can consume a SOAP fault message with the faultactor field present.
<42> Section 3.1.5.3: Windows chooses a Channel URI based on the registered schemes specified in Creating Proxy from Request URI and Server Type (section 3.3.4.1.1). It picks the first Channel URI whose scheme is registered in the client Channel Table.
<43> Section 3.2.5.1.4: The Windows mechanism for binding to a Remote Method is as follows:
If there is no method in the Server Type with the Remote Method name that was de-serialized, then a RemotingException is constructed as specified in the Constructing a Remoting Exception (section 3.2.5.1.7.2) section and the Exception is sent back to the client.
If there is more than one Remote Method in the Server Type with the given name, Windows uses the Method Signature de-serialized to disambiguate. For each of the matching Remote Methods, the Remoting Types in the Method Signature are checked against the Remoting Type of the Remote Method's Argument. If all the Remoting Types match, then the Remote Method is chosen. If no Remote Method matches the Method Signature or if there are multiple matches and no Method Signature, then a RemotingException is constructed as specified in the Constructing a Remoting Exception (section 3.2.5.1.7.2) section, and the Exception is sent back to the client.
When using the SOAP protocol, if the Message Frame has a SOAP-Action header then the SOAP-Action is compared with the SOAP-Action inferred for the Remote Method as specified in the SOAP Action String (section 2.2.4.1) section. If they do not match, then a RemotingException is constructed as specified in the Constructing a Remoting Exception (section 3.2.5.1.7.2) section and the Exception is sent back to the client.
<44> Section 3.2.5.1.4: The Server Object is a CLR object whose type is Server Type and the Remote Method maps to a method in the Class. The Array of Data Values is passed as parameters to the method. The CallContext is passed as thread-specific CallContext values in the CLR.
<45> Section 3.2.5.1.5.3: Windows generates unique Server Object URIs as shown in the following table.
|
Format of the dynamically generated Server Object URI |
||
|---|---|---|
|
ServerObjectURI |
= |
GuidPart '/ 'BytesPart '_' SequenceId '.rem' |
|
GuidPart |
= |
8*8(HEXDIGIT) 3*3 ('_' 4*4(HEXDIGHT)) '_' 12*12(HEXDIGIT) |
|
BytesPart |
= |
24 * 24 (DIGIT / ('A'-'Z') / ('a'-'z') / '+' / '_') |
|
SequenceId |
= |
1*10(DIGIT) |
The GuidPart is a string representation of a GUID with '-' replaced by '_'. Windows uses the same GUID for all the Server Object URIs hosted in an AppDomain. The BytePart consists of 18 randomly generated bytes that are Base64 encoded. The bytes are generated for every Marshaled Server Object. SequenceId is an integer ranging from -2,147,483,648 to 2,147,483,647. It starts from 1 and is incremented for every Marshaled Server Object. Incrementing SequenceId value from 2,147,483,647 wraps it to be -2,147,483,648.
<46> Section 3.2.5.1.7.1: Windows populates the Message field with a localized text message describing the error. The StackTraceString contains text describing the call stack from where the Exception is thrown. The RemoteStackTraceString is NullObject. RemoteStackIndex is 0. ExceptionMethod contains text that lists the Method name, Library name and Remoting Type name. Source contains text representing the name of the Application.
<47> Section 3.2.5.1.7.2: Windows populates the Message field with a localized text message describing the error. The StackTraceString contains text describing the call stack from where the Exception is thrown. The RemoteStackTraceString is NullObject. RemoteStackIndex is 0. ExceptionMethod contains text that lists the Method Name, Library name, and Remoting Type name. Source contains text representing the name of the Application.
<48> Section 3.3.4.2.1: Windows constructs a MethodSignature when there is more than one method with the same name in a Server Type. In this case the MethodSignature is used to disambiguate the methods.