Make AutoFixture a PCL

[ryanhorath]

PCLs are becoming more and more important, and I do not see a reason why AutoFixture should not be a PCL. Sure, users are currently able to create separate .NET 4.5 test projects and use AutoFixture to test their PCLs from that project, but this puts an unnecessary limitation on users (requiring a .NET library project for testing). As an example, xunit.net is a cross platform PCL and thus does not have this requirement. I am willing to make this change as a pull request, but I wanted to throw it out and get feedback first. I opened the solution and found that converting to a PCL would be fairly easy, but involve some decisions on what to do about minor issues. There were 3 main things preventing conversion to a PCL.

1. The newish MailAddressGenerator class internally uses MailAddress from System.Net.Mail, which is not available in a PCL. There are a few options for dealing with this: a) leave this class out of the PCL version, or b) implement a custom MailAddress class in the PCL version, or c) implement a custom version to eliminate the reliance on System.Net.Mail completely. Alternative C is the cleanest solution, but also the most painful, as it would be a breaking change for any current clients using MailAddressGenerator.

2. There is quite a bit of usage of DataAnnotations, which are not available in all PCLs - mainly because Windows Phone lacks the library. However, I am planning on soon uploading a Portable DataAnnotations library to Nuget that uses TypeForwardedToAttribute to select the correct library on different platforms, while supplying a custom library based on a simple port of the .NET DataAnnotations source code for PCLs and Windows Phone. Nuget will correctly select platform-specific packages through the "PCL Bait and Switch Trick" so that the only platform that would actually run my custom implementation would be Windows Phone. This has been a pain point for a lot of people for a long time and I'm not really sure why no one has resolved it yet (as far as I can tell), even though I see a lot of complaints. I have tested it locally with Nuget and everything works. I just need to find the time to finalize it and upload it to Github and Nuget.

3. There are 4 or 5 Exception classes that use the SerializableAttribute and have protected constructors that take a SerializationInfo parameter. These are not PCL compliant. Correct me if I am wrong, but I could not find an actual use for these constructors or the attribute in the AutoFixture code. So, I may just be able to remove those items. If there is some use for them, there is surely a workaround for serialization that would work fine for PCLs.

In general, there are two approaches that could be taken for making AutoFixture work as a PCL. One is to make the current project a PCL. This would introduce some breaking changes mentioned above, but those would be minor. The other option is to introduce new projects for PCL support, duplicating the current project with linked files. This complicates the project structure somewhat, but keeps from making any breaking changes.

Let me know what you think of these suggestions.

[dcastro]

I have little experience developing PCLs, but I suppose all the glue libraries would have to be migrated as well, correct?

Migrating the mocking glue libraries (AutoMoq, AutoFoq, AutoNSubstitute, etc) might not be possible, since most mocking frameworks use System.Reflection.Emit to generate dynamic proxies, which is not available on WinRT. Or perhaps they could be converted to a PCL that does not target WinRT.

[ryanhorath]

That is a good point, and I think makes this less desirable, though still somewhat useful. Most people are using one of the mocking libraries and that immediately means you still cannot use a PCL.

[ploeh]

As a preamble, let me say that I have zero experience with PCLs, so only a vague theoretical understand of the advantages and disadvantages of them.

My only exposure to PCLs so far was when @moodmosaic analysed what it would take to convert AtomEventStore to a PCL, and that turned out to not be practical, although that's a much more recent project.

AutoFixture is originally from 2009, and if there were PCLs around back then, it wasn't a thing. AutoFixture was never designed with PCLs in mind.

If turning AutoFixture into a PCL involves breaking changes, it would have to wait until version 4.

What is the advantage to making AutoFixture a PCL? It's a unit testing library, so does it ever have to run on Windows Phone, or in Windows Store Apps?

this puts an unnecessary limitation on users (requiring a .NET library project for testing)

How should I understand this remark? If you don't use a .NET library project for testing, then what do you do?

[ryanhorath]

How should I understand this remark? If you don't use a .NET library project for testing, then what do you do?

What I meant by that was forcing users to use a full .NET project rather than the project type of their choice (PCL, Xamarin, etc). It's a limitation, but not a big one since the full .NET project should always be available to choose. Given dcastro's point about the unavailability of Reflection.Emit for the mocking libraries, I now think that while the work for this would be fairly trivial for AutoFixture alone, it is not worth the effort since the mocking libraries will be blocked from becoming PCLs. If no one minds, I will just close this issue and maybe keep it on the back-burner of thought.

[ploeh]

Thanks for your thoughts.

FWIW, had we created AutoFixture today, we would probably have explicitly though about this. My apprehension in this matter is that I fear it may not be completely trivial to do. Still, it may be worth considering for the next version.

[ryanhorath]

I reopened this issue after additional thought. There are cases where you cannot use a full .NET library for testing. One such case is Windows 8.1 and Windows Phone 8.1 unit testing. If you wish to test platform features, your unit tests must reside in a "Windows 8.1 Unit Test" project or a "Windows Phone 8.1 Unit Test" project, respectively. xUnit 2 supports this. But AutoFixture is unavailable in these scenarios. In the case of Windows 8.1, the mocking libraries may never be portable due to lack of Reflection.Emit, but other platforms, Windows Phone 8.1 included, do support Reflection.Emit. Windows 10 is unifying these two platforms, so that support may again be lost (or gained back, depending on what the Windows 10 team decides), but the same logic likely applies to unit testing Xamarin projects and any future platforms. Thus, I think it would be useful to make AutoFixture a PCL going forward. I would like to open this issue back up and encourage everyone to read the suggested fixes from the original post and comment.

[ploeh]

Closing this issue in favour of tracking it in #404