lucenenet-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent Boogaart <>
Subject Re: Source not in solution
Date Sat, 07 Nov 2015 11:57:17 GMT
Thanks Simon.

So, just to be clear, there are no usable branches of Lucene.NET post 3.0.x? I was assuming
there was something usable because of this post:,
wherein Peter Bailey says be has used a later build to avoid the spurious exceptions I mentioned
in point #1.

Assuming there is nothing post 3.0.x I can use, my recourse here will be to simply use the
project as is and debug it to try to determine why I’m getting the second issue. I can live
with the first-chance exceptions, but the second issue is a blocker.

FWIW, the changes I needed to make to the core project to get it to build for iOS were all
to do with AppSettings, because ConfigurationManager simply doesn’t exist. Consequently,
there are some knock-on changes to Contants.cs and StringHelper.cs. One other thing I had
to do when I was using that project was to manually add the snowball analyzer in, since it
was omitted.


> On 7 Nov 2015, at 6:12 PM, Simon Svensson <> wrote:
> Hi Kent,
> Based on the core/Util/Version.cs of chrigu-ebert/Xamarin-Lucene, it's
> version 3.0.x. The latest stable version of Lucene.Net <> is
3.0.3, so his
> sources seem correct. (I have, however, issues with his non-documented
> approach to modifying the source code. Are these changes that perhaps
> could go back to the real Lucene.Net <> source?)
> There are no newer stable code for you to use. I presume you tried the
> master branch of apache/lucenenet, but it's currently an in-progress
> port of Lucene 4.8 and is in no ways complete.
> The MultiFieldQueryParser (and the QueryParser) are not longer present
> in the core, but moved to the [java-package
> org.apache.lucene.queryparser.classic][1]. This means that we'll have in
> a separate project once it's ported, but there is to timeline for that.
> // Simon
> [1]:
> On 07/11/15 07:50, Kent Boogaart wrote:
>> OK, I’ve changed tact. I’m instead building the Lucene.Net source
>> whilst targeting Xamarin platforms.
>> I can get the core project to build with a few minor changes.
>> However, the Lucene.Net solution appears to be completely missing
>> MultiFieldQueryParser. Where has this gone? Can anyone please
>> enlighten me - I’m struggling to reconcile the state of this project
>> against the Javadocs for Lucene itself (which shows that
>> MultiFieldQueryParser is still a thing).
>> Thanks, Kent
>>> On 7 Nov 2015, at 11:06 AM, Kent Boogaart <>
>>> wrote:
>>> Hi,
>>> I’m using Lucene from a mobile app (using Xamarin) via this
>>> project:
>>> < <>>
>>> However, I would like to upgrade to a more recent Lucene.NET <>
>>> < <>> to address two issues I
have. Briefly, the two
>>> issues I have are:
>>> 1. First-chance exceptions are raised on every search, such as
>>> “IOException: read past eof” and “LookaheadSuccess: Error in the
>>> application” 2. On a brand new install of my app, the first attempt
>>> to search results in an exception: "System.IO.IOException: Invalid
>>> handle to path
>>> "/private/var/mobile/Containers/Bundle/Application/EDDBC7B3-E54E-46CC-BC51-0CDE18A066F4/[Unknown]””
> My understanding is that later versions of Lucene.NET <>
> < <>> have addressed #1. By upgrading
I hope to also
> address #2, though even if I don’t I will be in a good position to look
> deeper into the matter.
>>> As a starting point, I forked the Xamarin Lucene.NET <>
>>> < <>> project, cloned Lucene.NET
>>> < <>>, and wrote a little script
to copy like-named
>>> files from the Lucene.NET <> < <>>
source to the
>>> Xamarin Lucene.NET <> < <>>
source. Catastrophe!
>>> It became evident that there are a lot of files in the Lucene.NET <>
>>> < <>> code base that aren’t
even part of the main
>>> solution. I’m trying to understand why this is.
>>> An example of such a file is StopwordAnalyzerBase.cs. It resides
>>> under src\Lucene.Net.Analysis.Common\Analysis\Util, so going by the
>>> readme it should be part of the core code base. However, it is not
>>> present in the solution.
>>> Can anyone tell me why this is?
>>> Thanks, Kent

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message