Autofixture: CoreCLRのサポート

まだ、少なくとも。 DNXとは何ですか？

ハハ..それは新しいクロスプラットフォームのasp.netフレームワークです。 https://github.com/aspnet/DNX

ランタイムは「net451」などではなく「dnx451」です。

この文脈で「サポート」とはどういう意味ですか？ .NET4ライブラリに依存しているテストライブラリからASP.NET5をテストすることは不可能だと言っていますか？

ASPNET5は複数のプラットフォームで実行されます。 現在、dnxプラットフォームでASPNET 5を記述しているだけなので、ランタイムライブラリの別のセットです。 私たちのコードは現在「net451」用にコンパイルされていないため、ライブラリは互換性のないプラットフォームを効果的にターゲットにしています

私のテストはこの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"
}

}

面白い。 違いが何であるかを確認するために、これに取り組んでいる人にバグを報告する必要があります。
それを機能させるために何か特別なことをしましたか？

そうではありません。 IIRCAutofixtureは常にaspnet5で動作しましたが、以前はxUnit拡張機能で問題が発生していました。 これで、AFのxUnit 2サポートが終了し、DNXとxUnitがうまく連携して機能します。

ここでの考え方は、実際にはDNXではなく「CoreCLRのサポート」であるように思われます。 .NET Framework 4.5で機能するものはすべて、DNXの4.5でも機能します。 CoreCLRをサポートするにはある程度の努力が必要になる可能性がありますが、どれだけかはわかりません。 見つけるための最良の方法は、CoreCLR用にビルドしてみて、何が壊れているかを確認することです。

はい、はっきりしているべきでした。 DNXだけでなく、CoreCLRを意味しました。

coreclrリポジトリを見るだけでは、プロジェクトのステータスを把握するのは困難です。 プレビュー中ですか？ ベータ？ リリースされましたか？

まったく試していなくても、サポートされている機能がさまざまなプラットフォームで利用可能な機能の共通部分であるという点でCoreCLRがポータブルクラスライブラリのようなものである場合、変更を壊さずにAutoFixtureを改造してCoreCLRで実行できる可能性はほとんどありません。

最近、 @ moodmosaicはAtomEventStore（AutoFixtureよりもはるかに小さいプロジェクト）のでした、そしてここで結果はPCLバージョンが実行不可能であったということでした。

AutoFixtureのソースをまったく調べていなくても、私はあなたの評価に同意します。重大な変更が行われる可能性があります。 サポートが計画に含まれている場合は、 #if DNX_*スタイルのディレクティブが必要になります。

CoreCLRは、多かれ少なかれ、Windows Phone8以降で稼働しています。

ASP.NET 5は11月にRCになり、LinuxおよびMac用のCoreCLRも2015年11月にRCになります。CoreFXとともに。 2016年第1四半期に予定されているすべてのリリース1.0。

重大な変更を導入せずにCoreCLRのサポートを追加できれば、私は非常に驚きます。そこで、この問題に_4.0_マイルストーンを追加しました。

好奇心から、私はPloeh.AutoFixtureアセンブリでAPI Portability Analyzerを実行し、いくつかの興味深い結果を得ました。

シャンパンを開ける前に待ってください。 サポートされていないシンボルの大まかな3％は、残念ながら、いくつかのかなり基本的なシンボルを説明しています。

| ターゲットタイプ| ターゲットメンバー|
| --- | --- |
| 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 |

ただし、いくつかの解決策があります。

• System.Type内のプロパティへのすべての参照を、 GetTypeInfo(Type)拡張メソッドを介して利用可能なSystem.TypeInfo内の対応するものに置き換えます。
• System.SerializableAttributeへのすべての参照を削除します。
• System.Runtime.Serialization.SerializationInfoへのすべての参照を削除します（おそらく_例外コンストラクタ_でのみ使用されます）。
• System.Net.Mail.MailAddressへのすべての参照を削除します。
• System.Reflection.MemberInfo.ReflectedTypeプロパティへのすべての参照を削除し、反映されたオブジェクトを使用してその型を保持します。
• 代わりに、 System.Reflection.PropertyInfo.GetSetMethodプロパティへのすべての参照をSystem.Reflection.PropertyInfo.SetMethodプロパティに置き換えます。

これは最初のパスに過ぎず、CoreCLRがまだ開発中であるため、状況が変わる可能性があります。 少なくとも、AutoFixtureと互換性を持たせるには何が必要かについての一般的な考えは得られました。

わあ、この分析を実行してくれてありがとう、

互換性のないタイプの一部（例： MailAddress ）は、完全なフレームワークでのみ機能するアドオンライブラリに移動できます。 バージョン4の_Ploeh.AutoFixture_ライブラリからいくつかの機能を

PropertyInfo.GetSetMethodをPropertyInfo.SetMethodに置き換えるというアイデアは良いことです。 AFAICT、.NET 4.5以降でのみ機能しますが、_v4_ブランチはすでに.NET 4.5にあるため、問題ありません。

「ジャンプイン」ラベルがこの問題に適しているかどうかわからない。 通常、これは、かなり簡単で新しい寄稿者に優しい、小さな、孤立した、一口サイズの問題を示すために使用されます。 この問題には、コードベースの大部分とその履歴をかなりよく理解する必要があるようです。

@chaitanyagurrapu 、おそらくあなたは正しいです。

_jump in_ラベルを追加した理由は、この作業がAutoFixtureの詳細とは多少無関係であると考えるためです。 はい：さまざまな非互換性に対処する方法を決定する必要がありますが、CorCLRに関連してコード/ビルドインフラストラクチャ全体がどのように機能するかを理解するだけでも多くの作業があり、その部分はAutoFixtureとはまったく関係ありません。

現時点では、これらのスキルを持っていないので、これを手伝ってもらいたいです。 互換性の問題に関して行う必要のある決定は、ここまたは専用のGithubの問題で説明できます。

私はこれに取り組み始めました。 来る質問:)

私にはいいですね：+1：

@lbargaoanuいいですね：+1：可能であれば、小さくしてください。

MailAddressGeneratorをv4ブランチの完全なフレームワークを対象とする別のプロジェクトに移動して、.NETCore用のAutoFixtureをビルドできるようにします。 .NET Coreのプレースホルダー型を宣言することもできますが、これまで条件付きコンパイルは避けてきました。 そして、完全なフレームワークでのみサポートされるものが常にあります。

作業中です。 しかしその間...

将来の参考のために
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

いい投稿です！ ライブラリもカバーしていますか？ （_library_を検索しましたが、あまり見つかりませんでした...）

:)これでライブラリについてはすべてですが、この投稿とそのリンクで十分です。

AutoFixtureがCoreCLRでも機能し、必要に応じて喜んでお手伝いしてくれることを望んでいます。 Lucian Bargaoanuの最後のPR（＃511、および＃513）を見ると、この問題はいくつかの未解決の議論で古くなったようです。

ボールを転がしたいのですが、全体的な計画がどうだったのか、議論を妨げていた詳細のいくつかにどう対処するのかわかりません。 したがって、すべての詳細に入る前に、そのようなことを理解しておくと便利な場合があります。

私が浮かんでいるのを見た、または私が自分自身を持っているいくつかの質問：

• AutoFixtureをPCLに変換する必要がありますか、それとも共有プロジェクトのようなものを使用する必要がありますか？
• どのプラットフォームが間違いなく必要であるか、または長期的に必要ですか？ （.NET、CoreCLR、UWP？）
• このようなプロジェクトでは条件付きコンパイルは不要ですか？

@ploehこれらの質問のすべてにあなたが答えることができるわけではないことを@lbargaoanuこれについて何か意見がありますか？ ありがとう！

このスレッドに返信するのを忘れているようです。 私の謝罪を受け入れてください：フラッシュ：

.NET Core用のAutoFixtureコードベースを準備するために実行できる作業は、コードベースを劣化させたり、重大な変更を導入したりしない限り、歓迎されます。

重大な変更は引き続き可能ですが、_v4_ブランチに移動する必要があります。

いずれにせよ、しかし、私は、現状のままで不当と思われる変更については、正当な理由が必要です。 .NET Coreの状況を厳密に追跡しているとは言えませんが、まだ多くのスラッシングが発生しているようであり、ターゲットがまだ動いている限り、投機的な変更を導入することには熱心ではありません。

条件付きコンパイルが必要になっても驚かないでしょうし、それを正気に保つことができる限り、私はそれに反対しません。 公開する必要のあるものをビルドするためにビルドスクリプトを実行できる場合は、おそらく問題ありません。 しかし、私はこれについて多くの経験を持っていないことを認めなければなりません。

また、どのプラットフォームが必要かわかりません。 基本的に、コミュニティの誰かが、保守しやすいように見え、AutoFixtureの範囲を拡大するプルリクエストを送信した場合は、それらを受け入れることを検討します。

AFAICTでは、 netstandard1.Xをターゲットにする必要があります。これは、APIを実装する任意のプラットフォーム（Windowsのみのネットコアクロスプラットフォームとネットフレームワークを含む）で実行されるAPIのセットです。

https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.mdを参照して

一般に、数値が大きいほどAPIは多くなりますが、サポートされるプラットフォームは少なくなります。 netstandard1.XどのXをターゲットにするかを理解することから、おそらくこの議論を開始（継続）する必要があります。

その文書の最初の段落は私を少し怖がらせます：

.NETクラスライブラリを構築する将来の初期計画を共有しています。
--https：//github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaicそれも私を怖がらせますが、問題は、ターゲットにするAPIを選択するという一般的な概念がどちらの方法でも本質的に必要になるということです。 netstandardは、よく知られている名前と合意されたサブセット、およびそれらを説明するためのより簡単な方法を提供します。 それは、そもそもポータブルになりたかったことを前提としています。

たとえば、AutoFixture用のリフレクションAPIが必要な場合、持つ可能性のあるターゲットのリストが減ります。 同時コレクションが必要な場合も同様です。 これらのプラットフォーム（ネットフレームワークフル、Windows Phoneなど）はすでに存在するため、必要なAPIについて話し合っても変更できるものではないと思います。

私は会話を開始するかもしれません...（免責事項：私もまだこのことを学んでいます）

私は、すでに最大数のプラットフォームに実装されている最低（ netstandard1.0 ）から始めて、そのプラットフォームにコミットできない（またはコミットしない）理由を探します。

私の理解によると、APIのnetstandard1.0セットはかなり古く、制限があります。 次のようなものはありません。

• 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をターゲットにするのは現実的ではないと思います。

ここで@ecampidoglioによって言及されたアナライザーを待つことがより良い戦略であるかどうか疑問に思います。

編集：ここに.NET APIポータビリティアナライザツールリポジトリがあり、ここにWebサイトhttp://dotnetstatus.azurewebsites.netがあります

コメントスパムが多すぎて申し訳ありません。今すぐやめます:)

参考までに、v4 4a7d415からローカルに構築されたPloeh.AutoFixture.dllで最新のポータビリティアナライザーを実行しました。要約は次のとおりです。

現在推奨されている変更は次のとおりです。

完全な出力はここにあり

@ploeh Asp.Net Coreの多くの広く使用されているコンポーネントには、少なくともnetstandard1.3必要です。 この例には、EntityFrameworkCore（1.3を使用）およびMvc（1.6を使用）が含まれます。

Autofixtureがこれらのいずれかをベースラインとして使用した場合、それは良い場所になると思います。

.Net Coreサポートが利用可能になる時期についてのタイムラインはありますか？

私はv4ブランチに基づいて.NETCoreでビルドを行うことができました。 しかし、私はテストプロジェクトを構築しようとはしませんでした。 パッケージを作成したい場合は、このブランチをチェックしてください。

FWIW、これがAutoFixture / AutoFixturev4とuhaciogullari / AutoFixtureネットコアの

まあ、それは本当に簡単ではありません。 project.jsonが存在すると、現在、通常のcsprojプロジェクトのビルドでエラーが発生します。 すべてのプロジェクトをproject.json形式に移行できますが、それが他のプロジェクトにとって良いアイデアかどうかはわかりません。 詳細は確認していませんが、他のテストフレームワークのプラグインだと思います。 .NETCoreもサポートしているかどうかはわかりません。

もう1つは、 Microsoftがproject.jsonから間もなく移行し、 csprojに戻ることを発表したことです。 簡単な移行を約束しますが、この一時的な形式を使用するために時間をかけたいですか？ それはすべてあなた次第です。 現在のブランチからパッケージをプッシュすることはできますが、v4は進行中のようです。

エラーなしでビルドする方法があります：＃712

私は実際にあなたのブランチからビルドしようとしましたが、dllを生成しません。 おそらくいくつかの構成が欠落していますが、各プロジェクトに追加のフォルダーを作成しても、見た目には魅力的ではありませんでした。

これに関する更新はありますか？

.netコアツールがRTMステータスに達するまで待つのが賢明だったと思います。 更新されたcsprojツールはVS2015に移植されないため、VS2017でのみ使用できます。 https://twitter.com/TheCodeJunkie/status/822048014172880900を参照して

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

@ hoetzvs2017コミュニティエディションは引き続きインストールできます。

この問題を検討する予定はありますか？

AitoFixtureなしで.NET標準アセンブリのテストを書くのは本当に気分が悪いです...

みなさん、こんにちは。コミュニティの誰かが参加して貢献する必要があります。 ガバナンスモデルの問題はまだ解決されていないため、現時点では明らかに困難です（＃703）。 誰かもその前線に足を踏み入れる必要があります。

私は問題をいじっています。 現在、私はSrc \ AutoFixture.slnのみに焦点を当てています。

私の戦略は、Src \ AutoFixture \ AutoFixture.csprojを新しいプロジェクト形式（VS 2017）に変換して、.NETFrameworkと.NETStandardの両方をサポートできるようにすることです。

.NET Portability Testを実行しましたが、最適なターゲットは.NET Standard 1.5です（添付ファイルを参照）。

そもそも、テストプロジェクトを変換することはしませんが、将来的には.NETCoreランタイムでもテストを実行したいと思うかもしれません。

AutoFixtureNetPortabilityTest.zip

ねえ@ Kralizek-ちょうどnetstandard1.3成功しました

@Kralizek私の間違い、私はnetstandard1.3計画を始めたようですが、実際にはnetstandard1.5 👍

もうすぐです。 .NET Frameworkでは、テストはすべて緑色です。 .NETStandardではビルドはすべて赤です。 ：D

私はこれらのカテゴリーの問題だけに会いました：

ジェネレーターは必要ありません
System.Net.Mail.MailAddressは.NET標準では使用できないため、 MailAddressGenerator 1つのケースのみです。 解決策：ファイル全体が#if NET40 ...＃endifによって「削除」されました

シリアル化
SerializableAttribute、SerializationInfo、およびStreamingContextは、.NETStandardには存在しません。 また、Exceptionには、これら2つの型をとるコンストラクターがありません。 コンパイラ指令を使用して、すべての例外から属性とそのコンストラクタを削除しました。 特に属性を削除することは本当にきれいではありません。

タイプに関する情報を取得するためのReflectionの使用
.NET標準では、 Typeははるかに貧弱です。 すべてが、使用されるすべてのプロパティを含むTypeInfoオブジェクトに委任されます。 問題は、.NETFrameworkがまだ​​古いTypeクラスを使用していることです。
解決：
まったく同じTypeオブジェクトpublic static Type GetTypeInfo(this Type type) => type;を転送する拡張メソッドを作成し、この拡張メソッドをコンパイラ指令を介して.NETFrameworkでのみ使用できるようにしました。 このトリックは、ファイルをそのままにしておく多くの非互換性を解決しました。 注：拡張メソッドはinternalとしてマークされています。

現在のアセンブリを取得するためのReflectionの使用
プロジェクトのレイアウトがよくわからないので、これは大変でした。 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は、 v4ブランチで> = net45をターゲットにするつもりであることに気づきましたか？

@adamchesterいいえ...それほど重要ではありませんが、ターゲットフレームワークを変更します。 ヘッドアップをありがとう！ 👍

ところで、 System.Threading.Threadがパッケージとして利用できることがわかりました。

それはまったく新しいレベルのコンパイラエラーのロックを解除しました... nice：P

.NET Standard 2.0多くのAPIを追加する必要がありますが、待つ価値はありますか？

いいえ、ちがいます。 .NET Standard 2.0は2017年第3四半期にリリースされる予定です。.NETStandard1.5のサポートから1コミット離れていますが、なぜ2.0を待つ必要があるのでしょうか。 ランタイムでメールメッセージを生成するためにそれをサポートすることは決してありませんか？

また、2.0はほとんどフレームワーク4.6のシムであり、多くのNotSupportedExceptionがスローされます。

@Kralizekまあまあ。 もちろん、autofixterがもっと早くリリースされるのが好きなので、もっと一般的な質問でした。

FWIW、私はメールアドレスジェネレーターのサポートを追加した寄稿者です。AutoFixtureがすぐにサポートできるようになったのは素晴らしいことですが、AutoFixtureの重要な側面ではなく、努力する価値があります。それを待つ。

AutoFixtureを可能な限り低い.NET標準に設定することが、最も優先されるはずです、IMHO。 良い仕事を続けてください、そしてあなたがそれをテストすることで助けまたはサポートを探しているなら、私は間違いなく売り込むことができます。

@KralizekTypeInfoのものは.NET4.5にも存在するので、役に立ちます。

多数の.NETCoreプロジェクトにテストを追加し始めたときに、「Package AutoFixture 3.50.5はnetcoreapp1.1（.NETCoreApp、Version = v1.1）と互換性がありません」というエラーに悩まされました。

この非常に便利なnugetパッケージがこのプラットフォームでいつ利用可能になるかについての方向性を示す「.netcoreの自動フィクスチャの状態」のような応答を求めています（.net core 2.0はすでにrtmであり、リリースが保留されています..） 。

何がそれを妨げているのですか？ （前もって感謝します）

現在取り組んでおり、＃773で進捗状況を追跡できます。 このPRは、 AutoFixtureプロジェクト自体に関するものであることに注意してください。 移行する必要のあるプロジェクトは他に9つありますが、これは、このプロジェクトの作業が終了した後でのみ実行する必要があります。

.NET Coreのサポートはv4としてリリースされます。スコープ全体は、

その間、Dev NuGetフィード（＃762）にも取り組んでいるため、初期の製品テストに参加できます😉

@zvirja詳細な更新に感謝します。 他の開発者にも役立つと思います。 初期の製品テストに参加できれば幸いです。

@zvirja明確にするために、.NET Coreアプリケーション/ライブラリに対して単体テストを作成する現在の（一時的な）アプローチは、たとえば.NET 4.7テストプロジェクトでAutoFixture 、テストプロジェクトを移行することです。後で.NETCoreに移行しますか？

これは当面の推奨される回避策ですか？ （私が書いているアプリが完全に.NET Coreであることが許可されている限り、通常の.NET 4.7環境でテストを書くことは実際には大きな問題ではありません）。

@andersborum一時的な回避策については考えたことはありません。 v3で使用するすべてのAPI（パッケージ、NuGetに公開）が.Net Standard 2.0に準拠しているかどうかはわかりません（.NET Standardの新機能を使用するため）。

v3と.NetCoreの両方を組み合わせる方法を見つけた場合はお知らせください。そうすれば、他の人にアドバイスすることができます😉

みんなに通知するだけです-AutoFixturePR（＃773）の.NetStandardサポートがv4ブランチに統合されました。 あなたは私たちのプライベートフィードからパッケージを消費することができます。

AutoFixtureライブラリのみが移行されていることに注意してください。 他の接着剤ライブラリは後でフォローアップします。

アルファ版であっても、v4をnuget.orgに移動することは可能ですか？ これまで、.netstandardをサポートするautofixtureに匹敵するものは見つかりませんでした。
v4のリリース日はすでに決まっていますか？

@RomanKernSW現時点ではありません-プロジェクトの半分（xUnit、NUnit、NSubstituteサポートなど）もまだ移行していないため、時期尚早です。 また、名前空間をmasterをv4に常にマージしているので、名前空間をできるだけ後で変更したいと思います。変更後にそれを行うのは大変です。

プライベートフィードに問題がありますか？ 強く必要な場合は、 NuGet.configを介してフィードを追加できます。

hm nugetの復元にnuget.configを使用できるかどうかを確認する必要があります（.Net Core 2-VSOでのタスクのプレビュー）。 現在、nuget.configファイルのないnuget.orgを含む1つのプライベートフィード（VSO）があります。 これをテストする時間が必要です...

.Net Standard 2.0には、.Net FrameworkNuGetsの互換モードがあります。
AutoFixture3.50.xを使用して.NetCoreテストを作成しましたが、問題はありません。
遠い。

@roarwrecker素晴らしい、共有してくれてありがとう！ つまり、NuGetへの公式サポートを展開するまでの時間バッファーが大きくなります：wink：

@roarwreckerありがとう...これは.netstandard1.6の問題ではありませんでした。 nugetをインストールできましたが、エラーなしでコンパイルされることはありません

やあみんな、.NetCoreの作業がどこまで進んでいるかはわかりませんが、NuGetでアルファ版を入手することは可能ですか？

@selmendorfFrontlineここから返信します：

プレリリースバージョンをNuGetに公開することは、私にとって少し辛い質問です。 ほとんどのプロジェクトで.NETCoreのサポートを開始しましたが、デフォルトの名前空間をあります。 これはクライアントにとって大きな重大な変更であり、すべてのクライアントコードのコンパイルが停止します。 これは混乱が現れるポイントです：

• 既存の名前空間でalphaをリリースし、 alphaとRTMの間で名前空間を変更すると、クライアントは既存の名前空間でv4をすでに見ているため、混乱します。 ガバナンスモデルが変更されたため、v4は常に新しい名前空間でリリースされたとクライアントに感じてもらいたいです。
• 名前空間を変更してalphaをリリースすると、 masterをv4ブランチに簡単にマージできなくなります。 現在、両方のブランチにコミットしているため、名前空間の変更を最後まで延期したいと思います。 もう1つのポイントは、ドキュメントの準備ができていないため、名前空間のインポートがすべて無効である理由がわからない可能性があり、テキスト置換を実行するだけでよいということです。 それは彼らを怖がらせ、経験は私が望むほどスムーズではなくなります。

この状況を解決する最善の方法は、 alphaをリリースせず、RTMのみをリリースすることです。 残念ながら、正確なETAは、私の能力（私は自由時間にこのプロジェクトに取り組んでいます）と他の貢献者の可用性（私のPRを確認する必要があります😉）に依存するため、提供できません。 私の頭の中では、1、2か月でリリースされることを想像しており、この範囲内でリリースされることを望んでいます。 このプロジェクトは、ガバナンスモデルの変更により、約9か月間停止しました。これが、このようなサポートの遅延の主な理由です。

それまでの間、プレビューフィードのパッケージを使用してください。 上記のようにNuget.configを調整できるので、これは問題になるはずです。

＃857が最終的にマージされた後、この問題をクローズします。 最終的な.NET互換性テーブルは次のようになります。

| 製品| .NET Framework | .NET標準|
| ------------------ | ------------------------ | ------------------------ |
| 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：|
| イディオム| ：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 |

Idioms.FsCheckを除くすべてのサポートされていないライブラリは、依存関係が.Net Standardをサポートしておらず、更新される可能性が低いため、更新できません（ほとんどのライブラリは廃止されています）。 .NET 452と.NET Standard 2.0両方をサポートするためにIdioms.FsCheckを移植しようとしましたが（技術的には可能です）、それを機能させることができませんでした。 F＃SDKはまだかなり荒いようで、新しいリリースを待つ必要があります。 TargetFrameworksノードを定義した後、コンパイルとプロジェクトのロードが失敗するだけです。

他のビジョンがない限り、私はこの計画に従います😃リリースにどれだけ近づいていて、どれだけ遅れているかも感じます😊

行け！行け！行け！

.NET 452と.NET Standard 2.0両方をサポートするためにIdioms.FsCheckを移植しようとしました

そのバージョンで新しいF＃バージョンに切り替えてみましたか？ IIRC、それはF＃3.1にあり、これが当てはまるかもしれません。

素晴らしい仕事@zvirja。 v4を出すことができると思いますか？ 近づくほど、ワクワクします:)

私はあなたにビールを提供できたらいいのにと思います:)

そのバージョンで新しい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による.NETCoreのサポートをより良い時期まで延期したいと思います。

@Kralizek上記のいくつかの回答の返信をご覧ください。

VS 2017.4でチェックインしたばかりですが、F＃プロジェクトの複数のフレームワークをターゲットにすることはできません。 したがって、他のすべてのプロジェクトで.NET Coreをサポートしているため、この問題は今のところ閉じています。

JFYI：v4 rc1をNuGetにリリースしたので、カスタムフィードを操作しなくても、消費してテストできます。