lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <>
Subject Re: Strong named assemblies for Lucene.Net 4.8
Date Mon, 11 Sep 2017 19:37:15 GMT
Hi Aaron,

With regards to strong naming, please see this:

As Lucene.NET is an Apache project, all decisions have to go through the
community and developers so I can't really make a decision here. I do hope
the reasoning above would make sense to all involved. You can sign the
assemblies yourself if needed.



Itamar Syn-Hershko
Freelance Developer & Consultant
Elasticsearch Partner
Microsoft MVP | Lucene.NET PMC | @synhershko <>

On Mon, Sep 11, 2017 at 10:33 PM, Aaron Meyers <> wrote:

> 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<
> 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

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