Fix PR: Change NUnit v2 to v3

[savornicesei]

The existing PR #259 is mergeable BUT:

• nunit references must be changed to NuGet ones
• NUnit folder from Tools must be deleted
• make sure tests run

This is a must for linux build

     [exec]   Core/SourceControl/Mercurial/StubFileSystemTest.cs(11,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.' [/data/Proiecte/OSS/CruiseControl.NET/CruiseControl.NET_2/project/UnitTests/UnitTests.csproj]
     [exec]   Core/Util/RegistryTest.cs(8,3): error CS0619: 'TestFixtureAttribute' is obsolete: 'The NUnit framework shipped with Mono is deprecated and will be removed in a future release. It was based on NUnit 2.4 which is long outdated. Please move to the NUnit NuGet package or some other form of acquiring NUnit.' [/data/Proiecte/OSS/CruiseControl.NET/CruiseControl.NET_2/project/UnitTests/UnitTests.csproj]

[savornicesei]

@RubenWillems, @obones, @mintsoft
Any ideas why I would have 4 tests failing in VS 2019 and 49 tests failing when running them from the build script (W10, VS2019 CE)?

Most of them are related to xml serialization - the namespaces are not in the expected order.
I've updated the build script to use the latest version of MSBuild available but somehow it still runs on 4.0!?! (it does not recognize ToolsVersion 15.0)
I have installed 4.0 SDK after VS2019 - I might do a VS2019 repair this evening just to be sure references or registries did not go bananas.

Any ideas are highly appreciated.

[RubenWillems]

I've had similar things in the past. can you make a PR with the stuff you have now? so I can help looking into it? In the past it was that somewhere in the build script a line forced an older version of MSBuild to be used, that involved line was duplicated between the build definitions (debug, release, test) and not all places were updated. grts Ruben Willems

…

On Wed, 22 Jan 2020 at 07:32, Simona Avornicesei ***@***.***> wrote: @RubenWillems <https://github.com/RubenWillems>, @obones <https://github.com/obones>, @mintsoft <https://github.com/mintsoft> Any ideas why I would have 4 tests failing in VS 2019 and 49 tests failing when running them from the build script (W10, VS2019 CE)? Most of them are related to xml serialization - the namespaces are not in the expected order. I've updated the build script to use the latest version of MSBuild available but somehow it still runs on 4.0!?! (it does not recognize ToolsVersion 15.0) I have installed 4.0 SDK after VS2019 - I might do a VS2019 repair this evening just to be sure references or registries did not go bananas. Any ideas are highly appreciated. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#286?email_source=notifications&email_token=AAEUZALKJH2G7NXUUSX5C73Q67R6VA5CNFSM4KI4IYUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJSMODA#issuecomment-577029900>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEUZANOLJFYLGNEDCKMLJDQ67R6VANCNFSM4KI4IYUA> .

[mintsoft]

@savornicesei I've seen that before when a reference is updated and has added a binding redirect to the app.config, however the tests haven't had that binding redirect applied as it needs to be added to the nunit runner's .config instead.

On AppVeyor https://ci.appveyor.com/project/ccnet/cruisecontrol-net/builds/30297266 it looks like it's actually working but the attribute order is different now. Is that the same as you're seeing in VS?

[savornicesei]

@mintsoft I'll check tomorrow the assembly bindings.
For the inversed xml namespaces I was thinking of trying FluentAssertion because it has some xml assertions. Here we don't care about the ns indexes, just about their existence.
https://fluentassertions.com/xml/

There are also 2 tests failing because the change datetimes do not match up to the last digit of the milisecond. Did they ever pass?

[mintsoft]

@savornicesei

There are also 2 tests failing because the change datetimes do not match up to the last digit of the milisecond. Did they ever pass?

Which ones? I can't see that in the build output anywhere; there's only the 47 XML tests.

(I think last I built ccnet from source and ran all the tests on VS2015 all the tests were green, but it was a few years ago so I might be wrong)

[RubenWillems]

Hi all the Within keyword can be used to specify tolerances : https://stackoverflow.com/questions/3577856/nunit-assert-areequal-datetime-tolerances/7601507#7601507 DateTime now = DateTime.Now;DateTime later = now + TimeSpan.FromHours(1.0); Assert.That(now, Is.EqualTo(now) );Assert.That(later, Is.EqualTo(now).Within(TimeSpan.FromHours(3.0)));*Assert.That(later, Is.EqualTo(now).Within(3).Hours);* Take a tolerance of 1 second for example. grts Ruben Willems

…

On Thu, 23 Jan 2020 at 01:03, Rob Emery ***@***.***> wrote: @savornicesei <https://github.com/savornicesei> There are also 2 tests failing because the change datetimes do not match up to the last digit of the milisecond. Did they ever pass? Which ones? I can't see that in the build output anywhere; there's only the 47 XML tests. (I *think* last I built ccnet from source and ran all the tests on VS2015 all the tests were green, but it was a few years ago so I might be wrong) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#286?email_source=notifications&email_token=AAEUZAJOL6TZVHFJJ2HSHYTQ7DNEVA5CNFSM4KI4IYUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJVRQKY#issuecomment-577443883>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEUZAJGEMOG4GFERC6FHNLQ7DNEVANCNFSM4KI4IYUA> .

[savornicesei]

@RubenWillems , @mintsoft Thank you for your input!

Everything revolves around this ticket (looking at you, #271 ) so I want to get it done as soon as possible.
Feel free to code review it as the changes have larger scope than the one defined by the issue title.

[savornicesei]

Uhh! Ohhh!

My greatest work's completed!

[savornicesei]

Done