# .NET: Using NEST 7.x high-level client against Elasticsearch 6.x: **URL:** \ **Category:** Elasticsearch\ **Tags:** language-clients\ **Created:** [August 14, 2023, 3:45pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768 "2023-08-14T15:45:45Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Thomas\_Doman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thomas_doman/32/11409_2.png) [@Thomas\_Doman](https://discuss.elastic.co/u/Thomas_Doman)\ **Post date:** [August 14, 2023, 3:45pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/1 "2023-08-14T15:45:45Z")
Continuing the discussion from [.NET: Using newer NEST high-level client against previous version of Elasticsearch](https://discuss.elastic.co/t/net-using-newer-nest-high-level-client-against-previous-version-of-elasticsearch/336613/7): @stephenb we've gotten to point of trying this out now. We've seen that using NEST 7.x against an ES 6.x cluster will work for search operations (🆒) but not for indexing (☹). The error we get there, no surprise, "no type was specified". Of course, we need indexing to also continue to work for our application. So, one last ditch question to see if we can avoid an outage in order to roll the cluster upgrade and then deploy the new code: Could you see if someone on the NEST team could tell me if there is there some compatibility mode available or some strategy we could use to deploy NEST 7.x code while still on ES 6.x? Perhaps some C# extension method for `.Type()` that could detect the version of ES or some other clever approach to give us a window to avoid an outage? ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 14, 2023, 4:31pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/2 "2023-08-14T16:31:57Z")
I will take a quick poke and see if I can... but I would not expect anything.. 6.x to 7.x was alway considered "A Breaking Change" .. You could look at the code directly in the repo... for the NEST client it is all open. > **[GitHub - elastic/elasticsearch-net at 7.17](https://github.com/elastic/elasticsearch-net/tree/7.17)** > > 7.17 My first instinct / (admittedly not well though through) is to add a a default pipeline to your indices so that you can add the appropriate `_type` > **[Index Modules | Elasticsearch Guide \[6.8\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/6.8/index-modules.html)** > `index.default_pipeline` > The default [ingest node](https://www.elastic.co/guide/en/elasticsearch/reference/6.8/ingest.html) pipeline for this index. Index requests will fail if the default pipeline is set and the pipeline does not exist. The default may be overridden using the `pipeline` parameter. The special pipeline name `_none` indicates no ingest pipeline should be run. ---
**Author:** ![Thomas\_Doman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thomas_doman/32/11409_2.png) [@Thomas\_Doman](https://discuss.elastic.co/u/Thomas_Doman)\ **Post date:** [August 14, 2023, 10:09pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/3 "2023-08-14T22:09:15Z")
Thanks @stephenb, we've got a pretty simple deployment and have never used Ingest nodes but we're taking a look at that option. Seems like a promising possibility. ---
**Author:** ![stephenb](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stephenb/32/40856_2.png) [@stephenb](https://discuss.elastic.co/u/stephenb)\ **Post date:** [August 15, 2023, 3:26am UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/4 "2023-08-15T03:26:28Z")
You don't need dedicated ingest nodes to use ingest pipelines. Unless you have specifically set up nodes to not be ingest nodes they should run ingest pipelines. Try it. You can create a simple little pipeline and just execute a test. You wanted ideas. That's my idea... At this point .... Not saying it's the best idea but it's the one I got right now 🙂 ---
**Author:** ![stevejgordon](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stevejgordon/32/80912_2.png) [@stevejgordon](https://discuss.elastic.co/u/stevejgordon)\ **Post date:** [August 15, 2023, 8:23am UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/5 "2023-08-15T08:23:36Z")
Unfortunately, there is no compatibility mode for 6x to 7x, and the upgrade is likely to require a short downtime to switch. If you're able to run a 6x and 7x side-by-side and sync the data, you may be able to take advantage of our [namespaced packages](https://www.elastic.co/blog/nest-and-elasticsearch-net-upgrading-your-codebase) to use a 6x and 7x client instance in the same app, but that's often more complex than a timed upgrade of both client and server. Note that we introduced a compatibility mode for 8x to make client upgrades easier so when you're ready for that upgrade, things are smoother. ---
**Author:** ![Thomas\_Doman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thomas_doman/32/11409_2.png) [@Thomas\_Doman](https://discuss.elastic.co/u/Thomas_Doman)\ **Post date:** [August 15, 2023, 2:52pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/6 "2023-08-15T14:52:49Z")
@stephenb @stevejgordon thank you both for your replies. We're investigating ingest pipelines as a potential "no downtime" option though, even if that works for indexing, we'll have to do broad testing to verify that all our other use cases also work (ie. snapshots, rollovers, alias creation, etc.). In the end, some downtime may be the safest, most straightforward way to go. We're definitely looking forward to being able to run NEST 7.x on an ES 8.x cluster. We haven't started the investigation there but we're hoping that's reasonably straightforward. Thanks again for the responses! ---
**Author:** ![Thomas\_Doman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/thomas_doman/32/11409_2.png) [@Thomas\_Doman](https://discuss.elastic.co/u/Thomas_Doman)\ **Post date:** [August 24, 2023, 7:12pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/7 "2023-08-24T19:12:08Z")
@stephenb @stevejgordon turns out that there _ **is** _ a way to get NEST 7.x to play nice with ES 6.x! As I said previously, search works just fine. For indexing, one of our engineers discovered `TypeQueryString` on the bulk descriptor which satisfies ES 6. This puts the type as an HTTP query parameter and it works against both ES 6 and ES 7. We've never used that in the past so I can't speak to it's original intended purpose but, in the event someone else inquires about this, it seems to be working for us across the board. That is, all the "ancillary" functions we use are working as well (ie. alias CRUD, rollover, snapshot, index CRUD). The only footnote so far is that the rollover command succeeds but the NEST 7 library claims it was not a valid response. We can live with this as we roll the cluster upgrades behind the code upgrade but, assuming we don't run into anything else, this will allow us to have zero downtime. I don't know if this use of `TypeQueryString` was intended or is just a happy accident but if it's the former, I'd expect it to be more common knowledge as a compatibility mode during transition. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 21, 2023, 7:13pm UTC](https://discuss.elastic.co/t/net-using-nest-7-x-high-level-client-against-elasticsearch-6-x/340768/8 "2023-09-21T19:13:02Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.