Make this project use the same version as NetTopologySuite of GeoAPI about projnet4geoapi HOT 8 CLOSED

Derp, I forgot I never got around to updating this one. Sorry. I'll try to fix it tonight.

from projnet4geoapi.

Thanks a lot for the super quick response and the can do approach! :-)

from projnet4geoapi.

I think I fixed this in 2702dc9 by adding a netstandard2.0 target here, which reference the netstandard2.0 stuff in GeoAPI. I've pushed a new -pre004 prerelease and then went ahead and hid the -pre3 one, so you might need to do manual csproj file updates to make sure it gets the new version.

I think GeoAPI can't (meaningfully) target a target framework that's higher than the highest that downstream intermediate projects also target, or else the apps at the end of the dependency chain that want to actually use that highest targeted framework with said downstream intermediate project will run into really obnoxious issues because the intermediate project expects, e.g., GeoAPI.Coordinate to implement the GeoAPI.ICloneable interface, but at runtime it doesn't because it implements the built-in System.ICloneable because we pulled that in from netstandard2.0.

from projnet4geoapi.

In the following line:
https://github.com/NetTopologySuite/NetTopologySuite/blob/develop/NetTopologySuite/NetTopologySuite.csproj#L29
the csporj uses a variable called $(GeoAPIPackageReferenceVersion), is it possible to use this here?
I'm guessing this is some sort of build process that packages everything, wouldn't it be better to make sure this project also gets packed?

from projnet4geoapi.

Are you still having problems? If so, can you please post all your project's PackageReference definitions and/or the packages.config file?

from projnet4geoapi.

the csporj uses a variable called $(GeoAPIPackageReferenceVersion), is it possible to use this here?

It's complicated, because NetTopologySuite and ProjNet4GeoAPI are libraries themselves, and so projects that depend on the latter have transient dependencies on GeoAPI.

If we change something in GeoAPI that doesn't introduce an API-incompatibility with NetTopologySuite or ProjNet4GeoAPI (e.g., we optimize the hash code function of GeoAPI.Geometries.Coordinate, or we add some new interfaces totally separate from the old ones, or we add non-abstract methods to a class or struct), then we don't need to bump up the reference version of the GeoAPI package on NetTopologySuite / ProjNet4GeoAPI, because the package reference for a library specifies what the minimum API-compatible version of GeoAPI is. Dependents further downstream can always grab a later package version, and it should work.

On the other hand, if we make a change like NetTopologySuite/GeoAPI@3613417 that affects the APIs that downstream intermediate projects use, then we do need to bump up that reference version, because dependents further downstream that want to use the new NetTopologySuite / ProjNet4GeoAPI versions will not be able to work with the older GeoAPI.

The mistake I'd made here was assuming that NetTopologySuite/GeoAPI@134354b fell into the first category, because it only added a new target framework. This was naive: if you use both NetTopologySuite and ProjNet4GeoAPI in the same project on a target framework that's supported by netstandard2.0, then the project system will likely do really spooky things (probably fail to build) when it tries to satisfy both libraries' demands for a single assembly to satisfy the demand for a GeoAPI reference.

I'm guessing this is some sort of build process that packages everything, wouldn't it be better to make sure this project also gets packed?

If NetTopologySuite and ProjNet4GeoAPI were definitely the only two permissible implementations of GeoAPI.NET, then I could see an argument for bundling it. But since they're not, and you could (in theory) have a project that only accepts GeoAPI.NET types without concerning itself of exactly how they're implemented, there's a need to have the GeoAPI.NET package serve as an independent (in theory) dependency that NetTopologySuite / ProjNet4GeoAPI use to add their value.

I don't want to try to argue how likely it is that there might exist such downstream projects that only reference GeoAPI.NET without also referencing one or more implementations of the interfaces, because I don't know, and it's kinda beside the point.

from projnet4geoapi.

Thanks for the detailed response.

Are you still having problems?

I Still haven't tried to update the references yet, hopefully today-tomorrow, I'll close the issue if the problem is solved.
Thanks again!

from projnet4geoapi.

Seems like this did the trick, thanks for the quick fix, I really suggest to move out of the pre-release and just bump up the version.
I'm using these pre-releases for about half a year in production server and it seems to be working great.
(haven't migrated to .net standards 2.0 since they have a horrible bug in their file watcher which crashes the server, but that's an entirely different story).

from projnet4geoapi.