lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conniey <...@git.apache.org>
Subject [GitHub] lucenenet issue #191: Migrating Lucene.Net to .NET Core
Date Tue, 15 Nov 2016 19:04:39 GMT
Github user conniey commented on the issue:

    https://github.com/apache/lucenenet/pull/191
  
    @NightOwl888 @synhershko 
    
    > Is it going to be easier to put binaries for both .NET 4.5.1 and .NET Core into the
same NuGet package, or do we need separate packages?
    
    The benefits of using a NuGet package is that a single package can [target multiple frameworks](https://docs.nuget.org/ndocs/create-packages/supporting-multiple-target-frameworks).
It would be better to ship 1 package with a package structure like:
    
    ```
    lib\
       net451\
         Lucene.Net.Core.dll (Built against .NET 4.5.1)
       netstandard1.5\
         Lucene.Net.Core.dll (Built against .NET Standard 1.5)
    ```
    
    >  If so, what needs to happen (if anything) to get this branch (and/or #194) ready
to merge?
    
     #194 can be merged, as long as we are set-up to run NUnit 3 tests. 
    
    For this PR, the things to figure out are:
    
    * Which NuGet packaging option to use (listed below)
    * How to build in TeamCity
    * Double-check that all the tests pass. :)
    
    > Will it be possible to put both the 32 and 64 bit binaries into the same NuGet package?
    > Let's assume that everyone who wants to use Lucene.Net on .NET Core will download
it via NuGet. What needs to happen to get us to that point? Specifically, are there any special
requirements necessary to get the icu-dotnet dependency into the target project? Is icu-dotnet
ready to be deployed via NuGet now, or does something else need to be finished and/or automated
first?
    
    Both 32-bit and 64-bit native binaries are packaged into `icu.net-54.04-alpha.nupkg`.
 Since Lucene.Net.Analysis.Common is a library, which native binary that gets built depends
on the consuming project. If the project is managed using `project.json` (NuGet v3 and/or
.NET CLI toolchain), then the system knows which native dependency (32bit, 64bit, windows
or linux, etc) to restore based on the runtime that is being targeted in the ["runtimes":
{ } section](https://docs.nuget.org/ndocs/schema/project.json#runtimes).  Packages like [libuv](https://www.nuget.org/packages/Libuv/)
use this so one package can work on multiple platforms.
    
    The issue arises when someone is using `packages.config` (NuGet v2) to manage their project
because the system only understands `content`.  Currently, `icu.net-54.04-alpha` package would
drop all its contents into the packages directory, but it would be up to the user to add a
link to those dlls. (I am working on updating that package to create a relative link to the
32-bit and 64-bit dlls in the project system so they are aware of it.)
    
    I am currently hosting the icu.net package on my myget-feed, so it can be consumed.  The
[project](https://github.com/sillsdev/icu-dotnet) that this was forked from builds a minimal
version of icu, which would not work for the Thai analyzers.
    
    > Are you interested in making a build script (or at least the start of one) to not
just build and test both .NET frameworks.
    
    That powershell snippet I have at the top can be used for both building, packaging and
testing with a few modifications.  Is there an existing build script/steps I can look at?
    
    ## Building NuGet Package
    
    There are 2 options to build the NuGet package targeting .NET 4.5.1 and .NET Standard
1.5. 
    
    1. Option 1: Use .NET Core projects
    
        `project.json` is capable of multi-targeting ([How to Multitarget](https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/libraries#how-to-multitarget)).
 In this PR, the .NET Core projects build for both .NET 4.5.1 and .NET Standard when you execute
msbuild on either the `.xproj` or `dotnet build`.
    
        Steps to create .nupkg:
    
        1. `msbuild Lucene.Net.Portable.sln`
        2. For each project, execute `dotnet pack <directory with project.json>`
    
    2. Option 2: Build Lucene.Net.sln and Lucene.Net.Portable.sln
    
        Steps to create .nupkg:
    
        1. msbuild Lucene.Net.sln (Visual Studio 2012)
            * The reason for using VS2012 is because the restore order for NuGet packages
in NuGet v3 (VS2015) is: project.json > {projectname}.project.json > packages.config
> packages.{projectname}.config. So you get into issues like dotnet/corefx#4544 when trying
to build a csproj that has a project.json in it.  There is a workaround using some hackery
described in [this blog](http://stackify.com/using-both-xproj-and-csproj-with-net-core/).
        2. msbuild Lucene.Net.Portable.sln (Visual Studio 2015)
        3. Re-generate nuspec (in case new dependencies were added to any of the projects)
        4. nuget pack <path to nuspec>
    
    __Option 1__
    
    | Pros | Cons |
    | :---- | :---- |
    | Build a single solution | Requires VS2015 with Update 3 and .NET Core SDK |
    | NuGet package is taken care of by .NET Core toolchain | |
    
    __Option 2__
    
    | Pros | Cons |
    | :---- | :---- |
    | VS2012 users can continue working on desktop solution | Requires users who want to test
both solutions to have VS2012 and VS2015 installed |
    | | Have to generate nuspec for .nupkg |
    | | Keep track of two solutions |
    
    > BTW - your test suite status indicates that you haven't yet merged Lucene.Net.Grouping
here. It might be a good idea to ensure there are no issues with it in .NET core 
    
    Thanks for letting me know! I will migrate that now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message