Support for CoreCLR

[tommck]

It seems that AutoFixture currently doesn't support the new DNX platform.

Are there plans to add support this?

[ploeh]

Not yet, at least. What is DNX?

[tommck]

Haha.. it's the new cross-platform asp.net framework. https://github.com/aspnet/DNX

the runtime is "dnx451" instead of "net451", etc.

[ploeh]

What does "support for" mean in this context? Are you saying that it's impossible to test ASP.NET 5 from a test library with a dependency on a .NET 4 library?

[tommck]

ASPNET 5 runs on multiple platforms. We're only writing ASPNET 5 on the dnx platform right now, so it is a different set of runtime libraries. Our code currently is not compiled for "net451", so the libraries are effectively targeting incompatible platforms

[hoetz]

My tests run just fine with this project.json:

{
"dependencies": {

     "xunit.runner.dnx": "2.1.0-*",
     "xunit":"2.1.0-*",
    "AutoFixture.Xunit2":"3.30-*",
    "NSubstitute": "1.8.0",
    "ManagementWeb": "",
    "Microsoft.AspNet.Mvc": "6.0.0-beta4",
    "AutoFixture": "3.30.4-*",
    "AutoFixture.AutoNSubstitute": "3.30.4-*",
    "Microsoft.Azure.Documents.Client": "0.9.2-preview",
    "WindowsAzure.Storage": "4.4.1-*",
    "DeepEqual": "1.1-*"
},
 "frameworks": {
    "dnx451": { }
},
"commands": {
    "test": "xunit.runner.dnx"
}

}

[tommck]

interesting. I'll have to bug the guy that's working on this to see what the difference is.
Did you do anything special to make it work?

[hoetz]

Not really, no. IIRC Autofixture always worked with aspnet 5 but in the past I had trouble with the xUnit extension. Now that xUnit 2 support for AF is out and DNX & xUnit play together nicely it just works.

[aggieben]

Seems to the the idea here is really "support for CoreCLR", not DNX. Anything that works for the .NET Framework 4.5 will work for 4.5 on DNX. CoreCLR will likely require some effort to support, but I have no idea how much. The best way to find out is to try building it for CoreCLR and see what breaks.

[tommck]

Yes, I should have been clear. I meant CoreCLR, not just DNX.

[ploeh]

From just looking in the coreclr repo, it's difficult for me to glean the status of the project. Is it in preview? Beta? Released?

Without having tried it at all, if CoreCLR is anything like Portable Class Libraries in that the supported features is an intersection of available features on various platforms, it's quite unlikely that it would be possible to retrofit AutoFixture to run on CoreCLR without breaking changes.

Recently, @moodmosaic was so kind to make the analysis for AtomEventStore (a much smaller project than AutoFixture), and here the outcome was that a PCL version was infeasible.

[aggieben]

Without having looked at AutoFixture sources at all, I agree with your assessment: breaking changes are likely. #if DNX_*-style directives will be necessary if support is in the plan.

[DerAlbertCom]

CoreCLR is, more or less, up an Running since Windows Phone 8.

ASP.NET 5 will be RC in November, CoreCLR for Linux and Mac will also be RC in November 2015. Alongside with CoreFX. Release 1.0 for everything planned for 1Q2016.

[ploeh]

It would surprise me tremendously if it was possible to add support for CoreCLR without introducing breaking changes, so I've added the 4.0 milestone to this issue.

[ecampidoglio]

Out of curiosity, I run the API Portability Analyzer on the Ploeh.AutoFixture assembly and got some interesting results:

Wait before you open the Champagne. That rough 3% of unsupported symbols, unfortunately, accounts for some rather fundamental ones:

Target type	Target member
System.Console	M:System.Console.get_Out
System.Threading.Thread	M:System.Threading.Thread.get_ManagedThreadId
System.Threading.Thread	M:System.Threading.Thread.get_CurrentThread
System.Reflection.ICustomAttributeProvider	M:System.Reflection.ICustomAttributeProvider.GetCustomAttributes(System.Type,System.Boolean)
System.Net.Mail.MailAddress	M:System.Net.Mail.MailAddress.#ctor(System.String)
System.SerializableAttribute	M:System.SerializableAttribute.#ctor
System.Runtime.Serialization.SerializationInfo	T:System.Runtime.Serialization.SerializationInfo
System.Reflection.ParameterInfo	M:System.Reflection.ParameterInfo.IsDefined(System.Type,System.Boolean)
System.Type	M:System.Type.get_IsGenericTypeDefinition
System.Type	M:System.Type.get_IsEnum
System.Type	M:System.Type.get_BaseType
System.Type	M:System.Type.get_IsPrimitive
System.Type	M:System.Type.get_Assembly
System.Type	M:System.Type.get_IsGenericType
System.Type	M:System.Type.GetTypeCode(System.Type)
System.Type	M:System.Type.get_IsClass
System.Type	M:System.Type.get_IsValueType
System.Type	M:System.Type.get_IsAbstract
System.Reflection.MemberInfo	M:System.Reflection.MemberInfo.get_ReflectedType
System.Reflection.PropertyInfo	M:System.Reflection.PropertyInfo.GetSetMethod
System.Exception	M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext)
System.Reflection.MethodBase	M:System.Reflection.MethodBase.GetCurrentMethod

However, there are a few solutions:

• Replace all references to the properties in System.Type with the corresponding ones in System.TypeInfo, available through the GetTypeInfo(Type) extension method.
• Remove all references to System.SerializableAttribute.
• Remove all references to System.Runtime.Serialization.SerializationInfo (likely only used in exception constructors).
• Remove all references to System.Net.Mail.MailAddress.
• Remove all references to the System.Reflection.MemberInfo.ReflectedType property and use the reflected object to get a hold of its type.
• Replace all references to the System.Reflection.PropertyInfo.GetSetMethod property with the System.Reflection.PropertyInfo.SetMethod property instead.

This is only a first pass and things might change as CoreCLR is still being developed. At least we got a general idea of what it would take to make AutoFixture compatible with it.

[ploeh]

Wow, thank you, @ecampidoglio, for performing this analysis 👍

Some of the incompatible types (e.g. MailAddress) we can move to an add-on library that only works on the full framework. I already had in mind to pull some features out of the Ploeh.AutoFixture library for version 4.

The idea of replacing PropertyInfo.GetSetMethod with PropertyInfo.SetMethod is good. AFAICT, it'll only work on .NET 4.5+, but that's okay, because the v4 branch is already on .NET 4.5.

[chaitanyagurrapu]

Not sure if the "Jump In" label is appropriate for this issue. Usually it is used to indicate small, isolated, bite sized issues that are fairly easy and new contributer friendly. It seems this issue would require a fairly good understanding of a large part of the code base and it's history.

[ploeh]

@chaitanyagurrapu, perhaps you're right.

The reason I added the jump in label was that I consider this work somewhat unrelated to AutoFixture details. Yes: decisions will have to be made on how to address various incompatibilities, but there's also a great deal of work simply figuring out how the entire code/build infrastructure works related to CorCLR, and that part is completely unrelated to AutoFixture.

At the moment, I don't have these skills, so I would love getting help with this. The decisions that need to be made regarding compatibility issues we can discuss here, or in dedicated Github issues.

[lbargaoanu]

I've started working on this. Questions to come :)

[moodmosaic]

Sounds good to me 👍

[ploeh]

@lbargaoanu Sounds good 👍 Remember, if at all possible, keep it small.

[lbargaoanu]

I would like to move MailAddressGenerator to a different project that targets the full framework in the v4 branch, so I can build AutoFixture for .NET Core. I could also declare a placeholder type for .NET Core, but I've avoided conditional compilation until now. And there will always be things supported only in the full framework.

[lbargaoanu]

It's in the works. But meanwhile...

[andersborum]

Was bitten by the error "Package AutoFixture 3.50.5 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1)" today when starting to add tests to a number of .NET Core projects.

I'm asking for a "state of autofixture for .net core" kind of reply that gives a direction for when this extremely useful nuget package will be available for this platform (and .net core 2.0 is already rtm and pending release ..).

What's holding it back? (thanks in advance)

[zvirja]

We are currently working on that and you can track the progress in #773. Notice, this PR is about the AutoFixture project itself. We have 9 more other projects that should be migrated, but that should be done only after we finish work on this one.

.NET Core support will be released as v4, you can find the whole scope here. I'd expect a couple of months before everything is ready.

In the meanwhile, we are also working on the Dev NuGet feed (#762), so you will be able to participate in early product testing 😉

[andersborum]

@zvirja thanks for the detailed update. I'm sure it'll come in handy for other developers as well. I'd be happy to participate in early product testing.

[andersborum]

@zvirja so just to clarify - the current (temporary) approach to writing unit tests against .NET Core applications/libraries is using AutoFixture in e.g. .NET 4.7 test projects and migrate the test project(s) to .NET Core at a later time?

Is this the suggested workaround for the time being? (as long as the app I'm writing is allowed to be fully .NET Core, it's actually not a big issue to write the tests in a regular .NET 4.7 environment).

[zvirja]

@andersborum I never thought about the temporary workaround. I'm not sure that all the API we use in v3 (packages, published to NuGet) are .Net Standard 2.0 compliant (to use a new feature of .NET Standard).

Let us know if you found a way to combine both v3 and .Net Core, so we could advice that to other people 😉

[zvirja]

Just to notify everybody - .Net Standard support for AutoFixture PR (#773) has been merged to the v4 branch. You can consume package from our private feed.

Notice, only AutoFixture library has been migrated. Other glue libraries will follow up later.

[RoCore]

It is possible to move the v4 to the nuget.org, even the alpha version? Couldn't find anything comparable to autofixture until now that support .netstandard.
Is the release date for v4 already decided?

[zvirja]

@RomanKernSW Not at this moment - we haven't migrated even a half of the projects yet (like xUnit, NUnit, NSubstitute support), so it's too early. Also we have a plan to change the namespace, so I'd prefer to do that before we release something publicly as that would be a major break between releases. On other hand, I want to change namespace as later as possible, as we constantly merge master to v4 and it will be a hell to do that after the change.

Do you have any issues with the private feed? You can add the feed via NuGet.config if that is strongly needed.

[RoCore]

hm I have to check if it possible to use nuget.config for nuget restore (.Net Core 2 - preview Task in VSO). Right now, we have one private Feed (VSO) with nuget.org without any nuget.config files. Need time to test this...

[roarwrecker]

.Net Standard 2.0 has a compatibility mode for .Net Framework NuGets. I have written .Net Core tests with AutoFixture 3.50.x and no problems so far.

[zvirja]

@roarwrecker Awesome, thanks for sharing! Meaning we have larger time buffer till we roll out the official support to NuGet 😉

[RoCore]

@roarwrecker thanks... this was not the issue on .netstandard 1.6. I could install the nuget, but it never compile without error

[selmendorfFrontline]

Hey Guys, not sure how far along the .NetCore work is, but is it possible to get an alpha version on NuGet?

[zvirja]

@selmendorfFrontline Copying the reply from here:

Publish of the pre-release version to the NuGet is a bit painful question to me. While we started to support .NET Core for most of the projects, we have a plan to change the default namespace. This would be a huge breaking change for our clients and all the client code will stop to compile. This is the point when the confusion appears:

• if we release alpha with existing namespace and change namespace in between the alpha and RTM, it will confuse our clients as they already saw v4 with existing namespace. I want our clients to feel that v4 was always released with a new namespace as governance model was changed.
• if we release alpha with changed namespace, we'll be unable to merge master to v4 branch without pain anymore. Currently we commit to both the branches, that's why I'd like to defer namespace change to the end. Another point is that our documentation is not currently ready, so people might simply not understand why all the namespace imports are invalid and that they need to simply run a text replace. That will make them scary and experience will not be as smooth as I wish.

The best way to solve this situation would be to not release alpha and release the RTM only. Unfortunately, I cannot provide you with precise ETA as it depends on my capacity (I'm working on this project in my free time) and availability of other contributors (my PRs should be reviewed 😉). In my head I imagine the release in a month or two and hope it will happen within this range. This project was dead for about 9 months due to governance model change - that's the main reason of such a delay in support.

Please use the package from the preview feed in the meanwhile. You can tune your Nuget.config as it was mentioned above, so this should be an issue.

[zvirja]

I'm going to close this issue after the #857 is finally merged. Our final .NET Compatibility table would be following:

Product	.NET Framework	.NET Standard
AutoFixture	✔️ 4.5.2	✔️ 1.5
AutoFixture.xUnit	✔️ 4.5.2	➖
AutoFixture.xUnit2	✔️ 4.5.2	✔️ 1.5
AutoFixture.NUnit2	✔️ 4.5.2	➖
AutoFixture.NUnit3	✔️ 4.5.2	✔️ 1.5
AutoFakeItEasy	✔️ 4.5.2	✔️ 1.6
AutoFoq	✔️ 4.5.2	➖
AutoMoq	✔️ 4.5.2	✔️ 1.5
AutoNSubstitute	✔️ 4.5.2	✔️ 1.5
AutoRhinoMock	✔️ 4.5.2	➖
Idioms	✔️ 4.5.2	✔️ 2.0
Idioms.FsCheck	✔️ 4.5.2	➖
SemanticComparison	✔️ 4.5.2	✔️ 1.5

All the unsupported libraries except Idioms.FsCheck cannot be updated as their dependencies don't support .Net Standard and it's unlikely that they will (most of them are obsoleted). I've tried to port Idioms.FsCheck to support both .NET 452 and .NET Standard 2.0 (as it's technically possible), however wasn't able to make it work. It seems that F# SDK is still pretty rough and we need to wait for new releases. Compilation and project load simply fail after I define TargetFrameworks node.

Unless anybody have other vision, I'm going follow this plan 😃I also feel how close we are to the release and how much is behind 😊

[MihaMarkic]

Go go go!

[moodmosaic]

I've tried to port Idioms.FsCheck to support both .NET 452 and .NET Standard 2.0

Have you tried switching to a newer F# version on that one? IIRC, it's on F# 3.1 and this might be the case.

[Kralizek]

Great work @zvirja. Do you think we can get v4 out? The closer we get, the more excited i feel :)

I wish i could offer you a beer :)

[zvirja]

Have you tried switching to a newer F# version on that one? IIRC, it's on F# 3.1 and this might be the case.

@moodmosaic Yep. If you check FsCheck 2.9.0 you will find that it depends on FSharp.Core (>= 4.1.17), therefore I had no other choice 😅 The issue is rather with SDK. If I start to target both frameworks simultaneously, I'm unable to load the solution in VS
Project:

<PropertyGroup>
  <TargetFrameworks>net452;netstandard2.0</TargetFrameworks>
  .....
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="FsCheck" Version="[0.9.2,3.0.0)" Condition=" '$(TargetFramework)'=='net452' " />
  <PackageReference Include="FSharp.Core" Version="3.1.2" Condition=" '$(TargetFramework)'=='net452' " />

  <PackageReference Include="FsCheck" Version="[2.9.0,3.0.0)" Condition=" '$(TargetFramework)'=='netstandard2.0' " />
  <PackageReference Include="FSharp.Core" Version="4.1.17" Condition=" '$(TargetFramework)'=='netstandard2.0' " />

  <PackageReference Include="FSharp.NET.Sdk" Version="1.0.*" PrivateAssets="All" />
</ItemGroup>

Trying to open in VS:

Everything is fine with the project - the issue is somewhere in F# SDK. That's why I'd like to postpone .NET Core support by FsCheck till the better times.

@Kralizek Please see the reply a few answers above.

[zvirja]

Just checked in VS 2017.4 and still cannot target multiple frameworks for F# project. Therefore, I'm closing this issue for now as we support .NET Core for all other projects.

[zvirja]

JFYI: I released v4 rc1 to the NuGet, so you can consume and test without need to play with a custom feed.