Is it possible to use Fixie in netcoreapp1.1?

[siberianguy]

I'm trying to make Fixie work in a netcoreapp1.1 project. First, I followed experimental branch samples code and tried to add net45 framework in addition to netcoreapp1.1 but it makes my other dependencies (that do not support net45) fail during restore. I also tried to add net45 to imports of netcoreapp1.1 but it doesn't seem to work. Did I miss something or it's just not supported so far?

[plioi]

I wish I had a better answer, but Fixie can't be used against netcoreapp yet. The history is complicated:

As described on the #145 (comment) the experimental 2.0.0-alpha-0001 release only works when your projects target the regular framework (like net45) and not the cross-platform netcoreapp1.1. I understand that may be confusing, since the experimental branch is doing exactly that!

After the 2.0.0-alpha-0001 release, I made a lot of progress in that branch towards cross-compiling against netstandard/netcoreapp. The biggest obstacle to that support, though, involved some extremely regrettable changes to the build script and the ability to realistically work in the solution in Visual Studio at all. (dotnet test's ability to find my exe required that even my own self-test projects refer to Fixie as a NuGet package rather than just referencing the projects in the solution, so imagine how hard it would be to make a change and see it work within that solution.) As I was about to get into making that situation workable, Microsoft announced that they were completely gutting dotnet test in both how it works and what it can do (it appears even the xUnit team is abandoning it as permanently broken by design), while also introducing a Visual Studio 2017 dependency (which hasn't RTM'd yet).

Alas, those changes were so disruptive that they invalidate further work within that experimental branch, and I'll have to try again as VS2017 and the new dotnet test model solidifies. All of the useful aspects of the experimental branch now live in the develop branch, but the actual .NET Core support along that branch is in a holding pattern for the dust to settle for real this time.

I'm closing this issue in favor of #155 where that future progress can be tracked.

[siberianguy]

Thanks for the answer! I will be the first one to test VS2017 support.

Ironically I was motivated to try Fixie after reading your article but I guess I'll have to wait for a while.

[seesharper]

I have said this before and I say it again. I really hope that this project makes it to .Net Core as it is the smoothest testing framework ever. Keep up the excellent work

[siberianguy]

Agree. Fixie + Autofixture = the best testing experience ever. I've been doing it wrong for so many years... And to make Fixie more mainstream we have to create a stable, maintainable Resharper plugin.

[plioi]

Thanks for the vote of confidence! When VS2017 comes out in the next few weeks, I'll pick this up again. My main development branch includes a lot of the necessary changes to support cross-compiling (there are a few places I'll need to add a #if for instance), and folks are even having some success using version 1.x with the VS2017 RCs, when targeting the regular framework, so we have reason to believe it will go a lot smoother this time around.

[seesharper]

Any news on this?

[plioi]

Right now, I'm bringing the solution up to speed with VS2017's project file formats (targeting the regular framework as a first step). My biggest obstacle comes with nuget packaging under the new tooling. "dotnet pack", in general, wants people to put only one dll in any package, and I'm first seeing if I can avoid that like the plague. I want to continue to support the "Just install Fixie and go" approach that's worked to date, unlike the "Install X, and install Y, but not the wrong version of Y, and maybe sometimes Z" scenario that other tools are doing as a result of the "one dll per package" pressure. After much searching, I've found one bit of evidence that it's still possible to build a package from a nuspec file (which gives you more control over what all gets included in a package): https://github.com/NuGet/Home/wiki/Adding-nuget-pack-as-a-msbuild-target#packing-using-a-nuspec I'm making progress using those command line arguments, but some of the error messages I'm getting along the way are extra confusing and almost comical :)

[siberianguy]

Am I the only one who feels like the problem with Fixie at the moment is more fundamental? At the moment it really feels like one-man side project and we're not really moving forward. And it's sad as all those xunit-driven test runners are outdated crap (I said it). If we want to make Fixie more popular (Resharper plugin?), we need to build a community of core contributors. I believe there're people around who're happy to get their hand dirty but they don't know how to start. My suggestion: create a pull-request with VS2017 support implementation where other people could contribute ideas and code.

[seesharper]

Why don't you just use NuGet with a nuspec file to pack Fixie? Then you have all the options to pack it any way that you like :)

[jbogard]

I would avoid nuspec as much as possible - it gets quite confusing when you can set things in your project file vs. not. I try to use dotnet pack as far as I can, the tooling is just so much nicer for it. @plioi while I think that might be a noble goal - I don't think that's actually a better end-user experience. If you want to have a "catch-all" package, you can create that directly. That's what the .NET team does for example with referencing netcoreapp.

I don't know of an OSS project that has regretted splitting packages out. It's much nicer to understand dependencies etc. when you do that.

So Fixie might depend on Fixie.Core and Fixie.TestDriven etc. if you wanted.

[plioi]

Ah, I hadn't thought of it like that. That makes sense. My goal is, as you're getting at, a simple installation scenario. I'm a little bugged by the idea of implementation details (like a common library used by all runners) being exposed as a whole public package, but if a catch-all package is all people really need to think about installing, yay.

[plioi]

@seesharper NuGet 4 is in a weird state, which makes nuspecs harder to work with. Using NuGet.exe, even the latest version, gets tripped up when the csproj in question is the new compact format. You can indicate a nuspec using "dotnet pack .... /p:NuspecFile..." which I do think I have working at last, but to Jimmy's point, I should probably just embrace the New World.

[plioi]

Let's take the discussion here: #155 The first item on the to-do list is marked Up for Grabs.