[
https://issues.apache.org/jira/browse/LUCENENET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16060602#comment-16060602
]
Jens Melgaard edited comment on LUCENENET-565 at 6/23/17 9:03 AM:
------------------------------------------------------------------
OK, did some digging.
Right now I am perhaps more confused than ever. (Granted I have been confused
about Owin, AspNetCore etc. for a while now, not really seeing where MS is
headed with it)...
As far as I can tell Owin won't actually be use-able as it seems you can't get
that into .Net Core. (Maybe that changes as of .Net Standard 2.0, where things
can be pulled in though a compatibility shim, but then we need to be sure Owin
does not use anything that is not supported, while doubtful it wouldn't be
fully supported, that is perhaps not an ideal solution)...
AspNetCore 1.1.2 seems to target .Net Standard 1.3 so that certainly runs on
both, (making the name ever so confusing)...
AspNetCore does not implement Owin thought (Owin does not support Core, so duh
i guess... it does align to the same ideas)...
There is however bridge solution that allows you to host Owin middleware and
applications on top of AspNetCore and the other way around, they are not
straight forward though, but at the same time they don't seem to complicated
either, obviously they can only be used under .Net Framework but that wouldn't
matter as it would be the consumers choice.
//RANT ON
With all these new things, .Net Core, .Net Framework, .Net Standard, AspNetCore
- This is giving me a real headache >.<... But .Net Standard gives me hope for
the future, but it seems to be a bumpy and somewhat painful ride before we get
there. Again... Maybe much of that pain is over as 2.0 arrives, but it's not
there yet :S (That will also remove the project.json files again but the
.csproj files will be greatly simplified... back and forth i guess >.<.)...
//RANT OFF
I Think the conclusion is that we either stick with System.Net (I have not
checked if that is possible in terms of a listener) and System.Net.Http (Will
be used with the client regardless of our choice) OR we go with AspNetCore... I
am probably leaning towards the later...
Curiosity question: Will there be any plans to move up to
2.0[https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md](.Net
Standard) ones that is done?... (Considering the amount of API's they have
added)
As for all the "minor" comments... I will focus on the above first, as getting
that in place (or not) is kind of a deal breaker.
Just so you don't think I am ignoring them as changes happen on the http stuff
^^.
was (Author: jmd):
OK, did some digging.
Right now I am perhaps more confused than ever. (Granted I have been confused
about Owin, AspNetCore etc. for a while now, not really seeing where MS is
headed with it)...
As far as I can tell Owin won't actually be use-able as it seems you can't get
that into .Net Core. (Maybe that changes as of .Net Standard 2.0, where things
can be pulled in though a compatibility shim, but then we need to be sure Owin
does not used anything that is not supported, while doubtful it wouldn't be
fully supported, that is perhaps not an ideal solution)...
AspNetCore 1.1.2 seems to target .Net Standard 1.3 so that certainly runs on
both, (making the name ever so confusing)...
AspNetCore does not implement Owin thought (Owin does not support Core, so duh
i guess... it does align to the same ideas)...
There is however bridge solution that allows you to host Owin middleware and
applications on top of AspNetCore and the other way around, they are not
straight forward though, but at the same time they don't seem to complicated
either, obviously they can only be used under .Net Framework but that wouldn't
matter as it would be the consumers choice.
//RANT ON
With all these new things, .Net Core, .Net Framework, .Net Standard, AspNetCore
- This is giving me a real headache >.<... But .Net Standard gives me hope for
the future, but it seems to be a bumpy and somewhat painful ride before we get
there. Again... Maybe much of that pain is over as 2.0 arrives, but it's not
there yet :S (That will also remove the project.json files again but the
.csproj files will be greatly simplified... back and forth i guess >.<.)...
//RANT OFF
I Think the conclusion is that we either stick with System.Net (I have not
checked if that is possible in terms of a listener) and System.Net.Http (Will
be used with the client regardless of our choice) OR we go with AspNetCore... I
am probably leaning towards the later...
Curiosity question: Will there be any plans to move up to
2.0[https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md](.Net
Standard) ones that is done?... (Considering the amount of API's they have
added)
As for all the "minor" comments... I will focus on the above first, as getting
that in place (or not) is kind of a deal breaker.
Just so you don't think I am ignoring them as changes happen on the http stuff
^^.
> Port Lucene.Net.Replicator
> --------------------------
>
> Key: LUCENENET-565
> URL: https://issues.apache.org/jira/browse/LUCENENET-565
> Project: Lucene.Net
> Issue Type: Task
> Components: Lucene.Net.Replicator
> Affects Versions: Lucene.Net 4.8.0
> Reporter: Shad Storhaug
> Priority: Minor
> Labels: features
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
