Hello,
would it be possible to use XUnit with Oxygene (netcore 3.1 SDK target) and VStudio 2019 Test runner integration?
Thank you,
Giovanni
Giovanni,
in theory that should just work by adding the appropriate references and using the classes; I know we used XUnit ourselves in there past. Are you seeing any errors, or have you not tried yet?
Hi Marc,
I’m trying but with no success. I’m not able to let runner discover tests even if I use “dotnet test” CLI the systems raise the following message
No test is available in C:_WORK_\XUnitTests\XUnitTestOxygeneProject\Bin\Debug.\XUnitTestOxygeneProject.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.
I’m also tryed to use it netcore2.1 target with the same result. It seems I cannot reference to xunit.runner.console because EBuild failed to compile with this message:
E: Package ‘xunit.runner.console:2.4.1’ has no deliverable for platform ‘netcoreapp 2.1’.
Please, if you can, consider the attached project to verify what I did.
Thank you very much,
Giovanni
XUnitTests.zip (32.9 KB)
I’ll have a look on the morning, thanx!
@mh, how far did you get with this ?
I’m trying something similar, but with the xunit.runner.visualstudio and getting the same no deliverables for platform error.
I’ll attach a project created by following the steps in the Xunit Getting Started docs, but using Water (since package references still cannot be managed in VisualStudio). The same error occurs in both Water and VS2019. Using Elements 10…2525
MyFirstUnitTests.zip (5.4 KB)
Curious. the package has neither lib nor ref folders, which is what I look for. it does have a build folder instead — which I have never seen, and does not seem consistent with how NuGet packages are structured. I’ll consider this “as designed” and a broken package, for now…
Yet this same package works perfectly in an MS C# project.
It doesn’t seem to me that it’s the package that’s broken. I’ve attached the equivalent project created using Visual Studio and MS C# so you can compare.
MyFirstUnitTestsJustWorks.zip (672 Bytes)
I believe you. Yet, nuget packages are supposed to have lib and/or ref subfolders, and this one doesn’t :(. I’ll see what I can do to hack around this, tomorrow.
This seems applicable ?
https://natemcmaster.com/blog/2017/11/11/build-tools-in-nuget/
It looks like you add a targets file to the project and treat build like lib
EBuild does not and will not support MSBuild .targets and tasks, by its very nature. But I’ll have a closer look tomorrow, to see what’s actionable here.
This article also sheds some light I think… https://endjin.com/blog/2020/04/dotnet-csharp-teamwork-share-project-config-with-common-nuget-build-asset-packages
TL;DR (if I understand correctly): The build folder may contain targets or props which are processed as part of the containing project, before (props) or after (targets) the project itself.
In the case of xunit.runner.visualstudio there are only props, no targets, and I guess there are no libs or refs in this package because the package contains only pieces needed at build time.
RIght, but thats irrelevant here. The problem is you want to link to there dlls shipped in build, and thats not what build is for,.
EBuild does not and will not support running MSBuild .targets or loading MSBuild properties from NuGet because EBuild, well, is not MSBuild. We use NuGet purely for — as the article puts it:
It might be used mostly for distributing DLLs.
There’s nothing for me tom do here; at best I could ignore the error or turn it into a warning — but then, you might as well just remove the reference altogether. And in fact your project builds fine if I remove it, so I’d consider this the appropriate fix.
The xunit:[2.4.1] package builds file, and thats what matters; I’d consider the xunit.runner.visualstudio:[2.4.2] package to be specific to Visual C#/MSBuild, and unsupported.
VisualStudio is unsupported?!
You just lost a customer. 
Where didi say that?
I’d consider the
xunit.runner.visualstudio:[2.4.2]package to be specific to Visual C#/MSBuild, and unsupported.
You may argue that you were saying that it is this particular package that is unsupported, rather than Visual Studio per se, but it amounts to the same thing when the reason for that lack of support is a lack of support for (part of) the Visual Studio build infrastructure.