AutoFixture 🚀 - 支持 CoreCLR

至少还没有。 DNX是什么？

ploeh 于 2015-05-13

哈哈..这是新的跨平台asp.net框架。 https://github.com/aspnet/DNX

运行时是“dnx451”而不是“net451”等。

tommck 于 2015-05-13

在这种情况下，“支持”是什么意思？您是说从依赖于 .NET 4 库的测试库测试 ASP.NET 5 是不可能的吗？

ploeh 于 2015-05-13

ASPNET 5 可在多个平台上运行。我们现在只在 dnx 平台上编写 ASPNET 5，所以它是一组不同的运行时库。我们的代码目前不是为“net451”编译的，所以这些库实际上是针对不兼容的平台

tommck 于 2015-05-13

我的测试在这个 project.json 上运行得很好：

{
“依赖关系”：{

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

}

hoetz 于 2015-05-14

有趣的。我将不得不打扰正在研究这个的人，看看有什么区别。
你做了什么特别的事情来使它工作吗？

tommck 于 2015-05-14

不是真的，不是。 IIRC Autofixture 总是与 aspnet 5 一起工作，但过去我在使用 xUnit 扩展时遇到了麻烦。现在 xUnit 2 对 AF 的支持已经结束，DNX 和 xUnit 可以很好地协同工作，它可以正常工作。

hoetz 于 2015-05-14

似乎这里的想法真的是“支持 CoreCLR”，而不是 DNX。任何适用于 .NET Framework 4.5 的东西都适用于 DNX 上的 4.5。 CoreCLR 可能需要一些努力来支持，但我不知道多少。找出答案的最好方法是尝试为 CoreCLR 构建它，看看有什么问题。

aggieben 于 2015-06-01

是的，我应该很清楚。我指的是 CoreCLR，而不仅仅是 DNX。

tommck 于 2015-06-01

仅查看coreclr repo ，我很难了解项目的状态。是预览版吗？测试版？释放？

根本没有尝试过，如果 CoreCLR 类似于可移植类库，因为支持的功能是各种平台上可用功能的交集，那么在不破坏更改的情况下改造 AutoFixture 以在 CoreCLR 上运行是不太可能的。

最近， @moodmosaic对 AtomEventStore（比 AutoFixture 小得多的项目）进行了

ploeh 于 2015-06-01

根本没有查看 AutoFixture 的来源，我同意您的评估：可能会发生重大变化。如果计划中提供支持，则需要#if DNX_* -style 指令。

aggieben 于 2015-06-01

CoreCLR 或多或少地从 Windows Phone 8 开始运行。

ASP.NET 5 将于 11 月成为 RC，用于 Linux 和 Mac 的 CoreCLR 也将于 2015 年 11 月成为 RC。与 CoreFX 一起。为 2016 年第一季度计划的所有内容发布 1.0。

DerAlbertCom 于 2015-08-20

如果可以在不引入重大更改的情况下添加对 CoreCLR 的支持，我会感到非常惊讶，因此我在此问题中添加了 _4.0_ 里程碑。

ploeh 于 2015-08-31

出于好奇，我在Ploeh.AutoFixture程序集上运行API Portability Analyzer并得到了一些有趣的结果：

autofixture-compatibility

等你开香槟。不幸的是，大约 3% 的不受支持的符号占了一些相当基本的符号：

| 目标类型 | 目标会员 |
| --- | --- |
| 系统控制台 | 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) |
| 系统类型 | M:System.Type.get_IsGenericTypeDefinition |
| 系统类型 | M:System.Type.get_IsEnum |
| 系统类型 | M:System.Type.get_BaseType |
| 系统类型 | M:System.Type.get_IsPrimitive |
| 系统类型 | M:System.Type.get_Assembly |
| 系统类型 | M:System.Type.get_IsGenericType |
| 系统类型 | M:System.Type.GetTypeCode(System.Type) |
| 系统类型 | M:System.Type.get_IsClass |
| 系统类型 | M:System.Type.get_IsValueType |
| 系统类型 | M:System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M:System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M:System.Reflection.PropertyInfo.GetSetMethod |
| 系统异常| M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M:System.Reflection.MethodBase.GetCurrentMethod |

但是，有几个解决方案：

替换到的属性的所有引用System.Type与所述相应一个System.TypeInfo ，可通过GetTypeInfo(Type)扩展方法。
删除对System.SerializableAttribute所有引用。
删除对System.Runtime.Serialization.SerializationInfo所有引用（可能仅用于 _exception 构造函数_）。
删除对System.Net.Mail.MailAddress所有引用。
删除对System.Reflection.MemberInfo.ReflectedType属性的所有引用，并使用反射对象来获取其类型。
将所有对System.Reflection.PropertyInfo.GetSetMethod属性的引用替换为System.Reflection.PropertyInfo.SetMethod属性。

这只是第一步，随着 CoreCLR 仍在开发中，情况可能会发生变化。至少我们对如何使 AutoFixture 与其兼容有了一个大致的了解。

ecampidoglio 于 2015-09-17

❤2 😄2

哇，谢谢@ecampidoglio执行此分析：+1：

一些不兼容的类型（例如MailAddress ）我们可以移动到仅适用于完整框架的附加库。我已经考虑从版本 4 的 _Ploeh.AutoFixture_ 库中提取一些功能。

替换的想法PropertyInfo.GetSetMethod与PropertyInfo.SetMethod好。 AFAICT，它只适用于 .NET 4.5+，但没关系，因为 _v4_ 分支已经在 .NET 4.5 上。

ploeh 于 2015-09-17

不确定“跳入”标签是否适合此问题。通常它用于表示相当容易且对新贡献者友好的小的、孤立的、一口大小的问题。看来这个问题需要对大部分代码库及其历史有很好的理解。

chaitanyagurrapu 于 2015-11-26

@chaitanyagurrapu ，也许你是对的。

我添加 _jump in_ 标签的原因是我认为这项工作与 AutoFixture 细节有些无关。是的：必须就如何解决各种不兼容性做出决定，但也有大量工作只是弄清楚与 CorCLR 相关的整个代码/构建基础设施如何工作，而这部分与 AutoFixture 完全无关。

目前，我没有这些技能，所以我很想得到这方面的帮助。关于兼容性问题需要做出的决定我们可以在这里讨论，或者在专门的 Github 问题中讨论。

ploeh 于 2015-11-26

我已经开始研究这个了。问题来了:)

lbargaoanu 于 2016-01-05

对我来说听起来不错：+1：

moodmosaic 于 2016-01-05

@lbargaoanu听起来不错：+1：记住，如果可能的话，尽量保持小。

ploeh 于 2016-01-05

我想将 MailAddressGenerator 移动到一个针对 v4 分支中完整框架的不同项目，以便我可以为 .NET Core 构建 AutoFixture。我也可以为 .NET Core 声明一个占位符类型，但直到现在我都避免使用条件编译。并且总是只有在完整框架中才支持的东西。

lbargaoanu 于 2016-01-15

它正在制作中。但同时...

lbargaoanu 于 2016-01-15

备查
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

lbargaoanu 于 2016-02-11

好贴！它也涵盖图书馆吗？（我搜索了 _library_ 但没有找到太多......）

moodmosaic 于 2016-02-11

:) 这就是图书馆的全部内容，但是这篇文章及其链接应该足够了。

lbargaoanu 于 2016-02-11

我也很想看到 AutoFixture 在 CoreCLR 上工作，并愿意在需要的地方提供帮助。查看 Lucian Bargaoanu（#511 和 #513）的最后 PR，看起来这个问题在一些未解决的讨论中变得陈旧。

我想让球滚动，但不知道这个总体计划是什么，以及如何处理一些阻碍讨论的细节。因此，在深入了解所有细节之前，了解类似的内容可能会很有用。

我看到的一些问题，或者我自己的问题：

应该将 AutoFixture 转换为 PCL，还是使用共享项目之类的东西？
哪些平台是绝对需要的，或者是长期需要的？（.NET、CoreCLR、UWP？）
像这样的项目不需要条件编译吗？

@ploeh我@lbaraoanu你对此有什么意见吗？谢谢！

tiesmaster 于 2016-03-07

我看到我忘记回复这个帖子了；请接受我的道歉 :flushed:

我们可以为 .NET Core 准备 AutoFixture 代码库所做的任何工作都是受欢迎的，只要它不会降低代码库或引入破坏性更改。

重大更改仍然是可能的，但它们必须进入 _v4_ 分支。

但是，无论如何，对于任何看起来毫无根据的更改，我都需要充分的理由。虽然我不能说我正在密切关注 .NET Core 的情况，但似乎仍然有很多颠簸，只要目标仍在移动，我就不热衷于引入推测性的变化。

如果条件编译最终成为必要，我不会感到惊讶，只要我们能保持理智，我并不反对。如果我仍然可以运行构建脚本以构建需要发布的任何内容，那可能没问题。不过，我必须承认，我在这方面没有很多经验。

我也不知道需要哪些平台。本质上，如果社区中的任何人向我们发送看起来可维护的拉取请求，并且扩展 AutoFixture 的影响范围，我们将考虑接受它们。

ploeh 于 2016-05-10

AFAICT，我们需要以netstandard1.X为目标，这是一组可以在任何实现它们的平台上运行的 API（仅包括 Windows 上的 netcore 跨平台和网络框架）。

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

一般来说，数字越大，API 越多，但支持的平台越少。我们可能应该通过了解我们应该在netstandard1.X定位哪个 X 来开始（继续）这个讨论。

adamchester 于 2016-05-10

该文件的第一段让我有点害怕：

我们正在分享构建 .NET 类库的未来早期计划。
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

moodmosaic 于 2016-05-10

@moodmosaic它也让我感到害怕，但问题是，无论哪种方式，选择我们将针对哪些 API 的一般概念本质上都是必要的。 netstandard 只是给它们一个众所周知的名称和商定的子集，以及一种更简单的方法来描述它们。那是假设我们首先想要便携。

例如，如果我们需要 AutoFixture 的反射 API，我们可能拥有的目标列表就会减少。如果我们需要并发集合，同样如此。这些平台已经存在（完整的网络框架、Windows 手机等），所以我认为如果我们讨论我们需要哪些 API，这不会改变。

adamchester 于 2016-05-10

👍1

我可能会[重新]开始谈话......（免责声明：我也在学习这些东西）

我从最低的 ( netstandard1.0 ) 开始，它已经在最大数量的平台上实现，并寻找我们不能（或不会）承诺到该平台的原因。

根据我的理解， netstandard1.0的 API 集非常古老且具有限制性。它没有像这样的东西：

System.Linq.Parallel（从netstandard1.1 ）
System.Console（从netstandard1.3 ）
System.Collections.Concurrent（从netstandard1.1 ）
System.ComponentModel.Annotations（从netstandard1.1 ）
System.Collections.Specialized（从netstandard1.3 ）

这让我认为 AutoFixture 以netstandard1.0为目标是不切实际的。

adamchester 于 2016-05-11

我不知道等待由@ecampidoglio提到的分析这里是一个更好的策略。

编辑：这里是.NET API Portability Analyzer 工具仓库，这里是网站http://dotnetstatus.azurewebsites.net

adamchester 于 2016-05-11

对不起，垃圾评论太多，我现在停止:)

仅供参考，我在来自 v4 4a7d415 的本地构建的 Ploeh.AutoFixture.dll 上运行了最新的可移植性分析器，摘要是：

部件	.NET 核心，版本 = v5.0	.NET 框架，版本=v4.6.2	.NET 平台，版本=v5.0
Ploeh.AutoFixture，版本=3.45.2.0，文化=中性，PublicKeyToken=null （.NETFramework，版本=v4.5）	98.56%	100.00%	98.37%

以下是它目前建议的一些更改：
screen shot 2016-05-11 at 11 36 16

完整输出在这里。

adamchester 于 2016-05-11

👍6

@ploeh许多广泛使用的 Asp.Net Core 组件至少需要netstandard1.3 。这方面的示例包括 EntityFrameworkCore（使用 1.3）和 Mvc（使用 1.6）。

如果 Autofixture 使用其中任何一个作为基线，我认为它会处于一个很好的位置。

rondefreitas 于 2016-08-03

.Net Core 支持何时可用的任何时间表？

mwhelan 于 2016-10-02

我设法在基于 v4 分支的 .NET Core 上进行构建。不过，我并没有尝试构建测试项目。如果要创建包，请查看此分支。

uhaciogullari 于 2016-10-23

👍1

FWIW，这是AutoFixture/AutoFixture v4 和 uhaciogullari/AutoFixture net-core 之间的

moodmosaic 于 2016-10-24

嗯，这真的不是那么简单。 project.json 的存在会导致现在构建常规 csproj 项目时出错。我们可以将所有项目迁移到 project.json 格式，但我不确定这对其他项目是否是个好主意。我没有详细检查它们，但我怀疑它们是其他一些测试框架的插件。不知道他们是否也支持 .NET Core。

另一件事是微软宣布他们将很快离开 project.json ，他们将回到 csproj。他们承诺轻松迁移，但您想花时间使用这种临时格式吗？全取决于你。我可以从我当前的分支推送一个包，但 v4 似乎正在进行中。

uhaciogullari 于 2016-10-25

有一种没有错误的构建方法：#712

adamchester 于 2016-10-25

我实际上尝试从您的分支构建，但它不会生成 dll。它可能缺少一些配置，但在每个项目中创建一个额外的文件夹在美学上对我没有吸引力。

uhaciogullari 于 2016-10-25

有任何更新吗？

christianhuening 于 2017-01-15

👍1

我认为等到 .net 核心工具达到 RTM 状态是谨慎的做法。更新后的 csproj 工具不会移植到 VS2015，因此只能在 VS2017 中使用。见https://twitter.com/TheCodeJunkie/status/822048014172880900

hoetz 于 2017-01-19

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

agoretsky 于 2017-03-08

@hoetz您仍然可以安装 vs2017 社区版。

有没有计划研究这个问题？

在没有 AitoFixture 的情况下为 .NET 标准程序集编写测试感觉真的很糟糕......

Kralizek 于 2017-03-09

大家好，这需要社区中的某个人介入并做出贡献。现在显然很困难，因为治理模型问题尚未解决（#703）。在这方面也需要有人介入。

adamchester 于 2017-03-09

我正在解决这个问题。现在我只关注 Src\AutoFixture.sln。

我的策略是将 Src\AutoFixture\AutoFixture.csproj 转换为新的项目格式（VS 2017），以便它可以同时支持 .NET Framework 和 .NET Standard。

我运行了 .NET Portability Test，最佳目标应该是 .NET Standard 1.5（见附件）。

首先，我不会转换测试项目，尽管我假设我们将来可能还想在 .NET Core 运行时中运行测试。

AutoFixtureNetPortabilityTest.zip

Kralizek 于 2017-03-12

嘿@Kralizek - 仅供参考 - 我在#712 中以netstandard1.3取得了成功

adamchester 于 2017-03-12

@Kralizek我的错误，看起来我开始计划netstandard1.3但实际上最终以netstandard1.5 👍

adamchester 于 2017-03-12

快好了。 .NET Framework 中的测试都是绿色的。构建在 .NET Standard 中都是红色的。 :D

我只遇到了以下几类问题：

不需要发电机
只有一种情况MailAddressGenerator ，因为System.Net.Mail.MailAddress在 .NET Standard 中不可用。解决方案：整个文件已被#if NET40 ... #endif“删除”

序列化
.NET Standard 中不存在 SerializableAttribute、SerializationInfo 和 StreamingContext。此外， Exception 没有采用这两种类型的构造函数。使用编译器指令，我从所有异常中删除了属性和构造函数。尤其是删除属性并不是很漂亮。

使用反射来获取有关类型的信息
在 .NET Standard Type中要差得多。一切都委托给包含所有使用的属性的 TypeInfo 对象。问题是 .NET Framework 仍然使用旧的 Type 类。
解决方案：
我创建了一个扩展方法，它转发完全相同的 Type 对象public static Type GetTypeInfo(this Type type) => type;并通过编译器指令使这个扩展方法仅在 .NET Framework 中可用。这个技巧解决了许多不兼容的问题，使文件保持不变。注意：扩展方法被标记为internal 。

使用反射获取当前程序集
好吧，这个很难，因为我不完全了解项目布局。我使用 ReSharper 快速检查类层次结构，但你们应该仔细检查。
文件是TerminatingWithPathSpecimenBuilder ，行是var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; 。看起来您正在寻找我们所在的程序集。由于此类没有继承者，因此可以安全地假设typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly返回相同的结果，但同样，我可能错了。（我把假扩展方法放在括号里）。如果我的假设是正确的，我建议将这个类标记为sealed以避免它被继承和破坏它的风险。

无论如何，让我向您介绍新的项目文件。

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

是的，这是整个项目文件。

Kralizek 于 2017-03-12

🎉1

@Kralizek你有没有注意到我们打算在v4分支中定位 >= net45 ？

adamchester 于 2017-03-12

@adamchester不......应该没有那么重要，但我会改变目标框架。感谢您的提醒！ 👍

顺便说一句，我发现System.Threading.Thread可以作为包使用。

它解锁了一个全新的编译器错误级别......很好：P

Kralizek 于 2017-03-12

.NET Standard 2.0 应该加很多api回来，也许值得等待？

nnyegaard 于 2017-03-13

不，这不对。 .NET Standard 2.0 将于 2017 年第三季度发布。我们距离支持 .NET Standard 1.5 仅有一次承诺，为什么要等待 2.0？对于在运行时生成邮件消息永远不会支持吗？

此外，2.0 主要是框架 4.6 的一个垫片，周围会抛出很多 NotSupportedException。

Kralizek 于 2017-03-13

👍4

@Kralizek足够公平。我当然喜欢 autofixter 发布得更快，所以是一个更普遍的问题。

nnyegaard 于 2017-03-14

FWIW，我是添加对邮件地址生成器的支持的贡献者，虽然，很高兴 AutoFixture 支持开箱即用，但这绝不是 AutoFixture 的重要方面，值得付出努力等待它。

恕我直言，在尽可能低的 .NET Standard 上拥有 AutoFixture 应该是最优先的。继续努力，如果您正在寻找任何帮助或支持来测试它，那么我绝对可以参与。

tiesmaster 于 2017-03-15

👍7

@Kralizek TypeInfo 的东西也存在于 .NET 4.5 中，所以它会有所帮助。

DerAlbertCom 于 2017-03-23

今天开始向许多 .NET Core 项目添加测试时，被错误“Package AutoFixture 3.50.5 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1)”所困扰。

我正在请求“.net core 的自动修复状态”类型的回复，它给出了这个非常有用的 nuget 包何时可用于该平台的方向（并且 .net core 2.0 已经是 rtm 并且待发布..） .

是什么阻碍了它？（提前致谢）

andersborum 于 2017-08-14

我们目前正在努力，您可以在 #773 中跟踪进度。注意，这个 PR 是关于AutoFixture项目本身的。我们还有 9 个其他项目应该迁移，但只有在我们完成这个项目的工作后才能完成。

.NET Core 支持将作为 v4 发布，您可以在此处找到整个范围。我预计一切准备就绪还需要几个月的时间。

同时，我们也在开发 Dev NuGet 提要 (#762)，所以你将能够参与早期的产品测试😉

zvirja 于 2017-08-14

👍1

@zvirja感谢您的详细更新。我相信它也会对其他开发人员派上用场。我很乐意参与早期的产品测试。

andersborum 于 2017-08-14

🎉1

@zvirja所以只是为了澄清 - 当前（临时）针对 .NET Core 应用程序/库编写单元测试的方法是在例如.NET 4.7测试项目中使用AutoFixture并迁移测试项目到 .NET Core 以后？

这是目前建议的解决方法吗？（只要允许我编写的应用程序完全是 .NET Core，在常规.NET 4.7环境中编写测试实际上并不是什么大问题）。

andersborum 于 2017-08-14

@andersborum我从没想过临时解决方法。我不确定我们在 v3 中使用的所有 API（包，发布到 NuGet）都符合 .Net Standard 2.0（使用 .NET Standard 的新功能）。

如果您找到了一种结合 v3 和 .Net Core 的方法，请告诉我们，以便我们可以向其他人提供建议 😉

zvirja 于 2017-08-15

只是为了通知大家 - AutoFixture PR (#773) 的 .Net Standard 支持已合并到v4分支。您可以从我们的私人提要中消费包裹。

请注意，仅迁移了 AutoFixture 库。其他胶水库稍后会跟进。

zvirja 于 2017-08-22

🎉6 ❤5 👍4

是否可以将 v4 移动到 nuget.org，甚至是 alpha 版本？直到现在都找不到任何可与 autofixture 相媲美的支持 .netstandard 的东西。
v4 的发布日期已经确定了吗？

RoCore 于 2017-08-30

@RomanKernSW目前还没有 - 我们甚至还没有迁移一半的项目（比如 xUnit、NUnit、NSubstitute 支持），所以现在还为时过早。我们也有更改命名空间的计划，所以我更愿意这样做_before_我们公开发布一些东西，因为这将是发布之间的重大突破。另一方面，我想尽可能晚地更改命名空间，因为我们不断将master合并到v4并且在更改后这样做会很糟糕。

您对私人提要有任何问题吗？如果强烈需要，您可以通过NuGet.config添加提要。

zvirja 于 2017-08-30

嗯，我必须检查是否可以使用 nuget.config 进行 nuget 还原（.Net Core 2 - VSO 中的预览任务）。现在，我们有一个带有 nuget.org 的私有源 (VSO)，没有任何 nuget.config 文件。需要时间来测试一下...

RoCore 于 2017-08-30

👍1

.Net Standard 2.0 具有 .Net Framework NuGets 的兼容模式。
我已经用 AutoFixture 3.50.x 编写了 .Net Core 测试，所以没有问题
远的。

roarwrecker 于 2017-08-30

👍1

@roarwrecker 太棒了，感谢分享！这意味着在我们推出对 NuGet 的官方支持之前，我们有更大的时间缓冲：wink：

zvirja 于 2017-08-30

@roarwrecker谢谢...这不是 .netstandard 1.6 的问题。我可以安装 nuget，但它永远不会编译没有错误

RoCore 于 2017-08-30

嘿伙计们，不确定 .NetCore 工作有多远，但是否有可能在 NuGet 上获得 alpha 版本？

selmendorfFrontline 于 2017-09-28

@selmendorfFrontline从这里复制回复：

将预发布版本发布到 NuGet 对我来说是一个有点痛苦的问题。虽然我们开始为大多数项目支持 .NET Core，但我们计划更改默认命名空间。这对我们的客户来说将是一个巨大的突破性变化，所有的客户端代码都将停止编译。这是混淆出现的点：
如果我们使用现有命名空间释放alpha并更改alpha和 RTM 之间的命名空间，它会混淆我们的客户，因为他们已经看到 v4 与现有命名空间。我希望我们的客户觉得随着治理模型的改变，v4 总是带有一个新的命名空间。
如果我们使用更改的命名空间发布alpha ，我们将无法再无痛苦地将master合并到v4分支。目前我们对两个分支都做出了承诺，这就是为什么我想将命名空间更改推迟到最后。另一点是我们的文档目前还没有准备好，所以人们可能根本不明白为什么所有的命名空间导入都是无效的，他们需要简单地运行文本替换。那会让他们感到害怕，体验也不会像我希望的那样顺利。
解决这种情况的最好方法是不释放alpha而只释放 RTM。不幸的是，我无法为您提供准确的 ETA，因为这取决于我的能力（我在空闲时间从事这个项目）和其他贡献者的可用性（我的 PR 应该被审查😉）。在我的脑海中，我想象一两个月后发布，并希望它会在这个范围内发生。由于治理模型的变化，这个项目已经停止了大约 9 个月——这是支持延迟的主要原因。

同时请使用预览源中的包。你可以像上面提到的那样调整你的Nuget.config ，所以这应该是一个问题。

zvirja 于 2017-09-28

在#857 最终合并后，我将关闭此问题。我们最终的 .NET 兼容性表如下：

| 产品 | .NET 框架 | .NET 标准 |
| ------------------ | ------------------------ | ------------------------ |
| 自动夹具 | :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 |
| 自动对焦| :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| 汽车起订量 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| 自动替代 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |
| AutoRhinoMock | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| 成语 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 2.0 |
| 成语.FsCheck | :heavy_check_mark: 4.5.2 | :heavy_minus_sign: |
| 语义比较 | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.5 |

除了Idioms.FsCheck之外的所有不受支持的库都无法更新，因为它们的依赖项不支持 .Net Standard，而且它们不太可能会更新（其中大部分已过时）。我试图移植Idioms.FsCheck以支持.NET 452和.NET Standard 2.0 （因为它在技术上是可能的），但是无法使其工作。看来 F# SDK 还是很粗糙的，我们需要等待新的发布。在我定义TargetFrameworks节点后，编译和项目加载就会失败。

除非有人有别的愿景，否则我会按照这个计划来😃我也觉得离发布有多近，还有多少落后😊

zvirja 于 2017-10-04

🎉3 👍3

去！去！去！

MihaMarkic 于 2017-10-04

我试图移植Idioms.FsCheck以支持.NET 452和.NET Standard 2.0

您是否尝试在该版本上切换到较新的 F# 版本？ IIRC，它在 F# 3.1 上，可能就是这种情况。

moodmosaic 于 2017-10-06

伟大的工作@zvirja。你认为我们可以推出 v4 吗？我们越接近，我就越兴奋:)

我希望我能给你一杯啤酒:)

Kralizek 于 2017-10-06

您是否尝试在该版本上切换到较新的 F# 版本？ IIRC，它在 F# 3.1 上，可能就是这种情况。

@moodmosaic 是的。如果你查看FsCheck 2.9.0你会发现它依赖于FSharp.Core (>= 4.1.17) ，因此我别无选择😅 问题出在 SDK 上。如果我开始同时针对两个框架，我将无法在 VS 中加载解决方案
项目：

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

尝试在 VS 中打开：

项目一切正常 - 问题出在 F# SDK 的某个地方。这就是为什么我想将 FsCheck 对 .NET Core 的支持推迟到更好的时候。

@Kralizek请参阅上面的几个答案的回复。

zvirja 于 2017-10-06

刚刚签入 VS 2017.4，但仍然无法针对 F# 项目的多个框架。因此，我暂时关闭此问题，因为我们支持所有其他项目的 .NET Core。

zvirja 于 2017-10-11

JFYI：我向 NuGet

zvirja 于 2017-10-18

👍6 🎉5

Autofixture: 支持 CoreCLR

最有用的评论

所有77条评论

相关问题