Dotnet core?

[ch-hristov]

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

[gsvgit]

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]

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

[DashNY]

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

[legnars]

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

[gsvgit]

@legnars hello! Seems, that we still can get problems with CodeContracts (seems that it is not ported to .NET Core: https://github.com/Microsoft/CodeContracts/issues/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]

@gsvgit based on this commentary https://github.com/Microsoft/CodeContracts/issues/493#issuecomment-353752918 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]

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

[gsvgit]

@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]

@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]

@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]

@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]

@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?

[ghost]

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]

@abk-x I’m still running them via .NET Framework, I just removed all references to Code Contracts so far.

---

From: David [email protected] Sent: Tuesday, September 18, 2018 7:36 PM To: YaccConstructor/QuickGraph Cc: Felippe Rangel; Mention Subject: Re: [YaccConstructor/QuickGraph] Dotnet core? (#149)

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.

@legnarshttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flegnars&data=02%7C01%7C%7C5cff010f6fe44fd186be08d61db731f0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636729069980656767&sdata=zN3q0gOG7JvyNDIobDmq3DpABM%2FSxG2aBbPABLnA2LM%3D&reserved=0 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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FYaccConstructor%2FQuickGraph%2Fissues%2F149%23issuecomment-422581019&data=02%7C01%7C%7C5cff010f6fe44fd186be08d61db731f0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636729069980656767&sdata=pB4YKj1GwMYYZe7YLdePw7VQP%2B6wylbhuXL04EOKcKU%3D&reserved=0, or mute the threadhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAYIGgtoAqwBe79XyUgu7eQIByDITBBqFks5ucXV0gaJpZM4JTW7G&data=02%7C01%7C%7C5cff010f6fe44fd186be08d61db731f0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636729069980656767&sdata=Cb8dqHuLLRpT95w2c5lEGMy8F7uG4ngmmAFWYHFTI3Q%3D&reserved=0.

[ArcticLampyrid]

Is there any progress?

[KeRNeLith]

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]

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