Autofixture: Support for CoreCLR

Not yet, at least. What is DNX?

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

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

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?

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

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"
}

}

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?

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.

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.

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

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.

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.

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.

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.

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.

Wow, thank you, @ecampidoglio, for performing this analysis :+1:

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.

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.

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

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

Sounds good to me :+1:

@lbargaoanu Sounds good :+1: Remember, if at all possible, keep it small.

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.

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

For future reference
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Nice post! Does it also cover libraries? (I searched for _library_ but didn't find much...)

:) That's all about libraries, but this post and its links should be enough.

I'd love to see AutoFixture working on CoreCLR, as well, and willing to help out where needed. Looking at the last PRs of Lucian Bargaoanu (#511, and #513), it looks like this issue got stale on some unresolved discussions.

I'd like to get the ball rolling, but don't know what the overall plan was for this, and how to deal with some of the details that were blocking the discussions. So it might be useful to get to something like that, before getting into all of the details.

Some questions that I've seen floating around, or that I have myself:

• should AutoFixture be converted into a PCL, or use something like shared projects?
• which platforms are definitely needed, or wanted for the long run? (.NET, CoreCLR, UWP?)
• are conditional compilations unwanted for a project like this?

@ploeh I can image that not all of these questions can be answered by you, but maybe the core contributors have some input on this. @lbargaoanu Do you have maybe some input on this? Thanks!

I see that I have forgotten to reply to this thread; please accept my apologies :flushed:

Any work we can do in order to prepare the AutoFixture code base for .NET Core is welcome, as long as it doesn't degrade the code base or introduce breaking changes.

Breaking changes are still possible, but they'd have to go into the _v4_ branch.

In any case, though, I'll need good justification for any change that seems unwarranted as is. While I can't say that I'm following the .NET Core situation closely, it seems like there's still a lot of thrashing, and I'm not keen to introduce speculative changes as long as the target is still moving.

I wouldn't be surprised if conditional compilation would end up being necessary, and I'm not against it as long as we can keep it sane. If I can still run the build script in order to build whatever needs to be published, it'll probably be OK. I must admit, though, that I don't have a lot of experience with this.

I also don't know which platforms are wanted. Essentially, if anyone in the community sends us pull requests that look maintainable, and that extend AutoFixture's reach, we'll consider taking them.

AFAICT, we would need to target netstandard1.X which is the set of APIs that would run on any platform that implements them (including netcore cross platform and net framework on Windows only).

See https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

In general, the higher numbers have more APIs, but less supported platforms. We should probably start (continue) this discussion by understanding which X we should target in netstandard1.X.

The first paragraph of that document scares me a little bit:

We're sharing early plans for the future of building .NET class libraries.
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic it scares me too, but the thing is, the general concept of choosing which APIs we would be targeting would essentially be necessary either way. netstandard just gives them a well known name and agreed subsets, and an easier way to describe them. That is assuming we wanted to be portable in the first place.

For example, if we need reflection APIs for AutoFixture, the list of targets we could possibly have is reduced. If we need concurrent collections, the same is true. Those platforms already exist (net framework full, Windows phone, etc), so I think it's not something that can change if we discuss which APIs we need.

I might [re] kick off the conversation... (disclaimer: I'm still learning this stuff too)

I start with the lowest (netstandard1.0) which is implemented already on the largest number of platforms, and look for reasons why we cannot (or will not) commit to that platform.

According to my understanding, the netstandard1.0 set of APIs is pretty old and restrictive. It doesn't have things things like:

• System.Linq.Parallel (starts from netstandard1.1)
• System.Console (starts from netstandard1.3)
• System.Collections.Concurrent (starts from netstandard1.1)
• System.ComponentModel.Annotations (starts from netstandard1.1)
• System.Collections.Specialized (starts from netstandard1.3)

This leads me to think it's not practical for AutoFixture to target netstandard1.0.

I wonder if waiting for the analyser mentioned by @ecampidoglio here is a better strategy.

Edit: here is the .NET API Portability analyser tools repo and here is the web site http://dotnetstatus.azurewebsites.net

Sorry for too much comment spam, I'll stop now :)

FYI I ran the latest portability analyser on a locally built Ploeh.AutoFixture.dll from v4 4a7d415 and the summary is:

Here are some changes it currently recommends:

Full output is here.

@ploeh Many widely-used componenets of Asp.Net Core require at minimum netstandard1.3. Examples of this include EntityFrameworkCore (uses 1.3) and Mvc (uses 1.6).

If Autofixture used either of these as the baseline, I think it'd be in a good place.

Any timelines on when .Net Core support might be available?

I managed to make a build on .NET Core based on v4 branch. I did not try to build test projects though. Check out this branch if you want to create a package.

FWIW, here's the comparison between AutoFixture/AutoFixture v4 and uhaciogullari/AutoFixture net-core. It's looking good 👍

Well it's not that straightforward really. The existence of project.json causes an error on building regular csproj projects right now. We could migrate all projects to project.json format but I am not sure if it's a good idea for the other projects. I haven't checked them in detail but I suspect they are plugins for some other testing frameworks. No idea if they support .NET Core as well.

Another thing is Microsoft announced they will move away from project.json soon and they will go back to csproj. They promise an easy migration but do you want to take your time to use this temporary format? It's all up to you. I could push a package from my current branch but v4 seems like work in progress.

There is a way to build without the errors: #712

I actually tried to build from your branch but it doesn't generate a dll. It's probably missing some configuration but creating an extra folder in each project didn't appeal to me aesthetically.

Is there any update on this?

I think it was prudent to wait until the .net core tooling reaches RTM status. The updated csproj tooling will not be ported to VS2015 and thus will only be available in VS2017. See https://twitter.com/TheCodeJunkie/status/822048014172880900

https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/

@hoetz you can still install vs2017 community edition.

Is there any plan to look at this issue?

It feels really bad to write tests for .NET standard assemblies without AitoFixture...

Hi Everyone, this requires somebody from the community to step in and contribute. It's obviously difficult right now because the governance model issues haven't been resolved yet (#703). Somebody also needs to step in on that front too.

I'm playing around with the problem. Right now I'm focusing only on Src\AutoFixture.sln.

My strategy is to convert Src\AutoFixture\AutoFixture.csproj to the new project format (VS 2017) so that it can support both .NET Framework and .NET Standard.

I ran the .NET Portability Test and the best target should be .NET Standard 1.5 (see attached file).

To begin with, I won't be converting the test projects, although I assume we might want to run the test also in .NET Core runtime in the future.

AutoFixtureNetPortabilityTest.zip

Hey @Kralizek - Just FYI - I had success with netstandard1.3 over in #712

@Kralizek my mistake, it looks like I started planning for netstandard1.3 but actually ended up with netstandard1.5 👍

Almost there. The tests are all green in .NET Framework. The build is all red in .NET Standard. :D

I met only these categories of problems:

Generator not needed
Only one case, MailAddressGenerator, because System.Net.Mail.MailAddress is not available in .NET Standard. Solution: the entire file has been "removed" by #if NET40 ... #endif

Serialization
SerializableAttribute, SerializationInfo and StreamingContext don't exist in .NET Standard. Also, Exception doesn't have the constructor that take those two types. Using compiler directive I've removed the attribute and that constructor from all the exceptions. Especially removing the attribute isn't really pretty.

Usage of Reflection to get information about a Type
In .NET Standard Type is much poorer. Everything is delegated to a TypeInfo object that contains all the properties that are used. The problem is that .NET Framework uses still the old Type class.
Solution:
I created an extension method that forwards the very same Type object public static Type GetTypeInfo(this Type type) => type; and made this extension method available only in .NET Framework via compiler directive. This trick solved many incompatibilities leaving the files untouched. Note: the extension method is marked as internal.

Usage of Reflection to get the current Assembly
Ok, this one was a tough one because I don't know perfectly the project layout. I used ReSharper to quickly check class hierarchy but you guys should double check.
The file is TerminatingWithPathSpecimenBuilder and the line is var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly;. It looks like you are looking for the assembly we are in. Since this class doesn't have inheritors, it's safe to assume that typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly returns the same result, but again, I might be wrong. (I put the fake extension method in brackets). If my assumption is correct, I would suggest to mark this class as sealed to avoid the risk of it being inherited and breaking it.

Anyway, let me introduce you the new project file.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net40;netstandard1.5</TargetFrameworks>
    <GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
    <GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
    <GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
    <GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
    <GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
    <GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
    <GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
  </PropertyGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net40' ">
    <Reference Include="System" />
    <Reference Include="System.Core" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.ComponentModel.DataAnnotations" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.5' ">
    <PackageReference Include="System.ComponentModel.Annotations" Version="4.1.0" />
  </ItemGroup>
</Project>

yes, this is the whole project file.

@Kralizek have you noticed we intend to target >= net45 in the v4 branch?

@adamchester nope... It shouldn't matter that much but I will change the target framework. Thanks for the heads up! 👍

Btw, I found out that System.Threading.Thread is available as a package.

It unlocked a whole new level of compiler errors... nice :P

.NET Standard 2.0 Should add a lot api back, maybe it is worth waiting?

No, it's not. .NET Standard 2.0 is due in Q3 2017. We are one commit away from supporting .NET Standard 1.5, why should we wait for 2.0? For generating mail messages on a runtime will never support it?

Also, 2.0 is mostly going to be a shim of framework 4.6 with a lot of NotSupportedException being thrown all around.

@Kralizek Fair enough. I would of course love autofixter released faster, so was a more general question.

FWIW, I'm the contributor that added the support for the mail address generator, and although, it's nice that it made AutoFixture to have support for that out of the box, it's by no means a vital aspect of AutoFixture and worth the effort to wait for it.

Having AutoFixture on the lowest possible .NET Standard should have most priority, IMHO. Keep up the good work, and if you're looking for any help, or support in testing it, then I can definitely pitch in.

@Kralizek the TypeInfo stuff is also present in .NET 4.5, so it would help.

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)

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 😉

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

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

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

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.

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?

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

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

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

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

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

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

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

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 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.xUnit | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoFixture.xUnit2 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFixture.NUnit2 | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoFixture.NUnit3 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoFakeItEasy | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.6 |
| AutoFoq | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| AutoMoq | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoNSubstitute | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoRhinoMock | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| Idioms | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 2.0 |
| Idioms.FsCheck | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| SemanticComparison | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 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 😊

Go go go!

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.

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

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.

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.

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