lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patric Forsgard <pat...@tasteful.se>
Subject Re: Strong named assemblies for Lucene.Net 4.8
Date Thu, 31 Jan 2019 08:54:24 GMT
Hi,

Is it possible to reconsider the strong naming decision of the Lucene.Net
regarding to Microsoft recommend that open source libraries should be
strong named?
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming


// Patric


On Sat, 16 Sep 2017 at 02:41, Daniel Plaisted
<daplaist@microsoft.com.invalid> wrote:

> Note that adding or removing a strong name is a breaking change, in the
> sense that libraries compiled against a non-strong-named version of a
> library won't work with a strong-named version, and vice versa.  So take
> that into account before adding or removing a strong name in a project.
>
> @Shad Storhaug, in response to your questions about tooling perf:
>
> > And if there is any strings you can pull at Microsoft to make the
> tooling run faster, that would also help :). Currently it takes:
>
> > 1. ~10 minutes to discover the tests in Visual Studio 2017 (in VS 2015
> this was a minute or two) 2. ~20 minutes to install the
> SDK/restore/build/pack on the command line (with the project.json and
> preview tooling, this was about 5 minutes) 3. Since there is no way to
> switch target framework in VSTest, we are doing this manually in a linked
> MSBuild file. But Visual Studio usually needs to be closed and reopened
> again when it is changed, which means we are at least 10 minutes away from
> being able to run the tests whenever it is switched. Previously, we had 2
> different solution files. Now it is looking like the most practical thing
> to do will be to make a solution file per assembly/test assembly pair.
>
> 1. For VS Perf issues, use the "Report a problem" feature in VS to report
> this.  You can also file an issue in
> https://github.com/dotnet/project-system
> 2. For command line perf issues, you can file an issue in
> https://github.com/dotnet/cli
> 3. For supporting multiple target frameworks in a test project, there is
> an issue for this here: https://github.com/Microsoft/vstest/issues/624
> You may also want to use Visual Studio's "Report a problem" feature to
> "vote" for the feature.
>
> Thanks!
> Daniel
>
> -----Original Message-----
> From: Darcy Thomas [mailto:darcy@darcythomas.com]
> Sent: Friday, September 15, 2017 3:28 PM
> To: dev@lucenenet.apache.org
> Subject: Re: Strong named assemblies for Lucene.Net 4.8
>
> As a work around I have used
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nuget.org%2Fpackages%2FBrutal.Dev.StrongNameSigner%2F&data=02%7C01%7Cdaplaist%40microsoft.com%7C4ac3b0a602bf48b517dc08d4fc890af5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636411112916061776&sdata=YR0g96BmyAIUett0IMz7mDeLhrDsBlo4YgoTPZYPCgk%3D&reserved=0
> on a past project to strongname (and fix up references) for any unsigned
> dependency.
>
> You just add the nuget package and it takes care of the rest.
>
> The let me GAC (ugh but it was the only way) everything I needed.
>
> On Sat, Sep 16, 2017, 10:07 Aaron Meyers <Aaron.Meyers@microsoft.com
> .invalid>
> wrote:
>
> > Thanks everyone for the replies, and sorry for my delay in responding.
> >
> > I have to agree that having two versions of a package seems like the
> > worst possible scenario and as a library, strong-naming doesn't seem
> > to have any real downsides as consumers can be strong-named or not.
> > Strong naming remains a requirement for my scenario (I did go back and
> > ask but the consensus was that the cost to remove across our large
> > codebase is high and offers no real benefit to justify that cost) so I
> > would love to see that included in Lucene.Net 4.8.
> >
> > I'll follow up on what I need to do from our side to allow me to make
> > contributions to Lucene.Net. I'll need to get my index working with
> > Lucene.Net 4.8 and then I should be able to demonstrate where we are
> > and how to move forward for our release.
> >
> > We've had a lot of performance problems with VS2017 as well. I've
> > specifically worked with some people on the VS team about issues with
> > lightweight solution load but let me see if I can find some contacts
> > for more general performance issues and provide them the info you've
> > given below.
> >
> > Thanks again for all the help,
> > Aaron
> >
> > -----Original Message-----
> > From: Patric Forsgard [mailto:patric@tasteful.se]
> > Sent: Tuesday, September 12, 2017 10:44 PM
> > To: dev@lucenenet.apache.org
> > Subject: Re: Strong named assemblies for Lucene.Net 4.8
> >
> > It exists some intresting comment threads on github where some of them
> > comes from users that during long time have say that strong naming is
> > bad and should bee avoided, but strong naming is less bad then having
> > two version that end's up with other problems.
> >
> > Comment (
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> > b.com%2Faspnet%2FDataProtection%2Fissues%2F245%23issuecomment-30715548
> > 5&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c154486ce87908
> > d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63640878241172
> > 2200&sdata=rPnuZqmVdV4vdnTg6TkyThGgw43gLWA2DitoFI42eRQ%3D&reserved=0
> > )
> > is an answer about strong namer usage from David Fowler and says:
> > > ... that's for package consumers, not producers. Luckily, if you're
> > > using
> > .NET Core, there are no issues. The issue is .NET Framework and the
> > only saving grace is the automatic binding redirects that the build
> > system generates. Package authors realistically all need to be strong
> > named and we
> > (Microsoft) need to fix the .NET Framework to not require binding
> > redirects to truly solve the problems that people hit (I'm fighting
> > for this, again 😄
> > ).
> >
> >
> > Or this
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> > b.com%2FAutoMapper%2FAutoMapper.Collection%2Fpull%2F43%23issuecomment-
> > 312351176&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c15448
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408
> > 782411722200&sdata=hytV5uDqDLvCXtuSbc%2FjTBXbDXAPXpkUj55cYVn5uUs%3D&re
> > served=0 that also have the conclusion from Jimmy Bogard that it is
> > better to only have one package instead of multiple package that.
> >
> >
> > // Patric
> >
> > On 13 September 2017 at 06:57, Daniel Plaisted <
> > daplaist@microsoft.com.invalid> wrote:
> >
> > > Hi Aaron,
> > >
> > > Consider using Strong Namer:
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > > hu
> > > b.com%2Fdsplaisted%2Fstrongnamer&data=02%7C01%7CAaron.Meyers%40micro
> > > so
> > > ft.com%7C7b58a615c154486ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7c
> > > d0
> > > 11db47%7C1%7C0%7C636408782411722200&sdata=64n7kbEA1laUvyUV2i1Y4ep5v%
> > > 2B
> > > Is7xs5LODuENhoD88%3D&reserved=0
> > >
> > > This is a project of mine that signs referenced assemblies as part
> > > of the build process, so you can reference libraries that aren't
> > > signed from projects that are.
> > >
> > > Thanks,
> > > Daniel
> > >
> > > -----Original Message-----
> > > From: Shad Storhaug [mailto:shad@shadstorhaug.com]
> > > Sent: Tuesday, September 12, 2017 9:28 PM
> > > To: Aaron Meyers <Aaron.Meyers@microsoft.com>
> > > Cc: dev@lucenenet.apache.org
> > > Subject: RE: Strong named assemblies for Lucene.Net 4.8
> > >
> > > Aaron,
> > >
> > > BTW - if it were only up to me I would just strong name the
> > > assemblies and not worry about it. But this is something we should
> > > put to a vote since some of the team members have actively spoken out
> against it.
> > >
> > > If you were to commit to doing some contributions (for example,
> > > finishing up the ICU functionality and/or contributing a couple of
> > > UI integration modules described at
> > > https://na01.safelinks.protection.outlook.com/?url=
> > > https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%2F209%23issueco
> > > mm
> > > ent- 321019002&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=flixkESIVLPuCgmRD4HkYBiD%
> > > 2BxJyX0B73gNWJ7sMwhc%3D&reserved=0), it might be an alternative way
> > > to get this done rather than opening up the issue on JIRA. I think
> > > that would be enough to convince the team that this is the best
> > > choice for all of our interests, and would be a more realistic
> > > avenue to get this done for the next beta release. Since we have
> > > very limited resources at our disposal, it would be difficult for
> > > anyone on the team to say no
> > to an offer like that.
> > >
> > > Thanks,
> > > Shad Storhaug (NightOwl888)
> > >
> > >
> > > -----Original Message-----
> > > From: Shad Storhaug [mailto:shad@shadstorhaug.com]
> > > Sent: Wednesday, September 13, 2017 5:24 AM
> > > To: Aaron.Meyers@microsoft.com; synhershko;
> > > itamar.synhershko@gmail.com
> > > Cc: dev@lucenenet.apache.org
> > > Subject: RE: Strong named assemblies for Lucene.Net 4.8
> > >
> > > Aaron,
> > >
> > > Thanks for your interest in Lucene.Net. Answers inline...
> > >
> > > > Are there any plans to strong-name the Lucene.Net 4.8 assemblies
> > > > in the
> > > beta Nuget packages? 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?
> > >
> > > I have no objections and understand this is a serious blocker for
> > > anyone who requires strong naming, however since you are literally
> > > only the second person to ask for this I repeat what I told the last
> > > person. Please, open an issue on JIRA about strong naming and
> > > encourage people to vote on it if it is a blocker for them by
> > > sending an email to our user mailing list (or provide any feedback
> > > why we shouldn't do it). Including information about your expected
> > > user base
> > would also be something for us to consider.
> > > "Because it is a blocker if someone requires it" isn't quite enough
> > > to make a case for a feature that we are not sure anyone uses
> > > anymore, but I'd be happy to advocate for it if we have more
> > > evidence this is still needed by some people.
> > >
> > > Do note that all of our dependencies are strong named AFAIK and I
> > > have setup the versioning with strong naming in mind, so this
> > > shouldn't take a huge effort to do.
> > >
> > > If you are willing to help we would accept a contribution to enable
> > > strong naming *as an option* during build (FEATURE_STRONG_NAME),
> > > which is something that is on my TODO list. And yes, we will be
> > > using the Lucene.Net.snk in our repository for this.
> > >
> > > > Is there some specific investigation needed that I could do?
> > >
> > > See above.
> > >
> > > > I'm curious though why 4.5.1 was targeted specifically for
> > > > Lucene.Net
> > > since there weren't many significant changes in that version?
> > >
> > > This is a question that I have also asked, but the person/people who
> > > made that decision are no longer actively involved in the project.
> > >
> > > > 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.
> > >
> > > This comment is now out of date (actually, the first sentence has
> > > been removed from the codebase since you looked). Basically, we were
> > > unable to strong name Lucene.Net.Analysis.Common previously because
> > > of a reference to ICU4NET, which has since been changed to icu.net.
> > > ICU4NET was a blocker for the SNK, but now it is no longer an issue.
> > > The dependency has also been consolidated into a new project named
> > > Lucene.Net.ICU to prevent the majority of our users from having a 25
> > > MB dependency that a small minority will actually need.
> > >
> > > > Any timeline for the next beta release? I've seen mention recently
> > > > that
> > > another beta release is planned soon. Any timeline on this?
> > >
> > > "Soon" is a relative term, which of course depends on how quickly we
> > > can get through all of the tooling hurdles and bug fixes and how
> > > much help we have to do it. I just sent an email to our dev list
> > > about some of the issues we are facing with failing tests (
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.
> > safelinks&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c15448
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408
> > 782411732208&sdata=%2FlUTbzRBJk3CMQcpAJG4iMKAznEWdq6ObjBDESH6F0g%3D&re
> > served=0
> > .
> > > protection.outlook.com/?url=http%3A%2F%2Fapache.markmail.org%2Fmessa
> > > ge
> > > %
> > > 2F3kgnc7bguo73kmbw%3Fq%3Dlucenenet%2Bdebugging%2Bhelp%2Brequested%2B
> > > fo r% 2Bbeta&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=7r46aivOu45xrq%2FMH5RHKnIUQi
> > > % 2F5V2aElk4Ayg0n44k%3D&reserved=0), and any help you could provide
> > > would also be welcome.
> > >
> > > Basically, there are 4 things I would like to include in the release
> > > that are not yet done:
> > >
> > > 1. We are currently getting random "file in use by another process"
> > > exceptions in the tests, which I don't believe were happening in the
> > > last release. Need to confirm that these issues were not present in
> > > the last release, find out which commit caused them to start, and
> > > decide
> > on a fix.
> > > 2. There is a new .NET Core 2.0 command line tool (lucene-cli) that
> > > needs to be published and packaged in the build (ideally on
> > > Chocolatey, but just zipped and included in the Lucene.Net
> > > distribution
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.
> > safelinks&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c15448
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408
> > 782411732208&sdata=%2FlUTbzRBJk3CMQcpAJG4iMKAznEWdq6ObjBDESH6F0g%3D&re
> > served=0
> > .
> > > protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%
> > > 2Fdist%2Flucenenet%2F&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=LiZiyhv1HMcuz2Ue%2B%
> > > 2B6tUKmoJOzXWEsqlBgTmyPAhU0%3D&reserved=0 failing that).
> > > 3. Include API documentation generation as part of the build. See
> > > https://na01.safelinks.protection.outlook.com/?url=
> > > https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Fpull%
> > > 2F206&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=hfk1qGDYP1HiZMl9bKnBYqhUOqNK
> > > MM
> > > KhVRUymbEOGds%3D&reserved=0.
> > > 4. Change from .NET Framework 4.5.1 to .NET Framework 4.5. This was
> > > also requested previously and according to the requestor the 3
> > > assemblies that would most likely be problematic all compiled fine.
> > >
> > > Ideally, we would also like to get all of the tests passing, too,
> > > but I am not going to hold up the release if the ICU issues are not
> fixed.
> > >
> > > If you know anything about packaging a .NET Core .DLL command line
> > > utility as a Chocolatey package, we could use the help with that as
> > > well. It doesn't seem to be documented anywhere how to make a
> > > package for a .NET Core .DLL (Chocolatey only considers .EXE files by
> default).
> > >
> > > And if there is any strings you can pull at Microsoft to make the
> > > tooling run faster, that would also help :). Currently it takes:
> > >
> > > 1. ~10 minutes to discover the tests in Visual Studio 2017 (in VS
> > > 2015 this was a minute or two) 2. ~20 minutes to install the
> > > SDK/restore/build/pack on the command line (with the project.json
> > > and preview tooling, this was about 5 minutes) 3. Since there is no
> > > way to switch target framework in VSTest, we are doing this manually
> > > in a linked MSBuild file. But Visual Studio usually needs to be
> > > closed and reopened again when it is changed, which means we are at
> > > least 10 minutes away from being able to run the tests whenever it is
> switched.
> > > Previously, we had 2 different solution files. Now it is looking
> > > like the most practical thing to do will be to make a solution file
> > > per
> > assembly/test assembly pair.
> > >
> > > > Additionally, I came across this blog post<
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.
> > safelinks&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c15448
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408
> > 782411732208&sdata=%2FlUTbzRBJk3CMQcpAJG4iMKAznEWdq6ObjBDESH6F0g%3D&re
> > served=0
> > .
> > > protection.outlook.com/?url=http%3A%2F%2Fcode972.com%
> > > 2Fblog%2F2016%2F07%2F98-lucene-net-4-8-is-in-beta-and-
> > > we-need-your-help&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=N%2BCfIu59XAFix1Av8lyjNsDZ24
> > > % 2BkT48ozn8bwwnhpus%3D&reserved=0> which suggests that Lucene.Net
> > > 4.8 should be a good option even in its current "beta" form.
> > >
> > > We are now quite a bit better off from when that blog post was
> > > written. I cannot comment on whether we are more/less stable than
> > > Lucene 3.0.3, but our goal is to get it as stable as Java Lucene
> > > before making the release official, and then work on closing the
> > > version gap. We have a few tests that are newly failing after
> > > upgrading from project.json to .csproj, but considering that we have
> > > nearly 8000 tests that pass I'd say we are on track to meet that goal.
> > >
> > > > 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.
> > >
> > > The only Microsoft employee that I have crossed paths with during
> > > the year or so I have been involved with the project is Connie Yau,
> > > who primarily helped us get on .NET Standard and helped out a lot
> > > with the International Components for Unicode (ICU) part, which
> > > still has a bit more work left to complete. See:
> > >
> > > 1. https://na01.safelinks.protection.outlook.com/?url=
> > > https%3A%2F%2Fgithub.com%2Fsillsdev%2Ficu-dotnet%2Fpull%2F37&data=02
> > > %7 C01%
> > > 7Cdaplaist%40microsoft.com%7C580735c68cf14a53cbe408d4fa5fd0ca%
> > > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408736822148766&sdat
> > > a=
> > > kjTZrwxtB8Yh%2FmdHxcwTuIGzgKeGzvhP3Kbwhr%2BrlEc%3D&reserved=0
> > > 2. https://na01.safelinks.protection.outlook.com/?url=
> > > https%3A%2F%2Fgithub.com%2Fapache%2Flucenenet%2Ftree%
> > > 2Fmaster%2Fsrc%2FLucene.Net.Analysis.ICU%2FAnalysis%2FIcu&
> > > data=02%7C01%7Cdaplaist%40microsoft.com%7C580735c68cf14a53cbe408d4fa
> > > 5f d0ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> > > 7C636408736822148766&sdata=Kl%2BgymY%2BW709PbCv2Pi%2B2%
> > > 2FBA56eAqkdT%2Bk878oXMzeI%3D&reserved=0
> > >
> > >
> > > @Itamar, do you know of any others?
> > >
> > >
> > > Thanks,
> > > Shad Storhaug (NightOwl888)
> > >
> > >
> > > -----Original Message-----
> > > From: itamar.synhershko@gmail.com
> > > [mailto:itamar.synhershko@gmail.com]
> > > On Behalf Of Itamar Syn-Hershko
> > > Sent: Tuesday, September 12, 2017 2:37 AM
> > > To: dev@lucenenet.apache.org
> > > Subject: Re: Strong named assemblies for Lucene.Net 4.8
> > >
> > > Hi Aaron,
> > >
> > > With regards to strong naming, please see this:
> > > https://na01.safelinks.protection.outlook.com/?url=
> > > http%3A%2F%2Fcode972.com%2Fblog%2F2014%2F04%2F68-
> > > ditching-strong-naming-for-lucene-net&data=02%7C01%
> > > 7Cdaplaist%40microsoft.com%7C580735c68cf14a53cbe408d4fa5fd0ca%
> > > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408736822148766&sdat
> > > a=
> > > IIshOtISyeW66VGxZmsKCOz%2FoZ94rv8GX4eChWIVWXs%3D&reserved=0
> > >
> > > 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
> > > https://na01.safelinks.protection.outlook.com/?url=
> > > http%3A%2F%2Fcode972.com&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=aU1F%2BWnorMjjPtIDv3Lju1jTU%
> > > 2BLqOZ8xSJ1cHlacl%2FU%3D&reserved=0 | @synhershko <
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.
> > safelinks&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c15448
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408
> > 782411732208&sdata=%2FlUTbzRBJk3CMQcpAJG4iMKAznEWdq6ObjBDESH6F0g%3D&re
> > served=0
> > .
> > > protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%
> > > 2Fsynhershko&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=TXxKsDztnL0qABRSVyzPgygSFb4z
> > > qG
> > > nyWatozGiwsoc%3D&reserved=0>
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.
> > safelinks&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c15448
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408
> > 782411732208&sdata=%2FlUTbzRBJk3CMQcpAJG4iMKAznEWdq6ObjBDESH6F0g%3D&re
> > served=0
> > .
> > > protection.outlook.com/?url=http%3A%2F%2FBigDataBoutique.
> > > co.il%2F&data=02%7C01%7Cdaplaist%40microsoft.com%
> > > 7C580735c68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011
> > > db47%7C1%7C0%7C636408736822148766&sdata=%2FuFc7HnBUdFzwDF39JiMlPJPvX
> > > i4
> > > p
> > > oUcgMIFYqOxqjs%3D&reserved=0
> > >
> > > On Mon, Sep 11, 2017 at 10:33 PM, Aaron Meyers <
> > > Aaron.Meyers@microsoft.com.invalid> 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<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F
> > > > %2
> > > > Fc
> > > > ode972.com%2Fblog%2F&data=02%7C01%7Cdaplaist%40microsoft.com%7C580
> > > > 73
> > > > 5c
> > > > 68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7
> > > > C0
> > > > %7
> > > > C636408736822148766&sdata=nbyJVm3UNeodmDrq93rQviAZi8gGeBCJ75RelKCp
> > > > Ho
> > > > E%
> > > > 3D&reserved=0
> > > > 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