Hi Aaron, With regards to strong naming, please see this: http://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net
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. Cheers, -- 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, Sep 11, 2017 at 10:33 PM, Aaron Meyers < [email protected]> 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<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 > >
