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 issues. 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. Cheers Alexander -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Itamar Syn-Hershko Gesendet: Donnerstag, 10. November 2016 05:09 An: [email protected] Cc: Connie Yau <[email protected]> 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 http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Lucene.NET committer and PMC member On Thu, Nov 3, 2016 at 11:55 AM, Laimonas Simutis <[email protected]> wrote: > 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 <[email protected]> > 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 icu.net. > > > > https://github.com/sillsdev/icu-dotnet > > https://github.com/apache/lucenenet/pull/191 > > > > 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 [mailto:[email protected]] > > Sent: Thursday, November 3, 2016 9:37 PM > > To: [email protected] > > 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 (http://site.icu-project.org/)." > > https://github.com/niaher/icu4net > > ? > > > > > > 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 > > >
smime.p7s
Description: S/MIME cryptographic signature
