No, it should work for standard queries as well. If you are using an older version of Find, make sure that you are invoking the correct extensions method(as there are two), found in EPiServer.Find.ClientExtensions. 

Update: I have reported this as an issue to EPiServer support:  #25199 : UsingSynonyms results in 0 hits

Note: "MyType" is a standard .NET class added to the index by us. If I try the same on cms pages, UsingSynonyms() works as expected.
We are running Find as on premise solution (Virtual Applicance Raw).

We're experiencing this exact same thing with VA Raw. Issue #25040.

UsingSynonyms returns 4-6 results, while the same search with an identical index (developer index) returns 40-50 hits. Turning off UsingSynonyms gives me all the results I want.

Only IContent-data in the index, just indexed with the default indexing job.

Support team couldn't reproduce after sending them a DB and copy of the source code, so I'm kinda lost. I even added a property to my search page to be able to turn synonyms quickly on and off, just to verify the difference...

@Arve, just a shot in the dark here, but could you see if there is any difference in the indexed data for the two indexes? Use the explore view and do a diff on the same content for the two indexes. 

It seems to contain the same stuff, but the order is different between the two. Could this be the result of different versions of the index or search engine, or is this not important?

The VA Raw-server we're running against gives me the following if i go to the root; (ip:9200/):

{

  "ok" : true,
  "status" : 200,
  "name" : "mysecretindexname",
  "version" : {
    "number" : "0.90.12",
    "build_hash" : "${buildNumber}",
    "build_timestamp" : "NA",
    "build_snapshot" : false,
    "lucene_version" : "4.6"
  },
  "tagline" : "You Know, for Search"
}

Does this seem right or wrong? We initially had another version, but got an upgrade script of some kind a while back. It was just passed on to the operations guys, so I have not neither seen nor executed it myself... :-\

We're running the same version. Aparently, 0.90.12 is Elastic search version, not Find.

Yup. I haven't found anywhere Find reports about its own version.

Client version: "Find .NET API Version: 9.5.0.2999" on all our environments

Another shot in the dark: @Arve, could you specify fields in your query? Using InField(s). Unless you're already doing that... 

Explicitly saying InField(...) makes no difference.. :-\

...soooeh..anything new here? We're going live soon, and I'm supposed to teach people about this in a few days. Which won't be all that fun if one of the only "extra fancy features" they really want to use doesn't work. :-\

I'm using Find 9.6.0.3185 and also experiencing this issue.

Have reported details to EPiServer Support (Request: #26740)

Is there any news or a bug report that I can vote for?

The solution seems to be:

- Make sure the index does not have a default language. Include your languages, but leave the Default Languages-field empty.

- Make sure you're searching specific in fields (or SearchText() etc) - the all-field does not support synonyms.

@Arve: Shouldn't it be "Make sure you're searching on specific fields..."? :)

I have no idea what you're talking about.

(Never write forum answers and talk to people at the same time :) )

Thanks @Arve, that's some useful info no doubt.

Turned out the that, at the moment, developer indexes created at find.episerver.com doesn't support synonyms (at least not for my scenario, not using UnifiedSearch)

Tried creating a few of them thinking that there was something wrong with the index. 

I finally got it working after trying .UsingSynonyms() using a licensed production index (setup by EPiServer Operations)

Some details about my scenario:

- Find Client 9.6.0.3185

- Not using UnifiedSearch

- Searching in specific fields

@Peter: UsingSynonyms is supported when using a developer index.

I have the following working:

 - AlloyDemoKit from github

 - Find Client 9.6.0.3185

 - Using UnifiedSearch 

 - Developer index

However, it's seems like there exists a bug or two connected to the feature.

@Mari OK, so it's working when using UnifiedSearch, that's nice to know.