New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for CoreCLR #404

Closed
tommck opened this Issue May 13, 2015 · 77 comments

Comments

@tommck
Copy link

tommck commented May 13, 2015

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

Are there plans to add support this?

@ploeh

This comment has been minimized.

Copy link
Member

ploeh commented May 13, 2015

Not yet, at least. What is DNX?

@tommck

This comment has been minimized.

Copy link
Author

tommck commented May 13, 2015

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

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

@ploeh

This comment has been minimized.

Copy link
Member

ploeh commented May 13, 2015

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

This comment has been minimized.

Copy link
Author

tommck commented May 13, 2015

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

This comment has been minimized.

Copy link

hoetz commented May 14, 2015

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

This comment has been minimized.

Copy link
Author

tommck commented May 14, 2015

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

This comment has been minimized.

Copy link

hoetz commented May 14, 2015

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

This comment has been minimized.

Copy link

aggieben commented May 31, 2015

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

This comment has been minimized.

Copy link
Author

tommck commented Jun 1, 2015

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

@ploeh

This comment has been minimized.

Copy link
Member

ploeh commented Jun 1, 2015

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

This comment has been minimized.

Copy link

aggieben commented Jun 1, 2015

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

This comment has been minimized.

Copy link

DerAlbertCom commented Aug 20, 2015

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 ploeh changed the title Support for DNX Support for CoreCLR Aug 31, 2015

@ploeh ploeh added this to the 4.0 milestone Aug 31, 2015

@ploeh

This comment has been minimized.

Copy link
Member

ploeh commented Aug 31, 2015

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

This comment has been minimized.

Copy link
Member

ecampidoglio commented Sep 16, 2015

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

autofixture-compatibility

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

This comment has been minimized.

Copy link
Member

ploeh commented Sep 17, 2015

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

This comment has been minimized.

Copy link

chaitanyagurrapu commented Nov 26, 2015

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

This comment has been minimized.

Copy link
Member

ploeh commented Nov 26, 2015

@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

This comment has been minimized.

Copy link

lbargaoanu commented Jan 5, 2016

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

@moodmosaic

This comment has been minimized.

Copy link
Member

moodmosaic commented Jan 5, 2016

Sounds good to me 👍

@ploeh

This comment has been minimized.

Copy link
Member

ploeh commented Jan 5, 2016

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

@lbargaoanu

This comment has been minimized.

Copy link

lbargaoanu commented Jan 15, 2016

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

This comment has been minimized.

Copy link

lbargaoanu commented Jan 15, 2016

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

JSkimming added a commit to JSkimming/Castle.Core.AsyncInterceptor that referenced this issue Apr 12, 2017

Removed AutoFixture as it doesn't support .NET Core
Work is afoot to support .NET core, but since it's not heavily used in
this project it's easier to remove it.
See AutoFixture/AutoFixture#404

@zvirja zvirja referenced this issue Jul 3, 2017

Merged

Support .NET Standard by the AutoFixture project #773

16 of 16 tasks complete
@andersborum

This comment has been minimized.

Copy link

andersborum commented Aug 14, 2017

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

This comment has been minimized.

Copy link
Member

zvirja commented Aug 14, 2017

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

This comment has been minimized.

Copy link

andersborum commented Aug 14, 2017

@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

This comment has been minimized.

Copy link

andersborum commented Aug 14, 2017

@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

This comment has been minimized.

Copy link
Member

zvirja commented Aug 15, 2017

@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

This comment has been minimized.

Copy link
Member

zvirja commented Aug 22, 2017

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.

@RomanKernSW

This comment has been minimized.

Copy link

RomanKernSW commented Aug 30, 2017

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

This comment has been minimized.

Copy link
Member

zvirja commented Aug 30, 2017

@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.

@RomanKernSW

This comment has been minimized.

Copy link

RomanKernSW commented Aug 30, 2017

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

This comment has been minimized.

Copy link

roarwrecker commented Aug 30, 2017

@zvirja

This comment has been minimized.

Copy link
Member

zvirja commented Aug 30, 2017

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

@RomanKernSW

This comment has been minimized.

Copy link

RomanKernSW commented Aug 30, 2017

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

@selmendorfFrontline

This comment has been minimized.

Copy link

selmendorfFrontline commented Sep 28, 2017

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

@zvirja

This comment has been minimized.

Copy link
Member

zvirja commented Sep 28, 2017

@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

This comment has been minimized.

Copy link
Member

zvirja commented Oct 4, 2017

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

This comment has been minimized.

Copy link

MihaMarkic commented Oct 4, 2017

Go go go!

@moodmosaic

This comment has been minimized.

Copy link
Member

moodmosaic commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Contributor

Kralizek commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Member

zvirja commented Oct 6, 2017

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:
image

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

This comment has been minimized.

Copy link
Member

zvirja commented Oct 11, 2017

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

This comment has been minimized.

Copy link
Member

zvirja commented Oct 18, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment