bump to version 5.6.1

Mpdreamz · Mpdreamz · commit 744227244fb6 · 2018-03-14T12:50:53.000+01:00
diff --git a/docs/aggregations/writing-aggregations.asciidoc b/docs/aggregations/writing-aggregations.asciidoc
@@ -230,7 +230,6 @@ return s => s
         );
 ----
 <1> a list of aggregation functions to apply
-
 <2> Using LINQ's `Aggregate()` function to accumulate/apply all of the aggregation functions
 
 [[aggs-vs-aggregations]]
@@ -278,6 +277,5 @@ var maxPerChild = childAggregation.Max("max_per_child");
 maxPerChild.Should().NotBeNull(); <2>
 ----
 <1> Do something with the average per child. Here we just assert it's not null
-
 <2> Do something with the max per child. Here we just assert it's not null
 
diff --git a/docs/client-concepts/certificates/working-with-certificates.asciidoc b/docs/client-concepts/certificates/working-with-certificates.asciidoc
@@ -155,11 +155,8 @@ public class PkiCluster : CertgenCaCluster
 }
 ----
 <1> Set the client certificate on `ConnectionSettings`
-
 <2> The path to the `.cer` file
-
 <3> The path to the `.key` file
-
 <4> The password for the private key
 
 Or per request on `RequestConfiguration` which will take precedence over the ones defined on `ConnectionConfiguration`
diff --git a/docs/client-concepts/connection-pooling/exceptions/unexpected-exceptions.asciidoc b/docs/client-concepts/connection-pooling/exceptions/unexpected-exceptions.asciidoc
@@ -60,11 +60,8 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> set up a cluster with 10 nodes
-
 <2> where node 2 on port 9201 always throws an exception
-
 <3> The first call to 9200 returns a healthy response
-
 <4> ...but the second call, to 9201, returns a bad response
 
 Sometimes, an unexpected exception happens further down in the pipeline. In this scenario, we
@@ -103,9 +100,7 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> calls on 9200 set up to throw a `WebException`
-
 <2> calls on 9201 set up to throw an `Exception`
-
 <3> Assert that the audit trail for the client call includes the bad response from 9200 and 9201
 
 An unexpected hard exception on ping and sniff is something we *do* try to recover from and failover to retrying on the next node.
@@ -150,8 +145,6 @@ audit = await audit.TraceUnexpectedException(
 );
 ----
 <1> `InnerException` is the exception that brought the request down
-
 <2> The hard exception that happened on ping is still available though
-
 <3> An exception can be hard to relate back to a point in time, so the exception is also available on the audit trail
 
diff --git a/docs/client-concepts/connection-pooling/exceptions/unrecoverable-exceptions.asciidoc b/docs/client-concepts/connection-pooling/exceptions/unrecoverable-exceptions.asciidoc
@@ -68,7 +68,6 @@ var audit = new Auditor(() => Framework.Cluster
 );
 ----
 <1> Always succeed on ping
-
 <2> ...but always fail on calls with a 401 Bad Authentication response
 
 Now, let's make a client call. We'll see that the first audit event is a successful ping
@@ -89,9 +88,7 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> First call results in a successful ping
-
 <2> Second call results in a bad response
-
 <3> The reason for the bad response is Bad Authentication
 
 When a bad authentication response occurs, the client does not attempt to deserialize the response body returned;
@@ -125,7 +122,6 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> Always return a 401 bad response with a HTML response on client calls
-
 <2> Assert that the response body bytes are null
 
 Now in this example, by turning on `DisableDirectStreaming()` on `ConnectionSettings`, we see the same behaviour exhibited
@@ -158,6 +154,5 @@ audit = await audit.TraceElasticsearchException(
 );
 ----
 <1> Response bytes are set on the response
-
 <2> Assert that the response contains `"nginx/"`
 
diff --git a/docs/client-concepts/connection-pooling/request-overrides/disable-sniff-ping-per-request.asciidoc b/docs/client-concepts/connection-pooling/request-overrides/disable-sniff-ping-per-request.asciidoc
@@ -67,11 +67,8 @@ audit = await audit.TraceCalls(
 );
 ----
 <1> disable sniffing
-
 <2> first call is a successful ping
-
 <3> sniff on startup call happens here, on the second call
-
 <4> No sniff on startup again
 
 Now, let's disable pinging on the request 
@@ -95,7 +92,6 @@ audit = await audit.TraceCall(
 );
 ----
 <1> disable ping
-
 <2> No ping after sniffing
 
 Finally, let's demonstrate disabling both sniff and ping on the request 
@@ -117,6 +113,5 @@ audit = await audit.TraceCall(
 );
 ----
 <1> diable ping and sniff
-
 <2> no ping or sniff before the call
 
diff --git a/docs/client-concepts/connection-pooling/round-robin/skip-dead-nodes.asciidoc b/docs/client-concepts/connection-pooling/round-robin/skip-dead-nodes.asciidoc
@@ -142,9 +142,7 @@ await audit.TraceCalls(
 );
 ----
 <1> The first call goes to 9200 which succeeds
-
 <2> The 2nd call does a ping on 9201 because its used for the first time. It fails so we wrap over to node 9202
-
 <3> The next call goes to 9203 which fails so we should wrap over
 
 A cluster with 2 nodes where the second node fails on ping 
@@ -194,6 +192,5 @@ await audit.TraceCalls(
 );
 ----
 <1> All the calls fail
-
 <2> After all our registered nodes are marked dead we want to sample a single dead node each time to quickly see if the cluster is back up. We do not want to retry all 4 nodes
 
diff --git a/docs/client-concepts/connection-pooling/sniffing/role-detection.asciidoc b/docs/client-concepts/connection-pooling/sniffing/role-detection.asciidoc
@@ -140,7 +140,6 @@ var audit = new Auditor(() => Framework.Cluster
 };
 ----
 <1> Before the sniff, assert we only see three master only nodes
-
 <2> After the sniff, assert we now know about the existence of 20 nodes.
 
 After the sniff has happened on 9200 before the first API call, assert that the subsequent API
@@ -221,9 +220,7 @@ var audit = new Auditor(() => Framework.Cluster
 };
 ----
 <1> for testing simplicity, disable pings
-
 <2> We only want to execute API calls to nodes in rack_one
-
 <3> After sniffing on startup, assert that the pool of nodes that the client will execute API calls against only contains the three nodes that are in `rack_one`
 
 With the cluster set up, assert that the sniff happens on 9200 before the first API call
@@ -300,8 +297,6 @@ await audit.TraceUnexpectedElasticsearchException(new ClientCall
 });
 ----
 <1> The audit trail indicates a sniff for the very first time on startup
-
 <2> The sniff succeeds because the node predicate is ignored when sniffing
-
 <3> when trying to do an actual API call however, the predicate prevents any nodes from being attempted
 
diff --git a/docs/client-concepts/connection/configuration-options.asciidoc b/docs/client-concepts/connection/configuration-options.asciidoc
@@ -174,37 +174,37 @@ The following is a list of available connection configuration options on `Connec
 
 Specify how field names are inferred from POCO property names.
 +
-By default, NEST camel cases property names  e.g. EmailAddress POCO property => "emailAddress" Elasticsearch document field name
+By default, NEST camel cases property names e.g. EmailAddress POCO property => "emailAddress" Elasticsearch document field name
 
 `DefaultIndex`::
 
 The default index to use when no index is specified.
 
 `DefaultTypeNameInferrer`::
 
-Specify how type names are inferred from POCO types.  By default, type names are inferred by calling `ToLowerInvariant` on the type's name.
+Specify how type names are inferred from POCO types. By default, type names are inferred by calling `ToLowerInvariant` on the type's name.
 
 `MapDefaultTypeIndices`::
 
-Specify the default index names for a given POCO type.  Takes precedence over the global `DefaultIndex`
+Specify the default index names for a given POCO type. Takes precedence over the global `DefaultIndex` Removed in 6.x.
 
 `MapDefaultTypeNames`::
 
-Specify the default type names for a given POCO type.  Takes precedence over the global `DefaultTypeNameInferrer`
+Specify the default type names for a given POCO type. Takes precedence over the global `DefaultTypeNameInferrer` Removed in 6.x.
 
 `MapIdPropertyFor`::
 
-Specify which property on a given POCO should be used to infer the id of the document when  indexed in Elasticsearch. The type of the document.
+Specify which property on a given POCO should be used to infer the id of the document when indexed in Elasticsearch. The type of the document. Removed in 6.x.
 
 `MapPropertiesFor`::
 
-Specify how the properties are mapped for a given POCO type. The type of the document.
+Specify how the properties are mapped for a given POCO type. The type of the document. Removed in 6.x.
 
 `PluralizeTypeNames`::
 
 Pluralize type names when inferring from POCO type names.
 +
-This calls `DefaultTypeNameInferrer` with an implementation that will pluralize type names.              This used to be the default prior to Nest 0.90
+This calls `DefaultTypeNameInferrer` with an implementation that will pluralize type names.             This used to be the default prior to Nest 0.90
 
 :xml-docs: Nest:ConnectionSettingsBase`1
 
diff --git a/docs/client-concepts/high-level/analysis/writing-analyzers.asciidoc b/docs/client-concepts/high-level/analysis/writing-analyzers.asciidoc
@@ -106,7 +106,6 @@ var createIndexResponse = client.CreateIndex("my-index", c => c
 );
 ----
 <1> Pre-defined list of English stopwords within Elasticsearch
-
 <2> Use the `standard_english` analyzer configured
 
 [source,javascript]
@@ -274,7 +273,6 @@ var createIndexResponse = client.CreateIndex("questions", c => c
 );
 ----
 <1> Use an analyzer at index time that strips HTML tags
-
 <2> Use an analyzer at search time that does not strip HTML tags
 
 With this in place, the text of a question body will be analyzed with the `index_question` analyzer
diff --git a/docs/client-concepts/high-level/getting-started.asciidoc b/docs/client-concepts/high-level/getting-started.asciidoc
@@ -109,7 +109,6 @@ var indexResponse = client.Index(person); <1>
 var asyncIndexResponse = await client.IndexAsync(person); <2>
 ----
 <1> synchronous method that returns an `IIndexResponse`
-
 <2> asynchronous method that returns a `Task<IIndexResponse>` that can be awaited
 
 NOTE: All methods available within NEST are exposed as both synchronous and asynchronous versions,
diff --git a/docs/client-concepts/high-level/inference/field-inference.asciidoc b/docs/client-concepts/high-level/inference/field-inference.asciidoc
@@ -475,13 +475,9 @@ class Precedence
 }
 ----
 <1> Even though this property has a NEST property mapping _and_ a `JsonProperty` attribute, We are going to provide a hard rename for it on ConnectionSettings later that should win.
-
 <2> This property has both a NEST attribute and a `JsonProperty`, NEST should win.
-
 <3> We should take the json property into account by itself
-
 <4> This property we are going to special case in our custom serializer to resolve to ask
-
 <5> We are going to register a DefaultFieldNameInferrer on ConnectionSettings that will uppercase all properties.
 
 Here we create a custom serializer that renames any property named `AskSerializer` to `ask`
diff --git a/docs/client-concepts/high-level/inference/indices-paths.asciidoc b/docs/client-concepts/high-level/inference/indices-paths.asciidoc
@@ -90,7 +90,6 @@ singleIndexFromIndexName.Match(
 );
 ----
 <1> `_all` will override any specific index names here
-
 <2> The `Project` type has been mapped to a specific index name using <<index-name-type-mapping,`.InferMappingFor<Project>`>>
 
 [[nest-indices]]
@@ -123,9 +122,7 @@ ISearchRequest singleTypedRequest = new SearchDescriptor<Project>().Index(single
 var invalidSingleString = Index("name1, name2"); <3>
 ----
 <1> specifying a single index using a string
-
 <2> specifying a single index using a type
-
 <3> an **invalid** single index name
 
 ===== Multiple indices
@@ -151,9 +148,7 @@ manyStringRequest = new SearchDescriptor<Project>().Type(new[] { "name1", "name2
 ((IUrlParameter)manyStringRequest.Type).GetString(this.Client.ConnectionSettings).Should().Be("name1,name2");
 ----
 <1> specifying multiple indices using strings
-
 <2> specifying multiple indices using types
-
 <3> The index names here come from the Connection Settings passed to `TestClient`. See the documentation on <<index-name-inference, Index Name Inference>> for more details.
 
 ===== All Indices
diff --git a/docs/client-concepts/high-level/mapping/fluent-mapping.asciidoc b/docs/client-concepts/high-level/mapping/fluent-mapping.asciidoc
@@ -287,11 +287,8 @@ var createIndexResponse = client.CreateIndex("myindex", c => c
             );
 ----
 <1> Automap company
-
 <2> Override company inferred mappings
-
 <3> Auto map employee
-
 <4> Override employee inferred mappings
 
 [source,javascript]
@@ -426,11 +423,8 @@ var createIndexResponse = client.CreateIndex("myindex", c => c
             );
 ----
 <1> Automap `Company`
-
 <2> Override specific `Company` mappings
-
 <3> Automap `Employees` property
-
 <4> Override specific `Employee` properties
 
 [source,javascript]
diff --git a/docs/client-concepts/high-level/mapping/ignoring-properties.asciidoc b/docs/client-concepts/high-level/mapping/ignoring-properties.asciidoc
@@ -71,7 +71,6 @@ var createIndexResponse = client.CreateIndex("myindex", c => c
 );
 ----
 <1> we're using an in-memory connection, but in your application, you'll want to use an `IConnection` that actually sends a request.
-
 <2> we disable direct streaming here to capture the request and response bytes. In your application however, you'll like not want to do this in production.
 
 The JSON output for the mapping does not contain the ignored properties
diff --git a/docs/client-concepts/high-level/mapping/multi-fields.asciidoc b/docs/client-concepts/high-level/mapping/multi-fields.asciidoc
@@ -165,9 +165,7 @@ var createIndexResponse = client.CreateIndex("myindex", c => c
             );
 ----
 <1> Use the stop analyzer on this sub field
-
 <2> Use a custom analyzer named "named_shingles" that is configured in the index
-
 <3> Index as not analyzed
 
 [source,javascript]
diff --git a/docs/client-concepts/high-level/mapping/visitor-pattern-mapping.asciidoc b/docs/client-concepts/high-level/mapping/visitor-pattern-mapping.asciidoc
@@ -73,7 +73,6 @@ public class DisableDocValuesPropertyVisitor : NoopPropertyVisitor
 }
 ----
 <1> Override the `Visit` method on `INumberProperty` and set `DocValues = false`
-
 <2> Similarily, override the `Visit` method on `IBooleanProperty` and set `DocValues = false`
 
 Now we can pass an instance of our custom visitor to `.AutoMap()` 
diff --git a/docs/client-concepts/low-level/getting-started.asciidoc b/docs/client-concepts/low-level/getting-started.asciidoc
@@ -108,7 +108,6 @@ var asyncIndexResponse = await lowlevelClient.IndexAsync<string>("people", "pers
 string responseString = asyncIndexResponse.Body;
 ----
 <1> synchronous method that returns an `IIndexResponse`
-
 <2> asynchronous method that returns a `Task<IIndexResponse>` that can be awaited
 
 NOTE: All available methods within Elasticsearch.Net are exposed as both synchronous and asynchronous versions,
@@ -245,11 +244,8 @@ var serverError = searchResponse.ServerError; <3>
 var exception = searchResponse.OriginalException; <4>
 ----
 <1> Response is in the 200 range, or an expected response for the given request
-
 <2> Response is successful, or has a response code between 400-599 that indicates the request cannot be retried.
-
 <3> Details of any error returned from Elasticsearch
-
 <4> If the response is unsuccessful, will hold the original exception.
 
 Using these details, it is possible to make decisions around what should be done in your application.
diff --git a/docs/client-concepts/troubleshooting/logging-with-on-request-completed.asciidoc b/docs/client-concepts/troubleshooting/logging-with-on-request-completed.asciidoc
@@ -40,9 +40,7 @@ await client.RootNodeInfoAsync(); <3>
 counter.Should().Be(2);
 ----
 <1> Construct a client
-
 <2> Make a synchronous call and assert the counter is incremented
-
 <3> Make an asynchronous call and assert the counter is incremented
 
 `OnRequestCompleted` is called even when an exception is thrown, so it can be used even if the client is
@@ -66,9 +64,7 @@ await Assert.ThrowsAsync<ElasticsearchClientException>(async () => await client.
 counter.Should().Be(2);
 ----
 <1> Configure a client with a connection that **always returns a HTTP 500 response
-
 <2> Always throw exceptions when a call results in an exception
-
 <3> Assert an exception is thrown and the counter is incremented
 
 Here's an example using `OnRequestCompleted()` for more complex logging
@@ -149,15 +145,10 @@ list.ShouldAllBeEquivalentTo(new[] <6>
 });
 ----
 <1> Here we use `InMemoryConnection` but in a real application, you'd use an `IConnection` that _actually_ sends the request, such as `HttpConnection`
-
 <2> Disable direct streaming so we can capture the request and response bytes
-
 <3> Perform some action when a request completes. Here, we're just adding to a list, but in your application you may be logging to a file.
-
 <4> Make a synchronous call
-
 <5> Make an asynchronous call
-
 <6> Assert the list contains the contents written in the delegate passed to `OnRequestCompleted`
 
 When running an application in production, you probably don't want to disable direct streaming for _all_
@@ -237,10 +228,7 @@ list.ShouldAllBeEquivalentTo(new[]
 });
 ----
 <1> Make a synchronous call where the request and response bytes will not be buffered
-
 <2> Make an asynchronous call where `DisableDirectStreaming()` is enabled
-
 <3> Only the method and url for the first request is captured
-
 <4> the body of the second request is captured
 
diff --git a/docs/code-standards/naming-conventions.asciidoc b/docs/code-standards/naming-conventions.asciidoc
@@ -140,6 +140,8 @@ var nestAssembly = typeof(IElasticClient).Assembly();
 var exceptions = new List<Type>
 {
     nestAssembly.GetType("System.AssemblyVersionInformation"),
+    nestAssembly.GetType("Microsoft.CodeAnalysis.EmbeddedAttribute", throwOnError: false),
+    nestAssembly.GetType("System.Runtime.CompilerServices.IsReadOnlyAttribute", throwOnError: false),
 #if DOTNETCORE
     typeof(SynchronizedCollection<>),
     nestAssembly.GetType("System.ComponentModel.Browsable")
diff --git a/docs/search/request/suggest-usage.asciidoc b/docs/search/request/suggest-usage.asciidoc
diff --git a/docs/search/returned-fields.asciidoc b/docs/search/returned-fields.asciidoc
diff --git a/docs/search/writing-queries.asciidoc b/docs/search/writing-queries.asciidoc
diff --git a/global.json b/global.json
