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 Thu, 24 Nov 2016 02:29:44 GMT
Github user conniey commented on the issue:

    https://github.com/apache/lucenenet/pull/191
  
    > NOTE: Despite what I said earlier about not wasting effort on .NET 3.5, we should
probably keep that door open depending on how much demand there is for it once we get onto
NuGet. For Spatial4n, I was unable to get a portable library to work as far back as .NET 3.5,
so having a .csproj around for the old stack might be the only solution.
    
    You can create projects targeting .NET 3.5 using .NET Core projects (.xproj).  Here's
an example project.json that'll do it below. And if you want to multi-target your library,
just add another framework in the frameworks section.  The benefit of using .NET Core projects
rather than Portable libraries is that Portable libraries only allows you to use the intersection
of APIs from different frameworks so that it can compile it into a single binary.  Whereas
.NET Core projects, compiles the code multiple times, generating a different binary for each
framework you have in the framework section.  So, you're not limited to the intersection of
all your frameworks APIs.
    
    ```json
    {
      "version": "1.0.0-*",
      "dependencies": {
      },
      "frameworks": {
        "net35": {}
      }
    }
    ``` 
    
    > Ahh, that is something I didn't try before (it says above it won't work with VS2015).
I just tried it and I am also getting errors going down that road - here is a screenshot.
    
    Oh, I see the problem you're having now. Yes, opening Lucene.Net.sln from this PR will
not work in Visual Studio 2015.  I had mentioned that issue before (see quotation below).
 If you want, I can add in that workaround described in the [blog](http://stackify.com/using-both-xproj-and-csproj-with-net-core/)
so Lucene.Net.sln will open in Visual Studio 2015.  I was hoping that long term, we wouldn't
have to keep the csproj files around though because the xproj does everything the existing
solution did and more.  What do you think?
    
    > 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/).
    
    > Here's the file...  restore.zip.
    
    Wow, your restore.dg is missing a lot of project references.  It only has Lucene.Net.Tests.Analysis.Common
as a project to restore.  I've read a bunch of bugs where the .NET Core VS tooling doesn't
behave the same way as the command line tools. To workaround this, can you try:
    
    1. From command line: `dotnet restore`
    2. Open Lucene.Net.Portable.sln
    3. Right-click -> Build Solution (Ctrl+Shift+B)
    
    Do you still get the errors "An item with the same key has already been added..."?


---
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