You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Patric Forsgard <pa...@tasteful.se> on 2019/01/31 08:54:24 UTC
Re: Strong named assemblies for Lucene.Net 4.8
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
<da...@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 <Aa...@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
> > > >
> > > >
> > >
> >
>
RE: Strong named assemblies for Lucene.Net 4.8
Posted by Aaron Meyers <Aa...@microsoft.com.INVALID>.
Yes, I'd like to propose this again as well. I'm willing to make the change (we have a key checked into the repo, just need to use it when building assemblies).
This is still the best practice for any library because you must be strong-named for calling code that is strong-named to take a dependency on you. This is the reason that other open source libraries like Newtonsoft.Json and so on all have strong name.
-----Original Message-----
From: Patric Forsgard <pa...@tasteful.se>
Sent: Thursday, January 31, 2019 12:54 AM
To: dev@lucenenet.apache.org
Cc: Shad Storhaug <sh...@shadstorhaug.com>
Subject: Re: Strong named assemblies for Lucene.Net 4.8
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fdotnet%2Fstandard%2Flibrary-guidance%2Fstrong-naming&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C64c62c00b27b4510434708d68759f1b8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636845217721820206&sdata=zb9ZylzF9r2AZaFPXEUVYpjS3P69rgNEmKdjlz1hARc%3D&reserved=0
// Patric
On Sat, 16 Sep 2017 at 02:41, Daniel Plaisted <da...@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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fdotnet%2Fproject-system&data=02%7C01%7CAaron.Meyers%40mic
> rosoft.com%7C64c62c00b27b4510434708d68759f1b8%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C636845217721820206&sdata=MMNqLO7BT%2FAtVaS9Ay
> 7e2P1Ioq0R7akmpXQjmArsER0%3D&reserved=0
> 2. For command line perf issues, you can file an issue in
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fdotnet%2Fcli&data=02%7C01%7CAaron.Meyers%40microsoft.com%
> 7C64c62c00b27b4510434708d68759f1b8%7C72f988bf86f141af91ab2d7cd011db47%
> 7C1%7C0%7C636845217721820206&sdata=IyI%2Bg99mxChUfUKJTCukazAGH6D1g
> NZ9xL9x4PdAjRk%3D&reserved=0 3. For supporting multiple target
> frameworks in a test project, there is an issue for this here:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FMicrosoft%2Fvstest%2Fissues%2F624&data=02%7C01%7CAaron.Me
> yers%40microsoft.com%7C64c62c00b27b4510434708d68759f1b8%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C636845217721820206&sdata=vgKeWJcMxq
> zyrWvPkKK6SSOSSeX2NxEFXbwdMhxl%2FC8%3D&reserved=0
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> nuget.org%2Fpackages%2FBrutal.Dev.StrongNameSigner%2F&data=02%7C01
> %7CAaron.Meyers%40microsoft.com%7C64c62c00b27b4510434708d68759f1b8%7C7
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636845217721820206&sdata
> =2nDKEBNKEFjv%2B1QEVAEwN9rw%2Fi98uL%2BgqIdtrhy4osw%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%2Fgit
> > hu
> > b.com%2Faspnet%2FDataProtection%2Fissues%2F245%23issuecomment-307155
> > 48
> > 5&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c154486ce879
> > 08
> > d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636408782411
> > 72
> > 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%2Fgit
> > hu
> > b.com%2FAutoMapper%2FAutoMapper.Collection%2Fpull%2F43%23issuecommen
> > t-
> > 312351176&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c154
> > 48
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 08
> > 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%2Fg
> > > it
> > > hu
> > > b.com%2Fdsplaisted%2Fstrongnamer&data=02%7C01%7CAaron.Meyers%40mic
> > > ro
> > > so
> > > ft.com%7C7b58a615c154486ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d
> > > 7c
> > > d0
> > > 11db47%7C1%7C0%7C636408782411722200&sdata=64n7kbEA1laUvyUV2i1Y4ep5
> > > v%
> > > 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 <Aa...@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%23issue
> > > co
> > > 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%7C7b58a615c154
> > 48
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 08
> > 782411732208&sdata=%2FlUTbzRBJk3CMQcpAJG4iMKAznEWdq6ObjBDESH6F0g%3D&
> > re
> > served=0
> > .
> > > protection.outlook.com/?url=http%3A%2F%2Fapache.markmail.org%2Fmes
> > > sa
> > > 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%2FMH5RHKnIU
> > > Qi % 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%7C7b58a615c154
> > 48
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 08
> > 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=hfk1qGDYP1HiZMl9bKnBYqhUOq
> > > NK
> > > 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%7C7b58a615c154
> > 48
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 08
> > 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%2BCfIu59XAFix1Av8lyjNsDZ
> > > 24 % 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&sd
> > > at
> > > 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%7C580735c68cf14a53cbe408d4
> > > fa 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&sd
> > > at
> > > 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%2BWnorMjjPtIDv3Lju1jT
> > > U%
> > > 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%7C7b58a615c154
> > 48
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 08
> > 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=TXxKsDztnL0qABRSVyzPgygSFb
> > > 4z
> > > qG
> > > nyWatozGiwsoc%3D&reserved=0>
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fna01.
> > safelinks&data=02%7C01%7CAaron.Meyers%40microsoft.com%7C7b58a615c154
> > 48
> > 6ce87908d4fa6a6e15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6364
> > 08
> > 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=%2FuFc7HnBUdFzwDF39JiMlPJP
> > > vX
> > > 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%7C5
> > > > 80
> > > > 73
> > > > 5c
> > > > 68cf14a53cbe408d4fa5fd0ca%7C72f988bf86f141af91ab2d7cd011db47%7C1
> > > > %7
> > > > C0
> > > > %7
> > > > C636408736822148766&sdata=nbyJVm3UNeodmDrq93rQviAZi8gGeBCJ75RelK
> > > > Cp
> > > > 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
> > > >
> > > >
> > >
> >
>