3
Vote

xUnit.net versioning

description

I noticed some strange behavior when getting AutoFixture with xUnit data theories from NuGet.

AutoFixture references 'xunit.extensions, Version=1.6.1.1521, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c' assembly. However, on NuGet the available xUnit.net packages start from version 1.7.0.1540. So NuGet fetched this version instead of the 1.6.1.1521.

At runtime, I get a FileLoadException:

System.IO.FileLoadException was unhandled
Message=Could not load file or assembly 'xunit.extensions, Version=1.6.1.1521, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Source=mscorlib
FileName=xunit.extensions, Version=1.6.1.1521, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c

I think that this may discourage new users from trying AutoFixture because they will have to find the specific xUnit.net version themselves. Shall we upgrade to xUnit 1.7 or 1.8? (personally I would choose 1.8).

comments

ploeh wrote Sep 1, 2011 at 7:29 PM

Yes, it's a problem, but there's no point in upgrading. First of all it would be a perpetual race, and secondly it would be inappropriate according to Postel's Law. AutoFixture.Xunit doesn't need xUnit.net 1.8, so we would artificially cut off people not using the latest version.

It's not a problem with compilation, but with type loading. AutoFixture.Xunit does not require a specific version of xUnit.net, but the test runner apparently does. Any suggestions to resolve this problem smoothly would be much appreciated.

It's easy enough to address with an assembly redirect like described here: http://stackoverflow.com/questions/6505591/autofixture-and-moq-v4 but a more smooth and non-intrusive solution would be better. Upgrading, however, is not really an option for the reasons given above.

baxevanis wrote Sep 2, 2011 at 6:32 AM

I am not aware of many different ways other than the solution described. (However, AFAIK, Moq uses ILMerge and ships with the Castle dependency merged in the same assembly Moq.dll, but this scenario doesn't fit in this case though, I think.)

My point is, right now, anyone new to AutoFixture that gets the package from NuGet will not be able to use it with success inside the Visual Studio with TestDriven.Net add-in. When running tests with TestDriven.Net add-in (in this case with the type loading issue) no exception is thrown. If no exception is thrown, there will be no place to search for help if (the developer is not aware about assembly binding, type loading, etc.).

ploeh wrote Sep 2, 2011 at 7:10 AM

Yes, it sucks. However, if you attempt to run the unit tests with a stand-alone test runner, you'll get a rather descriptive exception message, so the fact that Test-Driven.NET is silently swallowing an exception is actually a bug in Test-Driven.NET, which I'll now go and report :)

I'd also very much like to report the root issue (if it's external to AutoFixture), but I haven't had time to get to the bottom of why it actually happens, so I don't know what the fix would be. I find it strange that one can compile with the combination of xUnit.NET 1.8 and AutoFixture.Xunit, but running the tests fails - but as I said, I simply haven't had time to dig into the root cause of it.

nikmd23 wrote Oct 2, 2012 at 10:58 PM

I have this problem with the R# test runner as well. :(

Hope to see a fix for this soon.

EdvL wrote Oct 3, 2012 at 8:02 PM

quick fix:
executing "Add-BindingRedirect" in the package manager console
for the test project which is using Autofixture
fixes this exception

Sign in to add a comment or to set email notifications