Autofixture: Dukungan untuk CoreCLR

Belum, setidaknya. Apa itu DNX?

Haha.. ini kerangka kerja asp.net lintas platform baru. https://github.com/aspnet/DNX

runtime adalah "dnx451" bukan "net451", dll.

Apa yang dimaksud dengan "dukungan untuk" dalam konteks ini? Apakah Anda mengatakan bahwa tidak mungkin menguji ASP.NET 5 dari pustaka uji dengan ketergantungan pada pustaka .NET 4?

ASPNET 5 berjalan di berbagai platform. Kami hanya menulis ASPNET 5 pada platform dnx sekarang, jadi ini adalah kumpulan pustaka runtime yang berbeda. Kode kami saat ini tidak dikompilasi untuk "net451", sehingga perpustakaan secara efektif menargetkan platform yang tidak kompatibel

Pengujian saya berjalan dengan baik dengan project.json ini:

{
"ketergantungan": {

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

}

menarik. Saya harus mengganggu orang yang mengerjakan ini untuk melihat apa perbedaannya.
Apakah Anda melakukan sesuatu yang istimewa untuk membuatnya bekerja?

Tidak benar-benar, tidak. IIRC Autofixture selalu bekerja dengan aspnet 5 tetapi di masa lalu saya mengalami masalah dengan ekstensi xUnit. Sekarang dukungan xUnit 2 untuk AF sudah keluar dan DNX & xUnit bermain bersama dengan baik, itu hanya berfungsi.

Tampaknya ide di sini benar-benar "dukungan untuk CoreCLR", bukan DNX. Apa pun yang berfungsi untuk .NET Framework 4.5 akan berfungsi untuk 4,5 di DNX. CoreCLR kemungkinan akan membutuhkan beberapa upaya untuk mendukung, tetapi saya tidak tahu berapa banyak. Cara terbaik untuk mengetahuinya adalah dengan mencoba membangunnya untuk CoreCLR dan melihat apa yang rusak.

Ya, saya seharusnya jelas. Maksud saya CoreCLR, bukan hanya DNX.

Dari hanya melihat di coreclr repo , sulit bagi saya untuk mendapatkan status proyek. Apakah dalam pratinjau? Beta? Dilepaskan?

Tanpa mencobanya sama sekali, jika CoreCLR mirip dengan Perpustakaan Kelas Portabel di mana fitur yang didukung adalah persimpangan fitur yang tersedia di berbagai platform, sangat tidak mungkin untuk memperbaiki AutoFixture untuk berjalan di CoreCLR tanpa merusak perubahan.

Baru-baru ini, @moodmosaic sangat baik untuk membuat analisis untuk AtomEventStore (proyek yang jauh lebih kecil daripada AutoFixture), dan di sini hasilnya adalah versi PCL tidak layak .

Tanpa melihat sumber AutoFixture sama sekali, saya setuju dengan penilaian Anda: perubahan yang melanggar mungkin terjadi. #if DNX_* -style directive akan diperlukan jika support ada dalam rencana.

CoreCLR, kurang lebih, berjalan sejak Windows Phone 8.

ASP.NET 5 akan menjadi RC pada bulan November, CoreCLR untuk Linux dan Mac juga akan menjadi RC pada bulan November 2015. Bersamaan dengan CoreFX. Rilis 1.0 untuk semua yang direncanakan untuk 1Q2016.

Akan sangat mengejutkan saya jika mungkin untuk menambahkan dukungan untuk CoreCLR tanpa memperkenalkan perubahan yang melanggar, jadi saya telah menambahkan tonggak _4.0_ ke masalah ini.

Karena penasaran, saya menjalankan API Portability Analyzer pada perakitan Ploeh.AutoFixture dan mendapatkan beberapa hasil yang menarik:

Tunggu sebelum Anda membuka Champagne. Sayangnya, 3% simbol yang tidak didukung itu menyumbang beberapa simbol yang agak mendasar:

| Jenis sasaran | Anggota sasaran |
| --- | --- |
| Sistem.Konsol | 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) |
| Jenis Sistem | M:System.Type.get_IsGenericTypeDefinition |
| Jenis Sistem | M:System.Type.get_IsEnum |
| Jenis Sistem | M:System.Type.get_BaseType |
| Jenis Sistem | M:System.Type.get_IsPrimitive |
| Jenis Sistem | M:System.Type.get_Assembly |
| Jenis Sistem | M:System.Type.get_IsGenericType |
| Jenis Sistem | M:System.Type.GetTypeCode(System.Type) |
| Jenis Sistem | M:System.Type.get_IsClass |
| Jenis Sistem | M:System.Type.get_IsValueType |
| Jenis Sistem | M:System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | M:System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | M:System.Reflection.PropertyInfo.GetSetMethod |
| Pengecualian Sistem | M:System.Exception.#ctor(System.Runtime.Serialization.SerializationInfo,System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | M:System.Reflection.MethodBase.GetCurrentMethod |

Namun, ada beberapa solusi:

• Ganti semua referensi ke properti di System.Type dengan referensi yang sesuai di System.TypeInfo , tersedia melalui metode ekstensi GetTypeInfo(Type) .
• Hapus semua referensi ke System.SerializableAttribute .
• Hapus semua referensi ke System.Runtime.Serialization.SerializationInfo (kemungkinan hanya digunakan di _exception constructors_).
• Hapus semua referensi ke System.Net.Mail.MailAddress .
• Hapus semua referensi ke properti System.Reflection.MemberInfo.ReflectedType dan gunakan objek yang direfleksikan untuk mendapatkan tipenya.
• Ganti semua referensi ke properti System.Reflection.PropertyInfo.GetSetMethod dengan properti System.Reflection.PropertyInfo.SetMethod sebagai gantinya.

Ini hanya lintasan pertama dan hal-hal mungkin berubah karena CoreCLR masih dikembangkan. Setidaknya kami mendapat gambaran umum tentang apa yang diperlukan untuk membuat AutoFixture kompatibel dengannya.

Wow, terima kasih @ecampidoglio , untuk melakukan analisis ini :+1:

Beberapa jenis yang tidak kompatibel (misalnya MailAddress ) dapat kita pindahkan ke perpustakaan tambahan yang hanya berfungsi pada kerangka kerja penuh. Saya sudah berpikir untuk menarik beberapa fitur dari perpustakaan _Ploeh.AutoFixture_ untuk versi 4 .

Ide untuk mengganti PropertyInfo.GetSetMethod dengan PropertyInfo.SetMethod itu bagus. AFAICT, itu hanya akan bekerja di .NET 4.5+, tapi tidak apa-apa, karena cabang _v4_ sudah ada di .NET 4.5.

Tidak yakin apakah label "Lompat Masuk" sesuai untuk masalah ini. Biasanya digunakan untuk menunjukkan masalah kecil, terisolasi, berukuran gigitan yang cukup mudah dan ramah bagi kontributor baru. Tampaknya masalah ini memerlukan pemahaman yang cukup baik tentang sebagian besar basis kode dan sejarahnya.

@chaitanyagurrapu , mungkin Anda benar.

Alasan saya menambahkan label _jump in_ adalah karena saya menganggap pekerjaan ini agak tidak terkait dengan detail AutoFixture. Ya: keputusan harus dibuat tentang cara mengatasi berbagai ketidakcocokan, tetapi ada juga banyak pekerjaan hanya mencari tahu bagaimana seluruh kode/membangun infrastruktur bekerja terkait dengan CorCLR, dan bagian itu sama sekali tidak terkait dengan AutoFixture.

Saat ini, saya tidak memiliki keterampilan ini, jadi saya ingin mendapatkan bantuan dengan ini. Keputusan yang perlu dibuat terkait masalah kompatibilitas dapat kita diskusikan di sini, atau dalam masalah Github khusus.

Saya sudah mulai mengerjakan ini. Pertanyaan yang akan datang :)

Kedengarannya bagus untuk saya :+1:

@lbargaoanu Kedengarannya bagus :+1: Ingat, jika memungkinkan, tetap kecil .

Saya ingin memindahkan MailAddressGenerator ke proyek lain yang menargetkan kerangka kerja lengkap di cabang v4, jadi saya bisa membuat AutoFixture untuk .NET Core. Saya juga dapat mendeklarasikan tipe placeholder untuk .NET Core, tetapi saya telah menghindari kompilasi bersyarat sampai sekarang. Dan akan selalu ada hal-hal yang didukung hanya dalam kerangka kerja penuh.

Ini sedang dikerjakan . Tapi sementara...

Untuk referensi di masa mendatang
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

Postingan yang bagus! Apakah itu juga mencakup perpustakaan? (Saya mencari _library_ tetapi tidak menemukan banyak...)

:) Itu saja tentang perpustakaan, tetapi posting ini dan tautannya sudah cukup.

Saya juga ingin melihat AutoFixture bekerja di CoreCLR, dan bersedia membantu jika diperlukan. Melihat PR terakhir Lucian Bargaoanu (#511, dan #513), sepertinya masalah ini menjadi basi pada beberapa diskusi yang belum terselesaikan.

Saya ingin membuat bola bergulir, tetapi tidak tahu apa rencana keseluruhan untuk ini, dan bagaimana menangani beberapa detail yang menghalangi diskusi. Jadi mungkin berguna untuk mendapatkan sesuatu seperti itu, sebelum masuk ke semua detailnya.

Beberapa pertanyaan yang pernah saya lihat beredar, atau yang saya miliki sendiri:

• haruskah AutoFixture diubah menjadi PCL, atau menggunakan sesuatu seperti proyek bersama?
• platform mana yang pasti dibutuhkan, atau diinginkan untuk jangka panjang? (.NET, CoreCLR, UWP?)
• apakah kompilasi bersyarat tidak diinginkan untuk proyek seperti ini?

@ploeh Saya dapat @lbargaoanu Apakah Anda mungkin punya masukan tentang ini? Terima kasih!

Saya melihat bahwa saya lupa membalas utas ini; terimalah permintaan maaf saya :malu:

Pekerjaan apa pun yang dapat kami lakukan untuk menyiapkan basis kode AutoFixture untuk .NET Core dipersilakan, selama itu tidak menurunkan basis kode atau memperkenalkan perubahan yang melanggar.

Melanggar perubahan masih dimungkinkan, tetapi mereka harus masuk ke cabang _v4_.

Bagaimanapun, saya memerlukan pembenaran yang baik untuk setiap perubahan yang tampaknya tidak beralasan. Meskipun saya tidak bisa mengatakan bahwa saya mengikuti situasi .NET Core dengan cermat, sepertinya masih banyak yang gagal, dan saya tidak ingin memperkenalkan perubahan spekulatif selama target masih bergerak.

Saya tidak akan terkejut jika kompilasi bersyarat akhirnya diperlukan, dan saya tidak menentangnya selama kita bisa membuatnya tetap waras. Jika saya masih dapat menjalankan skrip build untuk membangun apa pun yang perlu dipublikasikan, itu mungkin akan baik-baik saja. Saya harus mengakui, meskipun, bahwa saya tidak memiliki banyak pengalaman dengan ini.

Saya juga tidak tahu platform mana yang diinginkan. Pada dasarnya, jika ada orang di komunitas yang mengirimi kami permintaan tarik yang terlihat dapat dipertahankan, dan yang memperluas jangkauan AutoFixture, kami akan mempertimbangkan untuk menerimanya.

AFAICT, kita perlu menargetkan netstandard1.X yang merupakan kumpulan API yang akan berjalan pada platform apa pun yang mengimplementasikannya (termasuk lintas platform netcore dan kerangka kerja net pada Windows saja).

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

Secara umum, angka yang lebih tinggi memiliki lebih banyak API, tetapi platform yang kurang didukung. Kita mungkin harus memulai (melanjutkan) diskusi ini dengan memahami X mana yang harus kita targetkan dalam netstandard1.X .

Paragraf pertama dari dokumen itu membuat saya sedikit takut:

Kami berbagi rencana awal untuk masa depan membangun perpustakaan kelas .NET.
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic itu membuatku takut juga, tetapi masalahnya adalah, konsep umum untuk memilih API mana yang akan kami targetkan pada dasarnya akan diperlukan. netstandard hanya memberi mereka nama yang terkenal dan himpunan bagian yang disepakati, dan cara yang lebih mudah untuk menggambarkannya. Itu dengan asumsi kami ingin menjadi portabel di tempat pertama.

Misalnya, jika kita membutuhkan API refleksi untuk AutoFixture, daftar target yang mungkin kita miliki akan berkurang. Jika kita membutuhkan koleksi bersamaan, hal yang sama berlaku. Platform-platform itu sudah ada (net framework full, Windows phone, dll), jadi menurut saya itu bukan sesuatu yang bisa berubah jika kita membahas API mana yang kita butuhkan.

Saya mungkin [kembali] memulai percakapan... (penafian: Saya juga masih mempelajari hal ini)

Saya mulai dengan yang terendah ( netstandard1.0 ) yang sudah diimplementasikan pada jumlah platform terbesar, dan mencari alasan mengapa kami tidak dapat (atau tidak akan) berkomitmen pada platform tersebut.

Menurut pemahaman saya, set API netstandard1.0 cukup lama dan terbatas. Itu tidak memiliki hal-hal seperti:

• System.Linq.Parallel (mulai dari netstandard1.1 )
• System.Console (mulai dari netstandard1.3 )
• System.Collections.Concurrent (mulai dari netstandard1.1 )
• System.ComponentModel.Annotations (dimulai dari netstandard1.1 )
• System.Collections.Specialized (mulai dari netstandard1.3 )

Ini membuat saya berpikir bahwa AutoFixture tidak praktis untuk menargetkan netstandard1.0 .

Saya ingin tahu apakah menunggu penganalisa yang disebutkan oleh @ecampudoglio di sini adalah strategi yang lebih baik.

Sunting: di sini adalah repo alat penganalisis Portabilitas .NET API dan di sini adalah situs web http://dotnetstatus.azurewebsites.net

Maaf terlalu banyak komentar spam, saya akan berhenti sekarang :)

FYI Saya menjalankan penganalisis portabilitas terbaru pada Ploeh.AutoFixture.dll yang dibuat secara lokal dari v4 4a7d415 dan ringkasannya adalah:

Berikut adalah beberapa perubahan yang saat ini direkomendasikan:

Keluaran lengkap ada di sini .

@ploeh Banyak komponen Asp.Net Core yang banyak digunakan membutuhkan minimal netstandard1.3 . Contohnya termasuk EntityFrameworkCore (menggunakan 1.3) dan Mvc (menggunakan 1.6).

Jika Autofixture menggunakan salah satu dari ini sebagai baseline, saya pikir itu akan menjadi tempat yang baik.

Adakah jadwal kapan dukungan .Net Core mungkin tersedia?

Saya berhasil membuat build di .NET Core berdasarkan cabang v4. Saya tidak mencoba membangun proyek uji. Lihat cabang ini jika Anda ingin membuat paket.

FWIW, inilah perbandingan antara AutoFixture/AutoFixture v4 dan uhaciogullari/AutoFixture net-core . Ini terlihat bagus 👍

Yah itu tidak sesederhana itu. Keberadaan project.json menyebabkan kesalahan dalam membangun proyek csproj reguler saat ini. Kami dapat memigrasikan semua proyek ke format project.json tetapi saya tidak yakin apakah itu ide yang bagus untuk proyek lainnya. Saya belum memeriksanya secara detail tetapi saya curiga mereka adalah plugin untuk beberapa kerangka pengujian lainnya. Tidak tahu apakah mereka mendukung .NET Core juga.

Hal lain adalah Microsoft mengumumkan bahwa mereka akan segera pindah dari project.json dan mereka akan kembali ke csproj. Mereka menjanjikan migrasi yang mudah tetapi apakah Anda ingin meluangkan waktu untuk menggunakan format sementara ini? Semua terserah padamu. Saya dapat mendorong paket dari cabang saya saat ini tetapi v4 sepertinya sedang dalam proses.

Ada cara untuk membangun tanpa kesalahan: #712

Saya sebenarnya mencoba membangun dari cabang Anda tetapi tidak menghasilkan dll. Mungkin ada beberapa konfigurasi yang hilang tetapi membuat folder tambahan di setiap proyek tidak menarik bagi saya secara estetika.

Apakah ada pembaruan tentang ini?

Saya pikir itu bijaksana untuk menunggu sampai .net core tooling mencapai status RTM. Perkakas csproj yang diperbarui tidak akan di-porting ke VS2015 dan dengan demikian hanya akan tersedia di VS2017. Lihat https://twitter.com/TheCodeJunkie/status/822048014172880900

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

@hoetz Anda masih dapat menginstal edisi komunitas vs2017.

Apakah ada rencana untuk melihat masalah ini?

Rasanya sangat buruk untuk menulis tes untuk rakitan standar .NET tanpa AitoFixture...

Hai Semuanya, ini membutuhkan seseorang dari komunitas untuk masuk dan berkontribusi. Jelas sulit sekarang karena masalah model tata kelola belum terselesaikan (#703). Seseorang juga perlu melangkah di depan itu juga.

Aku sedang bermain-main dengan masalah. Saat ini saya hanya fokus pada Src\AutoFixture.sln.

Strategi saya adalah mengonversi Src\AutoFixture\AutoFixture.csproj ke format proyek baru (VS 2017) sehingga dapat mendukung .NET Framework dan .NET Standard.

Saya menjalankan .NET Portability Test dan target terbaik adalah .NET Standard 1.5 (lihat file terlampir).

Untuk memulainya, saya tidak akan mengonversi proyek pengujian, meskipun saya berasumsi kita mungkin ingin menjalankan pengujian juga di .NET Core runtime di masa mendatang.

AutoFixtureNetPortabilityTest.zip

Hai @Kralizek - Sekedar informasi - Saya sukses dengan netstandard1.3 di #712

@Kralizek kesalahan saya, sepertinya saya mulai merencanakan netstandard1.3 tetapi sebenarnya berakhir dengan netstandard1.5 👍

Hampir sampai. Semua tes berwarna hijau di .NET Framework. Build berwarna merah di .NET Standard. :D

Saya hanya menemukan kategori masalah ini:

Generator tidak diperlukan
Hanya satu kasus, MailAddressGenerator , karena System.Net.Mail.MailAddress tidak tersedia di .NET Standard. Solusi: seluruh file telah "dihapus" oleh #jika NET40 ... #endif

Serialisasi
SerializableAttribute, SerializationInfo dan StreamingContext tidak ada di .NET Standard. Juga, Pengecualian tidak memiliki konstruktor yang menggunakan kedua tipe tersebut. Menggunakan arahan kompiler, saya telah menghapus atribut dan konstruktor itu dari semua pengecualian. Terutama menghapus atribut tidak terlalu cantik.

Penggunaan Refleksi untuk mendapatkan informasi tentang Jenis
Dalam .NET Standard Type jauh lebih buruk. Semuanya didelegasikan ke objek TypeInfo yang berisi semua properti yang digunakan. Masalahnya adalah .NET Framework masih menggunakan kelas Tipe lama.
Larutan:
Saya membuat metode ekstensi yang meneruskan objek Jenis yang sama public static Type GetTypeInfo(this Type type) => type; dan membuat metode ekstensi ini hanya tersedia di .NET Framework melalui arahan kompiler. Trik ini memecahkan banyak ketidakcocokan dengan membiarkan file tidak tersentuh. Catatan: metode ekstensi ditandai sebagai internal .

Penggunaan Refleksi untuk mendapatkan Majelis saat ini
Ok, yang ini sulit karena saya tidak tahu persis tata letak proyek. Saya menggunakan ReSharper untuk memeriksa hierarki kelas dengan cepat tetapi kalian harus memeriksa ulang.
Filenya adalah TerminatingWithPathSpecimenBuilder dan barisnya adalah var thisAssembly = MethodBase.GetCurrentMethod().DeclaringType.Assembly; . Sepertinya Anda sedang mencari Majelis tempat kita berada. Karena kelas ini tidak memiliki pewaris, aman untuk mengasumsikan bahwa typeof(TerminatingWithPathSpecimenBuilder).DeclaringType[.GetTypeInfo()].Assembly mengembalikan hasil yang sama , tetapi sekali lagi, saya mungkin salah. (Saya menempatkan metode ekstensi palsu dalam tanda kurung). Jika asumsi saya benar, saya akan menyarankan untuk menandai kelas ini sebagai sealed untuk menghindari risiko mewarisi dan merusaknya.

Bagaimanapun, izinkan saya memperkenalkan Anda file proyek baru.

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

ya, ini adalah seluruh file proyek.

@Kralizek apakah Anda memperhatikan bahwa kami bermaksud menargetkan >= net45 di cabang v4 ?

@adamchester tidak... Seharusnya tidak terlalu penting tetapi saya akan mengubah kerangka kerja target. Terimakasih atas peringatannya! 👍

Btw, saya menemukan bahwa System.Threading.Thread tersedia sebagai paket .

Itu membuka tingkat kesalahan kompiler yang sama sekali baru ... bagus: P

.NET Standard 2.0 Haruskah menambahkan banyak api kembali, mungkin perlu menunggu?

Tidak. .NET Standard 2.0 akan dirilis pada Q3 2017. Kami tinggal satu komitmen lagi untuk mendukung .NET Standard 1.5, mengapa kami harus menunggu 2.0? Untuk menghasilkan pesan email saat runtime tidak akan pernah mendukungnya?

Juga, 2.0 sebagian besar akan menjadi shim dari framework 4.6 dengan banyak NotSupportedException dilemparkan ke mana-mana.

@Kralizek Cukup adil. Saya tentu saja suka autofixter dirilis lebih cepat, begitu juga pertanyaan yang lebih umum.

FWIW, saya adalah kontributor yang menambahkan dukungan untuk pembuat alamat email, dan meskipun, itu bagus karena membuat AutoFixture memiliki dukungan untuk itu di luar kotak, itu sama sekali bukan aspek penting dari AutoFixture dan sepadan dengan usaha untuk menunggu untuk itu.

Memiliki AutoFixture pada .NET Standard serendah mungkin harus memiliki prioritas paling tinggi, IMHO. Pertahankan pekerjaan yang baik, dan jika Anda mencari bantuan, atau dukungan dalam mengujinya, maka saya pasti bisa ikut serta.

@Kralizek barang TypeInfo juga ada di .NET 4.5, jadi itu akan membantu.

Digigit oleh kesalahan "Paket AutoFixture 3.50.5 tidak kompatibel dengan netcoreapp1.1 (.NETCoreApp,Version=v1.1)" hari ini ketika mulai menambahkan tes ke sejumlah proyek .NET Core.

Saya meminta jawaban "keadaan perbaikan otomatis untuk .net core" yang memberikan arahan kapan paket nuget yang sangat berguna ini akan tersedia untuk platform ini (dan .net core 2.0 sudah rtm dan menunggu rilis ..) .

Apa yang menahannya? (Terima kasih sebelumnya)

Kami sedang mengerjakannya dan Anda dapat melacak kemajuannya di #773. Perhatikan, PR ini adalah tentang proyek AutoFixture itu sendiri. Kami memiliki 9 proyek lain yang harus dimigrasikan, tetapi itu harus dilakukan hanya setelah kami menyelesaikan pekerjaan yang satu ini.

Dukungan .NET Core akan dirilis sebagai v4, Anda dapat menemukan seluruh cakupannya di sini . Saya harapkan beberapa bulan sebelum semuanya siap.

Sementara itu, kami juga sedang mengerjakan umpan Dev NuGet (#762), sehingga Anda dapat berpartisipasi dalam pengujian produk awal

@zvirja terima kasih atas pembaruan terperinci. Saya yakin itu akan berguna untuk pengembang lain juga. Saya akan senang untuk berpartisipasi dalam pengujian produk awal.

@zvirja jadi hanya untuk memperjelas - pendekatan (sementara) saat ini untuk menulis pengujian unit terhadap aplikasi/perpustakaan Inti .NET menggunakan AutoFixture dalam misalnya proyek pengujian .NET 4.7 dan memigrasikan proyek pengujian ke .NET Core di lain waktu?

Apakah ini solusi yang disarankan untuk saat ini? (selama aplikasi yang saya tulis diizinkan sepenuhnya .NET Core, sebenarnya bukan masalah besar untuk menulis tes di lingkungan .NET 4.7 ).

@andersborum Saya tidak pernah memikirkan solusi sementara. Saya tidak yakin bahwa semua API yang kami gunakan di v3 (paket, diterbitkan ke NuGet) sesuai dengan .Net Standard 2.0 (untuk menggunakan fitur baru .NET Standard).

Beri tahu kami jika Anda menemukan cara untuk menggabungkan v3 dan .Net Core, sehingga kami dapat menyarankannya kepada orang lain

Hanya untuk memberi tahu semua orang - Dukungan .Net Standard untuk AutoFixture PR (#773) telah digabungkan ke cabang v4 . Anda dapat mengkonsumsi paket dari feed pribadi kami.

Perhatikan, hanya perpustakaan AutoFixture yang telah dimigrasikan. Pustaka lem lainnya akan menyusul kemudian.

Apakah mungkin untuk memindahkan v4 ke nuget.org, bahkan versi alpha? Tidak dapat menemukan apa pun yang sebanding dengan autofixture sampai sekarang yang mendukung .netstandard.
Apakah tanggal rilis untuk v4 sudah diputuskan?

@RomanKernSW Tidak saat ini - kami belum memigrasikan bahkan setengah dari proyek (seperti dukungan xUnit, NUnit, NSubstitute), jadi ini terlalu dini. Kami juga memiliki rencana untuk mengubah namespace , jadi saya lebih suka melakukannya _before_ kami merilis sesuatu secara publik karena itu akan menjadi jeda besar di antara rilis. Di sisi lain, saya ingin mengubah namespace secepat mungkin, karena kami terus-menerus menggabungkan master ke v4 dan akan sangat sulit untuk melakukannya setelah perubahan.

Apakah Anda memiliki masalah dengan feed pribadi? Anda dapat menambahkan umpan melalui NuGet.config jika itu sangat dibutuhkan.

hm saya harus memeriksa apakah mungkin menggunakan nuget.config untuk pemulihan nuget (.Net Core 2 - pratinjau Tugas di VSO). Saat ini, kami memiliki satu Umpan pribadi (VSO) dengan nuget.org tanpa file nuget.config. Perlu waktu untuk menguji ini ...

.Net Standard 2.0 memiliki mode kompatibilitas untuk .Net Framework NuGets.
Saya telah menulis tes .Net Core dengan AutoFixture 3.50.x dan tidak ada masalah jadi
jauh.

@roarwrecker Luar biasa, terima kasih telah berbagi! Artinya kami memiliki buffer waktu yang lebih besar hingga kami meluncurkan dukungan resmi ke NuGet :wink:

@roarwrecker terima kasih... ini bukan masalah di .netstandard 1.6. Saya bisa menginstal nuget, tetapi tidak pernah dikompilasi tanpa kesalahan

Hai Teman-teman, tidak yakin seberapa jauh pekerjaan .NetCore, tetapi apakah mungkin untuk mendapatkan versi alfa di NuGet?

@selmendorfFrontline Menyalin balasan dari sini :

Menerbitkan versi pra-rilis ke NuGet adalah pertanyaan yang sedikit menyakitkan bagi saya. Sementara kami mulai mendukung .NET Core untuk sebagian besar proyek , kami memiliki rencana untuk mengubah namespace default . Ini akan menjadi perubahan besar bagi klien kami dan semua kode klien akan berhenti untuk dikompilasi. Inilah titik ketika kebingungan muncul:

• jika kita melepaskan alpha dengan namespace yang ada dan mengubah namespace di antara alpha dan RTM, itu akan membingungkan klien kita karena mereka sudah melihat v4 dengan namespace yang ada. Saya ingin klien kami merasa bahwa v4 selalu dirilis dengan namespace baru karena model tata kelola diubah.
• jika kita merilis alpha dengan namespace yang diubah, kita tidak akan dapat menggabungkan master ke v4 tanpa kesulitan lagi. Saat ini kami berkomitmen untuk kedua cabang, itu sebabnya saya ingin menunda perubahan namespace sampai akhir. Poin lainnya adalah bahwa dokumentasi kami saat ini belum siap, jadi orang mungkin tidak mengerti mengapa semua impor namespace tidak valid dan mereka hanya perlu menjalankan penggantian teks. Itu akan membuat mereka menakutkan dan pengalaman tidak akan semulus yang saya inginkan.

Cara terbaik untuk mengatasi situasi ini adalah dengan tidak melepaskan alpha dan melepaskan RTM saja. Sayangnya, saya tidak dapat memberi Anda ETA yang tepat karena tergantung pada kapasitas saya (saya mengerjakan proyek ini di waktu luang saya) dan ketersediaan kontributor lain (PR saya harus ditinjau ). Di kepala saya, saya membayangkan rilis dalam satu atau dua bulan dan berharap itu akan terjadi dalam kisaran ini. Proyek ini mati selama sekitar 9 bulan karena perubahan model tata kelola - itulah alasan utama penundaan dukungan tersebut.

Silakan gunakan paket dari umpan pratinjau sementara itu. Anda dapat menyetel Nuget.config seperti yang disebutkan di atas, jadi ini akan menjadi masalah.

Saya akan menutup masalah ini setelah #857 akhirnya digabungkan. Tabel Kompatibilitas .NET terakhir kami adalah sebagai berikut:

| Produk | .NET Framework | .NET Standar |
| ------------------ | ------------------------ | ------------------------ |
| Perbaikan Otomatis | :heavy_check_mark: 4.5.2 | :tanda_centang_berat: 1,5 |
| AutoFixture.xUnit | :heavy_check_mark: 4.5.2 | :tanda_minus_berat: |
| AutoFixture.xUnit2 | :heavy_check_mark: 4.5.2 | :tanda_centang_berat: 1,5 |
| AutoFixture.NUnit2 | :heavy_check_mark: 4.5.2 | :tanda_minus_berat: |
| AutoFixture.NUnit3 | :heavy_check_mark: 4.5.2 | :tanda_centang_berat: 1,5 |
| AutoFakeItEasy | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 1.6 |
| AutoFoq | :heavy_check_mark: 4.5.2 | :tanda_minus_berat: |
| AutoMoq | :heavy_check_mark: 4.5.2 | :tanda_centang_berat: 1,5 |
| AutoNSSubstitute | :heavy_check_mark: 4.5.2 | :tanda_centang_berat: 1,5 |
| AutoRhinoMock | :heavy_check_mark: 4.5.2 | :tanda_minus_berat: |
| Idiom | :heavy_check_mark: 4.5.2 | :heavy_check_mark: 2.0 |
| Idiom.FsCheck | :heavy_check_mark: 4.5.2 | :tanda_minus_berat: |
| Perbandingan Semantik | :heavy_check_mark: 4.5.2 | :tanda_centang_berat: 1,5 |

Semua pustaka yang tidak didukung kecuali Idioms.FsCheck tidak dapat diperbarui karena dependensinya tidak mendukung .Net Standard dan kecil kemungkinannya (kebanyakan sudah usang). Saya telah mencoba mem-port Idioms.FsCheck untuk mendukung .NET 452 dan .NET Standard 2.0 (karena secara teknis memungkinkan), namun tidak dapat membuatnya berfungsi. Tampaknya F# SDK masih cukup kasar dan kami harus menunggu rilis baru. Kompilasi dan pemuatan proyek gagal setelah saya mendefinisikan node TargetFrameworks .

Kecuali ada yang punya visi lain, saya akan mengikuti rencana ini Saya juga merasakan seberapa dekat kita dengan rilis dan seberapa jauh di belakang 😊

Pergi pergi pergi!

Saya telah mencoba mem-port Idioms.FsCheck untuk mendukung .NET 452 dan .NET Standard 2.0

Sudahkah Anda mencoba beralih ke versi F# yang lebih baru? IIRC, ada di F# 3.1 dan ini mungkin masalahnya.

Kerja bagus @zvirja. Apakah Anda pikir kami bisa mengeluarkan v4? Semakin dekat, semakin saya merasa senang :)

Saya berharap saya bisa menawarkan Anda bir :)

Sudahkah Anda mencoba beralih ke versi F# yang lebih baru? IIRC, ada di F# 3.1 dan ini mungkin masalahnya.

@moodmosaic Yap. Jika Anda memeriksa FsCheck 2.9.0 Anda akan menemukan bahwa itu tergantung pada FSharp.Core (>= 4.1.17) , oleh karena itu saya tidak punya pilihan lain Masalahnya lebih pada SDK. Jika saya mulai menargetkan kedua kerangka kerja secara bersamaan, saya tidak dapat memuat solusi di VS
Proyek:

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

Mencoba membuka di VS:

Semuanya baik-baik saja dengan proyek - masalahnya ada di F# SDK. Itu sebabnya saya ingin menunda dukungan .NET Core oleh FsCheck hingga waktu yang lebih baik.

@Kralizek Silakan lihat balasan beberapa jawaban di atas .

Baru saja diperiksa di VS 2017.4 dan masih tidak dapat menargetkan beberapa kerangka kerja untuk proyek F#. Oleh karena itu, saya menutup masalah ini untuk saat ini karena kami mendukung .NET Core untuk semua proyek lainnya.

JFYI: Saya merilis v4 rc1 ke NuGet, sehingga Anda dapat mengkonsumsi dan menguji tanpa perlu bermain dengan feed kustom.