lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: Compilation issues and gotchas
Date Thu, 10 Nov 2016 20:41:33 GMT
Yes, let's make sure Lucene.NET supports 4.5.2, 4.6 and 4.6.1 (and 3.5 if
possible, but that is something we can drop if it's anything more than
trivial to do). The nuget packages we publish should have assemblies
compiled for those platforms.

I will test again with Project Rider once things stabilize. It may as well
indicate something we missed, or a bug outside of our reach. But that's
something we should figure out before the release.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Lucene.NET committer and PMC member

On Thu, Nov 10, 2016 at 2:59 AM, Shad Storhaug <shad@shadstorhaug.com>
wrote:

> Itamar,
>
> I think we should seriously take this into consideration:
> https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-
> ending-for-the-net-framework-4-4-5-and-4-5-1/.
>
> If Microsoft isn't supporting 4.0, 4.5, or 4.5.1 we probably shouldn't
> either (although it wouldn't be a bad thing to target 4.5 or 4.5.1 since
> everything above it is an in-place upgrade). The only thing up in the air
> is 3.5 SP1 support, since that will still go on until 2020. I don't believe
> it would be trivial to support 3.5 SP1 - while we already have ported some
> of the missing pieces such as SortedSet for compatibility, there are other
> places (such as differences in LINQ support and covariant interfaces) that
> will be challenging to put in place. I think we really need to assess
> whether it will be worth the extra effort (but I guess we first need to
> determine exactly how much effort that really is). Is there really a need
> to get people who refuse to upgrade from antiquated versions of .NET to
> also upgrade to the latest version of Lucene? I mean, supporting .NET 3.5
> SP1 is probably not that trivial. But for those still on 3.5 SP1, upgrading
> to 4.5.2 is to take advantage of Lucene.Net 4.8.0 generally by comparison a
> trivial task. And if that is not an option, they still have Lucene.Net
> 3.0.3.
>
>
> As for the indexing issue, not sure what the problem is. Although, I can
> tell you that the majority of the remaining test failures are centered
> around indexing. It seems Connie is working on fixing many of the remaining
> tests on the .NET core branch, so we should probably revisit this after we
> get all of the tests to pass to see if it is still an issue. I am sure we
> will see the number of failures increase again when we add the remaining
> pieces to the test framework to randomize codec, culture, and time zone,
> but once those issues are fixed we should have most of the bugs out, and
> can begin working on any cross-platform issues that remain.
>
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
> -----Original Message-----
> From: itamar.synhershko@gmail.com [mailto:itamar.synhershko@gmail.com] On
> Behalf Of Itamar Syn-Hershko
> Sent: Thursday, November 10, 2016 10:56 AM
> To: dev@lucenenet.apache.org
> Subject: Compilation issues and gotchas
>
> Our nuget/myget packages are released only for 4.5.1 and up. I think we
> should release for as many platforms as we can - what do you think? Connie
> is on the .NET team in Microsoft and might have insights on this.
>
> In addition, I tried running a demo app (
> https://github.com/synhershko/LuceneNetDemo) with Project Rider <
> https://www.jetbrains.com/rider/> on Mac and got the following exception
> when indexing. Shad - what do you think this is?
>
> Unhandled Exception:
> System.NullReferenceException: Object reference not set to an instance of
> an object
>   at Lucene.Net.Store.DataOutput.WriteString (System.String s) <0x51eb2d0
> +
> 0x0006b> in <filename unknown>:0
>   at Lucene.Net.Store.DataOutput.WriteStringStringMap (IDictionary`2 map)
> <0x52998d0 + 0x000a7> in <filename unknown>:0
>   at Lucene.Net.Codecs.Lucene46.Lucene46SegmentInfoWriter.Write
> (Lucene.Net.Store.Directory dir, Lucene.Net.Index.SegmentInfo si,
> Lucene.Net.Index.FieldInfos fis, Lucene.Net.Store.IOContext ioContext)
> <0x52d9dc0 + 0x0011e> in <filename unknown>:0
>   at Lucene.Net.Index.DocumentsWriterPerThread.SealFlushedSegment
> (Lucene.Net.Index.FlushedSegment flushedSegment) <0x529ace0 + 0x0018e> in
> <filename unknown>:0
>   at Lucene.Net.Index.DocumentsWriterPerThread.Flush () <0x51f6940 +
> 0x00b47> in <filename unknown>:0
>   at Lucene.Net.Index.DocumentsWriter.DoFlush
> (Lucene.Net.Index.DocumentsWriterPerThread flushingDWPT) <0x51f4a58 +
> 0x00073> in <filename unknown>:0
>   at Lucene.Net.Index.DocumentsWriter.FlushAllThreads
> (Lucene.Net.Index.IndexWriter indexWriter) <0x51f3568 + 0x000b7> in
> <filename unknown>:0
>   at Lucene.Net.Index.IndexWriter.PrepareCommitInternal () <0x51f2f28 +
> 0x001e7> in <filename unknown>:0
>   at Lucene.Net.Index.IndexWriter.CommitInternal () <0x51f2da8 + 0x000ef>
> in <filename unknown>:0
>   at Lucene.Net.Index.IndexWriter.Commit () <0x51f2d78 + 0x0001f> in
> <filename unknown>:0
>   at LuceneNetDemo.GitHubIndex+<IndexRepositories>c__async0.MoveNext ()
> <0x358ce80 + 0x00427> in <filename unknown>:0
>

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