Vincent, Running the tests in Release mode must be done to ferret out the issues that occur when the compiler removes Debug.Assert statements that change state. Apparently, these statements are not removed in Java, so we have to be vigilant about testing this condition in .NET to ensure it will work right without them.
I think it is a good idea to find a better way to do this than the Debuggable attribute - at the time I was just trying to get over all of the hurdles to make the tests run successfully so we could release, and this was the first solution I could find that worked. The tests rely on specific information to be in the stack trace in order to succeed, and the way it is determined is different between .NET Framework and .NET Core. See: Lucene.Net.TestFramework.Util.StackTraceHelper Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyInCommit.Eval() Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyInSync.Eval() Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyOnFlush.Eval() Lucene.Net.Index.TestIndexWriterExceptions.FailOnlyOnTermVectors.Eval() As long as we can find a way to make these tests work, I have no issue with changing it. IMO, using stack trace information is a horrible thing to test for, anyway - it would be better to inject some kind of test helper that tracks what phase the index writer is in and read its state directly from the test, but I am not sure how difficult that would be. Perhaps there is a way to use a decorator pattern around the components in question to track whether a specific method is currently being executed...? Thanks, Shad Storhaug (NightOwl888) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Itamar Syn-Hershko Sent: Monday, June 12, 2017 9:45 PM To: [email protected] Subject: Re: Lucene.net release mode Sounds legit to me. Generating and distributing pdb's is the way to go, unless there is something preventing us from doing this. Shad? Connie? -- Itamar Syn-Hershko Freelance Developer & Consultant Elasticsearch Partner Microsoft MVP | Lucene.NET PMC http://code972.com | @synhershko <https://twitter.com/synhershko> http://BigDataBoutique.co.il/ On Mon, Jun 12, 2017 at 4:55 PM, Van Den Berghe, Vincent < [email protected]> wrote: > Hello everyone, > > I'm seeing the following in AssemblyInfo.cs: > > // LUCENENET NOTE: This attribute is required to disable optimizations > so the // > Lucene.Net.Tests.Index.TestIndexWriterExceptions.TestExceptionsDuringC > ommit() > test > // can read the stack trace information, otherwise the test fails. > [assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | > DebuggableAttribute.DebuggingModes.DisableOptimizations)] > > > This effectively disables optimizations in release mode. > However, removing this attribute is removed doesn't seem to affect the > "TestExceptionsDuringCommit" test. Moreover, this test doesn't seem to > read stack trace information, unless there is something that I'm missing. > > If stack trace information is needed in release mode, one could > consider generating PDB information. Yes, optimization will sometimes > cause the information to be incorrect, but the probability of having > bugs in release mode that can't be reproduced in debug mode is relatively > small, IMHO. > > What say the esteemed colleages? > > Vincent >
