Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dotnet core? #149

Open
ch-hristov opened this issue Jul 23, 2016 · 17 comments
Open

Dotnet core? #149

ch-hristov opened this issue Jul 23, 2016 · 17 comments

Comments

@ch-hristov
Copy link

Do you have any plans to port Quickgraph to be usable in dotnet core?

@gsvgit
Copy link
Member

gsvgit commented Jul 24, 2016

Yes, we have. But in mind only. First of all we should solve problems with "legacy" PEX-based tests (Issue #5), CodeContracts, and may be with PCL (Issue #6). More over, seems that F# is not fully supported, migration is not actual just now because there are many algorithms implemented in F#. Yes, we can use F# but it is a challenge.

I think that port QuickGraph to .Net Core is good idea, but we will work on it a bit later.

@CumpsD
Copy link

CumpsD commented Nov 30, 2016

Any progress on this? Now that Core is RTM and already iterating over new versions

@DashNY
Copy link

DashNY commented Mar 20, 2017

+1 Would love to use in a .NET Standard library. Thank you.

@legnars
Copy link

legnars commented Aug 29, 2018

@gsvgit hello! How's the progress on this? Any way that I can support the changes to allow .NET Core?

@gsvgit
Copy link
Member

gsvgit commented Aug 30, 2018

@legnars hello! Seems, that we still can get problems with CodeContracts (seems that it is not ported to .NET Core: microsoft/CodeContracts#231) Could you do some "research" to create a detailed list of problems?

If we still have serious problems, we should discuss it. Maybe we should find replacement for PEX and CodeContracts or just drop them out (but the last case is not preferable).

@legnars
Copy link

legnars commented Aug 30, 2018

@gsvgit based on this commentary
microsoft/CodeContracts#493 (comment)
I think it's unlikely that CodeContracts will be supported in .NET Core/VS 2017 any time soon.
(So not only it has problems compiling in core, it's also not officially supported in VS 2017)

@irperez
Copy link

irperez commented Aug 31, 2018

I agree with @legnars. Code Contracts is a legacy framework. Microsoft has moved on from that.

@gsvgit
Copy link
Member

gsvgit commented Sep 1, 2018

@legnars @irperez Well. Let just remove all CodeContracts related stuff. @legnars can you do it?

Next. What about PEX? It is a legacy too. Is it possible to migrate test to IntellyTest? As a first step, we can just save PEX-generated tests.

@legnars
Copy link

legnars commented Sep 1, 2018

@gsvgit Yes, I can!
How should we validate the current contract conditions though? I mean, apparently it is configured to throw exceptions at runtime, so it's not being used just as a static checker, but also as a blocker for bad operations at runtime, right?

I have not worked with PEX before! But if we can run them in .NET Framework it would be validating the same code as in .NET Core, right? So it can wait while we migrate the tests.

@gsvgit
Copy link
Member

gsvgit commented Sep 2, 2018

@legnars Can you look at https://github.com/deniszykov/code-contracts-remover ? It may help us to convert CodeContracts' conditions to "if (cond) then ... else throw ...". I think that it is one of the more appropriate ways of conditions conversion.

On PEX. Yes, it can wait. PEX generates tests for compiled binaries. As far as .NET Core binary format (instructions set) has differences from .NET Framework, it may be impossible to use PEX for .NET Core project. So, my proposal is:

  1. Run PEX on .NET Framework project to generate tests
  2. Save these tests as standard (N|MS|Smth_else)Unit tests
  3. Use saved tests in .NET Core project.

@gsvgit
Copy link
Member

gsvgit commented Sep 2, 2018

@legnars If we support the multitarget project, then we can test it ones. So, yes, let try to save tests for .NET framework build and turn it off (temporary) for .NET Core.

@legnars
Copy link

legnars commented Sep 3, 2018

@gsvgit after removing CodeContracts from the project (and making the proper changes), 11 tests started failing:

  • ChromaticPolinomialAlmostFullGraph
  • ChromaticPolinomialEmptyGraph
  • GraphPartitioningTest1
  • GraphPartitioningTest2
  • GraphPartitioningTest3
  • IsEulerianManyComponentsFalse
  • IsEulerianManyComponentsTrue
  • IsEulerianOneComponentFalse
  • IsEulerianOneComponentTrue
  • IsEulerianTwoVerticesTwoEdges
  • YenZeroCaseTest

They all break on this new line in the UndirectedEdge class:

if (Comparer<TVertex>.Default.Compare(source, target) > 0) {  throw new System.ArgumentException("source", "Comparer<TVertex>.Default.Compare(source, target) <= 0"); }

Except for YenZeroCaseTest, which breaks on this new line in the DijkstraShortestPathAlgorithm class:

if (!(this.VisitedGraph.ContainsVertex(rootVertex))) {  throw new System.ArgumentException("rootVertex", "this.VisitedGraph.ContainsVertex(rootVertex)"); }

Could the new if-then logic be revealing past broken tests?

@gsvgit gsvgit mentioned this issue Sep 5, 2018
5 tasks
@ghost
Copy link

ghost commented Sep 18, 2018

Not to step on any toes,

I am using YC.QuickGraph via nuget in a netstandard2.0 project, and I am not seeing any issues using it (with exceptions of nuget warnings for DotNet.Contracts). It would be interesting to know if the tests are successful however.

@legnars are you running tests via dotnet core? or via .NET? If the former, if you could point me to the repo I am keen to have a look at those failing tests.

@legnars
Copy link

legnars commented Sep 19, 2018 via email

@ArcticLampyrid
Copy link

Is there any progress?

@KeRNeLith
Copy link

Hello,

I forked this QuickGraph repository (here) and put a lot of effort to make it fully .NET Core compliant. I extended support of the library and obviously created targets for .NET Core.

I added a huge set of unit tests that are all green.

I get rid of PEX for unit testing.
I get rid of CodeContracts that apparently are not well compiled in the release on NuGet. I tested and was able to do things that should normally break. So I replaced them by standard assertions and throws.

Side note: this massive refactor was only done for QuickGraph core project for now.

@vidyakdil
Copy link

when can we get Quickgraph compatible for .net core 3.1?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants