nuget installed package error

[xarthurx]

Hello, I'm new to this lib and am about to test it due to the fantastic description.

OS: Windows 11
VS: VS 2022

nuget issue

I'm developing some program in C# and installed the library from nuget package management system.
However, unlike other packages, Visual Studio reports:

I'm not sure if this is due to some configuration of Clipper2 in the nuget system or on my side.
This has never happened to me for other nuget packages....

Cloning the repo and compiling the demo has no problem. Only nuget package has this error.

possible .net dependency issue

Based on a comment here: https://stackoverflow.com/questions/73130417/visual-studio-c-sharp-nuget-package-that-was-installed-cannot-be-found-with-usi

It seems this might be caused by Clipper2 is only depending on .NET 2.0, which is very old.
Perhaps targeting .NET framework 4.5+ or .NET 5+ might solve the issue?

type question

Besides, based on the demo file, it seems there is no PathsD defined, but I need to manually do the:

    using PathsD = List<List<PointD>>;

In my own program:

Clipper2/CSharp/Clipper2Lib.Examples/InflateDemo/Main.cs

Line 20 in dbc4020

using PathsD = List<List<PointD>>;

May I ask why is so?

[AngusJohnson]

Firstlly, thank you for the helpful feedback.

WRT the Nuget error, I'll certainly investigate that.

It seems this might be caused by Clipper2 is only depending on .NET 2.0, which is very old.
Perhaps targeting .NET framework 4.5+ or .NET 5+ might solve the issue?

Please understand that i'm not overly proficient in C# (or C++), so I'm somewhat reliant on others for advice to get things right. And I'm rather bamboozled by the number of C# frameworks - .NET Standard, .NET Core, .NET Framework, .NET 5, .NET 6 - and deciding which is the best one for Clipper2. Anyhow, from my readings, it seemed to me that NET Standard 2.0 was the safest option for a cross platform library based on Microsoft's published advice here. Now, I'm guessing that MS's advice there needs updating, and I'm certainly open to other advice as to a better framework (and one that supports more than just the most up to date compilers).

WRT your type question, I don't know how you can avoid adding using PathsD = List<List<PointD>> in all your own units. There's no typedef equivalent in C#, and IIRC there are lots of downsides to creating a class to encapsulate this structure. Do you have a suggestion?

Edit: After reading this page, I'm now wondering if it might be better to change the framework over to .NET 5 (both for the library and for all the support projects)?

[xarthurx]

I'm not entirely sure it is caused by the dependency, but the settings are a bit messed up.

For instance, you use #nullable enable which is a C#8.0 feature, but based on here, this needs at least .NET Standard 2.1 or .Net Core 3.x.

IMHO, since there're a Clipper v1 exist out there, for the Clipper2 it should target a bit higher, use more modern features and care less about compatibility issue.
In fact, .NET Standard v2 has stopped support and Clipper2 should at least target the lowest of a LTS version.
I would say that .NET Core or .NET framework is quite widely used, and developers are aware of that.

[xarthurx]

Update.

My issue was resolved, but I don't know how.
I cloned the repo and switched between several framework, build local version of nuget packages and install/uninstall.
During the process, I also installed several framework from VS Installer.

Then amazingly, the issue disappeared.

For the typedef issue, I would recommend creating a separate class for that, since no one is using PointD outside Clipper2.
I don't know what your downside is exactly.

Cost-wise, this should cost almost nothing in modern computers.

[AngusJohnson]

Hopefully all fixed now (and using List<List<PointD>> etc should no longer be necessary 😁).

[xarthurx]

Hopefully all fixed now (and using List<List<PointD>> etc should no longer be necessary 😁).

No, what I mean by creating a separate class is on the library side. If you agree, you should add that to Clipper2 so that we as the users will not need to do the using part.

[AngusJohnson]

No, what I mean by creating a separate class is on the library side. If you agree, you should add that to Clipper2 so that we as the users will not need to do the using part.

I'm afraid I don't understand what you're suggesting.

[xarthurx]

WRT your type question, I don't know how you can avoid adding using PathsD = List<List> in all your own units. There's no typedef equivalent in C#, and IIRC there are lots of downsides to creating a class to encapsulate this structure. Do you have a suggestion?

I'm suggesting to create a class for that. Unless you have really specific downside, which I currently cannot see.

Edit: After reading this page, I'm now wondering if it might be better to change the framework over to .NET 5 (both for the library and for all the support projects)?

I agree.

[AngusJohnson]

I'm suggesting to create a class for that.

This is what I've done, and what I thought you were suggesting:

  public class Path64 : List<Point64> 
  {
    public Path64(int reserve = 0) : base(reserve) { }
    public Path64(Path64 path) : base(path) { }
  }
  public class Paths64 : List<Path64>
  {
    public Paths64(int reserve = 0) : base(reserve) { }
    public Paths64(Paths64 paths) : base(paths) { }
  }

Do you have something else in mind?

Edit: After reading this page, I'm now wondering if it might be better to change the framework over to .NET 5 (both for the library and for all the support projects)?

I agree.

I made those changes yesterday 😁.

[xarthurx]

Edit: After reading this page, I'm now wondering if it might be better to change the framework over to .NET 5 (both for the library and for all the support projects)?

I agree.

I made those changes yesterday 😁.

Hmm, interesting... I'm using .net framework 4.8 for the project that uses Clipper2.
Changing the Clipper2 to net5 dependency makes it incompatible with net48...

Im'not an expert in those frameworks either... need some help from others here.

Perhaps .NET Core rather than .NET? (It seems .NET is for web app, and core is for cross-platformandframeworkis for windows application only.) Or just back toStandard 2.1`...

Is it even possible to do "either/or" multidependency?
Below is a package I found on nuget that I used in my system:

[SebastianDirks]

@AngusJohnson Would it be possible to still target netstandard2.0 as well? I am using Clipper2 in NetFramework4.8 currently in Version 1.0.0 and an update of the Clipper2 package to 1.0.4 is not possible since .NetFramework (any version) does not support netstandard2.1 at all.
There should not be any downside to multiple target frameworks as long as Clipper2 is not using any C# language features that are not included in NetStandard2.0 [Visual Studio will warn you if you try that on multi-target projects]. This target framework gives the library broad compatibility with .Net versions.
The Overview by Microsoft you linked still holds true for older frameworks, .NET Standard 2.0 is not deprecated (yet).
With NetStandard2.0 you are backwards compatible until .NetFramework 4.6.1 and .Net Core 2.0 from 2015, anything older is officially depricated by Microsoft. That is why we use netstandard2.0 in our Open Source Projects.
Just swap <TargetFrameworks>netstandard2.1;net5.0</TargetFrameworks> with <TargetFrameworks>netstandard2.0;netstandard2.1;net5.0</TargetFrameworks>, should be no problem since V1.0.0 worked with NetStandard2.0.
I would recommend dropping support for netstandard2.0 only when Microsoft drops it as well, which has not been anounced to happen yet, to maximize the library reach and portability.
Thanks for the amazing library, clipper is really fast and reliable.

[AngusJohnson]

I really need advice from experienced C# developers on the best way to package Clipper2 for Nuget.

[SebastianDirks]

@AngusJohnson I'm somewhat experienced in C# (about 5 years) and will try to help.
The .NET versioning was really confusing and inconsistent in the past, with .NET Framework for Windows and .NET Core for everything else. NETStandard was the first (and even more confusing) try by Microsoft to unify that mistake, by creating ANOTHER standard to target.
Starting with .NET5.0 MS finally did the right thing and it is backwards compatible with everything, you can use .NET Framework, Standard or Core assemblies in it. But as always, it will take years for all software and dependencies to update (We ourselves can not yet switch to .NET 5.0 because of an dependency/license).
As long as the older software is still around, libraries that want to be broadly compatible should target the smallest common denominator, which is currently NETStandard2.0 since it works with everything released after 2015, including .NET 5.0 and 6.0.

Regarding the original issue here: There is no way retargeting to .NET5.0 could have fixed xarthurx issue. The critical information missing is what .NET version his project is targeting. The Visual Studio error if the target framework is wrong reads something like "Package XXX is not compatible with netstandard2.0 (.NETStandard,Version=v2.0). Package XXX supports: netstandard2.0 (.NETStandard,Version=v2.0)". Nuget will prevent install of that package in that case.
The file not found exception sound more like a build system hickup, where the Nuget dependency was not copied to the output directory of the command line program correctly.

[xarthurx]

I believe @SebastianDirks is correct and more experienced than me.
Thank you for the explanation.

[AngusJohnson]

Thanks Sebastian. I guess the question is what would you recommend going forward?
Currently Clipper2 supports 2 target frameworks - netstandard2.1 and net5.0,
Should I change this to netstandard2.0 and net5.0, or just change it back to netstandard2.0?
Or something else? Cheers.

[SebastianDirks]

I think I would recommend just going back to NetStandard2.0.

Performance-wise the Just-In-Time Compiler is choosen based on the target of the project that is consuming Clipper2 library and optimization is also performed just in time or in NET6.0 even while running with the new Profile-guided optimization (PGO), C# differs from C++ here.
This means that you can get all the performance upgrades of the .NET6 JIT on NetStandard2.0 libraries as well.
The only solid reason for breaking compatibility in my opinion is if there are C# language features in newer versions that you want to use AND that are important enough to break backwards compatibility. Since your code right now is fully compatibel with NetStandard2.0, I don't think that would be worth it for clipper.
Multi-Targeting is useful if you want to target multiple frameworks that are not compatible and can't use NetStandard.

[AngusJohnson]

I think I would recommend just going back to NetStandard2.0.

OK, thanks again Sebastian. I'll revert the library to back to netstandard2.0 in due course .
(It may take me a few days as I'm kind of juggling other things ATM.)

[JimBobSquarePants]

This means that you can get all the performance upgrades of the .NET6 JIT on NetStandard2.0 libraries as well.

Bear in mind however that NetStandard2.0 limits the APIs available to you.

Say for example you wanted to use SIMD somewhere the codebase. You'd need to multitarget to add NET6 (Don't target NET5 as it's out of support)