lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shad Storhaug <>
Subject RE: ICU4NET 64bit?
Date Fri, 11 Nov 2016 14:22:27 GMT
Hi Connie,

Maybe this is a naïve question, but do we need to use MSBuild anymore? I mean, doesn't Roslyn
have the capability to compile both the .NET 4.6 and .NET Core stacks? And if we used Roslyn
exclusively for builds, would it help with solving the bitness issue?

Also, ICU4Net is missing the RuleBasedCollator, which is a dependency for the last missing
piece of Lucene.Net.Analysis.Common (Lucene.Net.Analysis.Collation). Using ICU4NET on 32 bit
builds, we won't be able to add this missing piece to the Lucene.Net.Analysis.Common package.
Note that most of the work has already been completed for Lucene.Net.Analysis.Collation on
this branch:

I am not sure if Lucene.Net.Analysis.Collation is critical for the Lucene.Net.Analysis.Common
package release - in the .NET world there is no RuleBasedCollator, so it will most likely
not be missed if this extension for it is not there. But, it would be nice to include it if
we can. Perhaps providing Lucene.Net.Analysis.Collation to the 64 bit release and excluding
it for 32 bit using conditional compilation is an option, although it seems like an uncommon
thing to do.

Another package (important for Lucene.Net release) that is dependent on ICU's (BreakIterator)
is Lucene.Net.Highlighter, which is (patiently) awaiting the resolution of the ICU dependency
before it is ported.


List of (known) sections remaining to port/complete for release:

1. Lucene.Net.Analysis.Collation (Namespace in Lucene.Net.Analysis.Common)
2. Lucene.Net.Highlighter
3. Lucene.Net.Store (Namespace in Lucene.Net.Misc - Native (C++) directories for Unix and
Windows - important??)
4. Lucene.Net.Spatial (currently WIP)
5. Lucene.Net.QueryParsers.Flexible (Namespace in Lucene.Net.QueryParser)

Other useful packages not yet ported that are not critical for release:

1. Lucene.Net.Analysis.ICU
2. Lucene.Net.Analysis.Kuromoji
3. Lucene.Net.Analysis.Morfologik
4. Lucene.Net.Analysis.Phonetic
5. Lucene.Net.Analysis.SmartCn
6. Lucene.Net.Analysis.UIMA
7. Lucene.Net.Demo

Lucene.Net.Analysis.ICU also depends on Although Itamar said that Lucene.Net.Analysis.ICU
is not critical to port for release, would it make sense to port it sooner rather than later
to make sure we have all of the support we need in

Shad Storhaug (NightOwl888)

-----Original Message-----
From: Connie Yau [] 
Sent: Friday, November 11, 2016 6:01 AM
To: Itamar Syn-Hershko;
Subject: RE: ICU4NET 64bit?


I apologise for the delayed response.  In the .NET Core migration<>
I am working on, with the current .NET Core toolchain, it compiles for x64 even if a 32-bit
runtime is specified. :( (It’s a known issue<>
they are not going to fix because of the migration to msbuild.) As a result, the only way
I could get the Lucene.Net.Analysis.Common library running was to change it to use 64-bit
version of<>
that I compiled from the sillsdev/icu-dotnet repository<>.

As an aside, I can create a separate PR which uses x86 version of icu-dotnet that I’ve replaced
ICU4NET with as a solution for this issue.


From: [] On Behalf Of Itamar
Sent: Thursday, November 10, 2016 12:44 PM
Cc: Connie Yau <>
Subject: Re: ICU4NET 64bit?

Ok, let's see what ICU support Shad and Connie come up with. Worst case we can release all
analyzers requiring the ICU packages as a separate package and remove the ICU dependency from
the more commonly used parts.


Itamar Syn-Hershko<>
| @synhershko<>
Freelance Developer & Consultant
Lucene.NET committer and PMC member

On Wed, Nov 9, 2016 at 11:53 PM, Roethinger, Alexander <<>>
Good morming!

I can confirm that this is an issue. Spent two hours the other night trying to deploy my solution
on a Windows Server 2012 VM to no avail. I kept on getting the known Assembly-Loading exceptions
despite setting PATH variable or copying the native DLLs to the Windows directory.

Forking Lucene.Net.Analysis.Common in order to manually remove the Thai-Analyzer and Wordbreaker
is not an option as it defies the advantage of your release packages as well as other compilation

I finally ended up simply removing the assembly references to ICU4NET and ICU4NET.Extensions
from my projects that use Lucene.Net.Analysis.Common and voila, the code still runs and I
could deploy without needing the native DLLs.

While I know that my application would crash if I were to access the Thai analyzer, since
I'm not using it, it seemed safe to proceed that way.

In any case it would be great to get rid of ICU4NET dependency, either by moving the Thai-Analyzer
and WordBreaker to a separate assembly (which only solves the problem partially) or some true
CLR alternative.


-----Ursprüngliche Nachricht-----
Von:<> [<>]
Im Auftrag von Itamar Syn-Hershko
Gesendet: Donnerstag, 10. November 2016 05:09
Cc: Connie Yau <<>>
Betreff: Re: ICU4NET 64bit?

I've had several reports on ICU4NET dependencies mostly on cloud environments - probably due
to the native assemblies that are shipped with it. Let's make sure we are using a solution
that runs on the CLR and work well.


Itamar Syn-Hershko<>
| @synhershko <<>>
Freelance Developer & Consultant Lucene.NET committer and PMC member

On Thu, Nov 3, 2016 at 11:55 AM, Laimonas Simutis <<>>

> Alexander,
> I am pretty sure that is the same code that you linked. I just created 
> a nuget package with all the ICU4C dlls included so that we could 
> reference them in Lucene port via nuget without having to include c 
> libs somewhere else.
> I will need to go back and see where I ended up with the 64 bit port.
> Although as Shad mentions, is this still relevant since for the long 
> term the port are going away from ICU4NET?
> On Thu, Nov 3, 2016 at 10:04 AM, Shad Storhaug 
> <<>>
> wrote:
> > Alexander,
> >
> > Actually, Connie Yau from Microsoft is working on porting to .NET 
> > core, and one of the things that is happening is that she is 
> > switching the dependency from ICU4NET to<>.
> >
> ><https://na01.safelinks.protec
> >
> > et&
> > 09aa4498%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=r8itnCstaCa0FO
> > L6mrSjWa2xYEPFMN0Sat9EQGFdpng%3D&reserved=0>
> ><https://na01.safelinks.
> >
> > nenet%2Fpull%2F191&
> > b5fd4e99406008d409aa4498%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdat
> > a=4L4penTOgo4T0EjS35aviV0m6cK63hxdAyk5JYhP%2FSg%3D&reserved=0>
> >
> > So at this point, making changes to ICU4NET is moot. However, I am 
> > not sure what that means in terms of 64 bit compatibility. Both of 
> > these packages are just wrappers around the ICU4C library.
> >
> > Connie, perhaps you can share what you know? If Alexander is willing 
> > to update that package to work with 64 bit (and fix the issues with 
> > auto-loading), that would be great.
> >
> >
> > Thanks,
> > Shad Storhaug (NightOwl888)
> >
> > From: Roethinger, Alexander 
> > [<>]
> > Sent: Thursday, November 3, 2016 9:37 PM
> > To:<>
> > Subject: ICU4NET 64bit?
> >
> > Dear Devs,
> >
> > can anyone point me to the source-code (if available) for the 
> > "ICU4NET packaged together with ICU4C 55.1 32-bit release"
> > package available on Nuget and provided by Laimonas Simutis?
> >
> > Or is this the same code as in
> > "Simple wrapper for ICU4C (<>."
> ><
> >
> >
> > C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=vurBYCkwS1BiswMx2vg2%2B4
> > gLu92ReatRBS7A3Fgni2w%3D&reserved=0>
> > ?
> >
> >
> > I would like to build a 64bit (resp. AnyCPU) version using the 64bit 
> > DLLs available at ICU-Homepage.
> > I believe Laimonas had mentioned in a post that he apparently had 
> > already successfully tested a 64bit version.
> >
> > Are there plans to provide 64bit support for ICU4NET?
> > (I know there's a discussion going regarding the dependency on
> > ICU4NET)
> >
> > Thanks
> > Alexander
> >

View raw message