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 [email protected] or file a JIRA ticket
with INFRA.
---
