lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Meyers <Aaron.Mey...@microsoft.com.INVALID>
Subject Strong named assemblies for Lucene.Net 4.8
Date Mon, 11 Sep 2017 19:33:30 GMT
tl;dr Are there any plans to strong-name the Lucene.Net 4.8 assemblies in the beta Nuget packages?
Is there some specific investigation needed that I could do? Any timeline for the next beta
release? And does anyone know why 4.5.1 was chosen as the target framework for Lucene.Net
4.8?

Quick intro: I'm an engineering lead for the language understanding engine underlying the
"Q&A" natural language query feature in Microsoft's Power BI product (internally known
as "Lucia"). We would like to start using Lucene.Net to implement our index of the user's
database string values (replacing current internal solutions which have some drawbacks). Our
scenario is rather different from the typical application of Lucene but still needs much of
the same underlying algorithms/features.

I have a working implementation over Lucene.Net 3.0.3 but recently discovered that Lucene.Net
4.8 supports both store compression and memory-mapped files which would be useful for our
scenario. Additionally, I came across this blog post<http://code972.com/blog/2016/07/98-lucene-net-4-8-is-in-beta-and-we-need-your-help>
which suggests that Lucene.Net 4.8 should be a good option even in its current "beta" form.

As I've started working with Lucene.Net 4.8, I hit two early roadblocks:

  1.  All of our assemblies are strong-named but the current Lucene.Net 4.8 beta packages
on Nuget are not strong-named
  2.  Our codebase currently targets .NET 4.5 but Lucene.Net 4.8 targets 4.5.1

For 1), I was able to build a strong-named version of Lucene.Net 4.8 by cloning the git repo
and using the Lucene.Net.snk included in the repo. I had to comment out these lines in the
AssemblyInfo.cs for Lucene.Net (I haven't tried to build any other assemblies yet - for our
usage, we'll probably only need the core Lucene.Net.dll as we'll provide our own analyzers
and we build queries directly):
// LUCENENET NOTE: For now it is not possible to use a SNK because we have unmanaged references
in Analysis.Common.
// However, we still need InternalsVisibleTo in order to prevent making everything public
just for the sake of testing.
// This has broad implications, though because many methods are marked "protected internal",
which means other assemblies
// must update overridden methods to match.
/*
[assembly: InternalsVisibleTo("Lucene.Net.Tests")]
[assembly: InternalsVisibleTo("Lucene.Net.TestFramework")]
[assembly: InternalsVisibleTo("Lucene.Net.Highlighter")] // For Automaton
[assembly: InternalsVisibleTo("Lucene.Net.ICU")] // For Automaton
[assembly: InternalsVisibleTo("Lucene.Net.Misc")]
[assembly: InternalsVisibleTo("Lucene.Net.Suggest")] // For Automaton
[assembly: InternalsVisibleTo("Lucene.Net.Tests.Analysis.Common")] // For Automaton
[assembly: InternalsVisibleTo("Lucene.Net.Tests.Highlighter")] // For Automaton
[assembly: InternalsVisibleTo("Lucene.Net.Tests.ICU")] // For Analysis.Util.TestSegmentingTokenizerBase
[assembly: InternalsVisibleTo("Lucene.Net.Tests.Misc")]
[assembly: InternalsVisibleTo("Lucene.Net.Tests.QueryParser")]
[assembly: InternalsVisibleTo("Lucene.Net.Tests.Cli")] // For lucene-cli
*/

I didn't see any issue in JIRA for this comment. Does anyone have more context on the problem?
I don't recall any issues with unmanaged references and strong names (we have both unmanaged
references from C# DLLs and Managed C++ DLLs in our codebase) but might not fully understand
the comment. I could look into this further but wondering if anyone has more information before
I try to start blind.

For 2), I also changed the target framework in the assembly I built to temporarily unblock
our development. We are planning to move to 4.5.2 target since both 4.5 and 4.5.1 haven't
actually been supported since 2016. I'm curious though why 4.5.1 was targeted specifically
for Lucene.Net since there weren't many significant changes in that version? In any case though
this shouldn't be a blocker for us (while we'll do some development on the 4.5 target at the
moment, we're of course running 4.6 or later on our development machines so I don't expect
any differences between 4.5 and 4.5.1 target).

Two other questions:

  1.  I've seen mention recently that another beta release is planned soon. Any timeline on
this? We can ship a strong-named version of Lucene.Net built ourselves but would prefer an
official release if possible. I'm assuming that when the strong name is added to the Lucene.Net
assembly it will use the Lucene.Net.snk already present in the repo so we should go ahead
and use that key as well?
  2.  The blog post referenced above also mentioned that a significant amount of contribution
to Lucene.Net 4.8 was done by Microsoft employees. Does anyone have names or contact info
for some of these people? I would love to reach out internally to understand these contributions
and how Lucene.Net 4.8 is being used elsewhere at Microsoft as this will help us coordinate
our plans and any potential contributions.

Thanks for your help and all the great work on Lucene.Net 4.8. We're very excited to be able
to leverage this in our product.

Aaron Meyers
Senior Software Engineer
Microsoft Power BI


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