-
Notifications
You must be signed in to change notification settings - Fork 73
.NET Core Nuget package #20
Comments
I see there is a folder in the source for this, I'd love to get an official support for it in the Nuget package |
I've created a pull request #21 which includes .NET Core library. |
Does version 1.7.4 has this support in it? |
This issue is blocking this issue: NetTopologySuite/NetTopologySuite#110 How can we more forward on this... anything I can do? Once we have a GeoAPI package supporting netstandard we can move on with NTS. Do we also convert the netcore project here to VS2017 format, similar to what we decided for NTS. |
To be fair, I haven't VS2017 and a lot of ignorance about .netcore and .netstandard. |
I think it must be done. It is the only way forward. Perhaps the new nuget tooling can help. There is Nugetizer 3000 and perhaps Visual Studio 2017 has improved tooling. The free community edition is quite powerful. |
No bad feelings: I'm sure it must be done and I'm sure can offer a lot of added value. |
As I said before, I'm willing to put in the work but we have to agree more or less and I can't publish nugets. I would say:
I would also recommend publish nugets more often, I publish nugets straight from my build server... perhaps we could do that for GeoAPI/NTS too? I publish, obviously, only when tests are all green and according to branch:
It increases # of contributions and bugfixes because there is an immidiate reward. Only the core contributor group decides when to merge to master and publish a 'stable' release. |
I'd like to have some suggestions from @FObermaier , that is actually the core maintainer of the project at this time. To me, I agree with all your suggestions.
I'f it's only a problem of credentials in nuget website, I can share this credentials with you (if @FObermaier agree, too). |
I also have some time to invest in it if needed. I really want to try and migrate my site from .net 4.5 to .Net Core but for this to happen I need GeoApi, NTS, OSMSharp to be in .Net Core as well. |
That is why I'm reluctant to releasing the package as is. I've spend some time on the 1st point but am not finished yet. |
netstandard 1.0 is already on it's way out and being replaced by netstandard 2.0 anyway, there aren't a lot of users using netstandard 1.0 and 2.0 will be supported almost everywhere. Supporting netstandard 1.6 will be the best option AFAIK and supporting 2.0 will be very easy once we've done this. We need to move faster, I can't use NTS/GeoAPI in any of my latest projects or the libraries I publish, it's the one project holding me back and this issue shows there are others with the same problem. What about releasing pre-release packages? We can move a lot faster that way and keep the stable releases the same as they are now. We can test integration with other packages and thus even improve the project overall. |
I have installed and ran VS 2017 over the weekend, I think it's safe to say it continues the csproj line of thought from earlier versions and it's stable enough to work with (and a lot shorter and editable, which is a huge plus). |
@HarelM The issue isn't a project for netcore because there is already one in master, for a couple of months even, the issue is that we can't do the same in NTS because there is no nuget package for it yet. |
It's worth noting that while VS2017 in in RC status, the .NET Core Tooling in it is actually only in alpha/preview if I recall. I am personally avoiding 2017 for .NET Core projects until the tooling catches up. Also, I think targeting the earlier .NET Standards of 1.0 or 1.1 (similar to what was said above by @FObermaier) is the way to go (at least as a first step) unless something from later versions of .NET standard are actually needed. Keeping the target of .NET standard low for dependency assemblies like this is a much better option in my opinion. People who consume it can try for .NET Standard 2.0 if they want as I believe it's all backwards compatible. But if you target 1.6 or even 2.0 with NTS, you end up excluding support for a few platforms. From my understanding of the way .NET Standards works, you should be able to target .NET Standard and eliminate some of the other project folders/files (like PCL) in the source. Don't take my word for it, but it's worth looking into. I would mention for those interested in migrating their existing websites, you can migrate your existing ASP.NET project to use ASP.NET Core and still target .NET 4.x in your code. The two are independant, and then you can migrate the code itself to .NET Core (or Standard) gradually. However, this fact is unrelated is unrelated to the issue. |
I'm not sure I agree with both your claims. The main advantage of migrating ASP.NET web application to .Net core IMO is the cross platform and docker support, and I prefer not to do the migration in two steps since I would need to make sure everything is working twice. |
What about to be more conservative in the official branch and made a single specific fork that targets this kind of issues/improvement like .net standard support and pre-release packages? |
Ok, lets agree then to:
I also think we should build a matrix with what platforms we want to support, support now and how long we want to keep supporting them. |
Was pretty easy, netstandard1.0 just works so that's good... |
@HarelM I think you're missing my point. Looking at the project files for NTS and GeoAPI, they are both using .NET 4.0 Client profile by default. The lowest .NET Standard supports is 4.5. So even with using 1.0 it's still an increase in supported version of .NET. By using .NET Standard 1.1 or 1.3 and higher, you start to drop off support for some platforms. All I'm trying to say is that unless there is something specifically gained through the increase in API coverage of the higher versions, I don't see what the benefit of targeting 1.6 or waiting until 2.0? |
NTS and GeoAPI targets also plain old 2.0, although I think that projects for this is PCL version can be the start point.
…----- Messaggio originale -----
Da: "Nick Albrecht" <notifications@github.com>
Inviato: 25/01/2017 20:08
A: "NetTopologySuite/GeoAPI" <GeoAPI@noreply.github.com>
Cc: "Diego Guidi" <diegoguidi@gmail.com>; "Comment" <comment@noreply.github.com>
Oggetto: Re: [NetTopologySuite/GeoAPI] .NET Core Nuget package (#20)
@HarelM I think you're missing my point. Looking at the project files for NTS and GeoAPI, they are both using .NET 4.0 Client profile by default. The lowest .NET Standard supports is 4.5. So even with using 1.0 it's still an increase in supported version of .NET. By using .NET Standard 1.1 or 1.3 and higher, you start to drop off support for some platforms. All I'm trying to say is that unless there is something specifically gained through the increase in API coverage of the higher versions, I don't see what the benefit of targeting 1.6 or waiting until 2.0 would be since it would?
.NET Standard Platform Support
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I'm not following anymore, all I know is we now have GeoAPI (in the current state of the code) supporting:
What's holding us back? This is amazing, most of these platforms aren't even supported anymore and we are fully up to date with all the new stuff... |
We're perfectly aligned, all platform you lister are the platform actually supported. |
Think we need to keep PCL for a while longer. If we want to remove stuff I would say remove .NET 2.0 - .NET 4.5 because .NET 4.0.3 and higher are supported by the PCL anyway and 2.0 and 3.5 are really really getting old. On the other hand, it's not difficult keeping them around for now. I now:
I also setup an automatic build process on my own build server, published packages here: |
Thanks a lot for your effort @xivk .
|
Hmm, not sure about the *deps.json, I don't include this in my other packages. Why should this be included? I do realize now that the nuspecs aren't 100% correct anymore, will correct this soon. And yes, I don't see any issue with renaming to GeoAPI.dll, will try and do that too... |
1.7.5 prerelease tagged and published on nuget: |
Great!!! when can we expect a NTS .Net core package pre-release? |
@FObermaier 👍 Thanks a lot! @HarelM Now I can get started on doing the same there... |
Considering this closed for now, I still suggest cleaning up the project structure later this year. |
Hello.
There is already a working .NET Core project for GeoAPI. Are there any chances of releasing a nuget package?
The text was updated successfully, but these errors were encountered: