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 <[email protected]> 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:[email protected]] > Sent: Friday, September 15, 2017 3:28 PM > To: [email protected] > 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 <[email protected] > .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:[email protected]] > > Sent: Tuesday, September 12, 2017 10:44 PM > > To: [email protected] > > 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 < > > [email protected]> 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:[email protected]] > > > Sent: Tuesday, September 12, 2017 9:28 PM > > > To: Aaron Meyers <[email protected]> > > > Cc: [email protected] > > > 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:[email protected]] > > > Sent: Wednesday, September 13, 2017 5:24 AM > > > To: [email protected]; synhershko; > > > [email protected] > > > Cc: [email protected] > > > 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: [email protected] > > > [mailto:[email protected]] > > > On Behalf Of Itamar Syn-Hershko > > > Sent: Tuesday, September 12, 2017 2:37 AM > > > To: [email protected] > > > 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 < > > > [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<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 > > > > > > > > > > > > > >
