Autofixture: دعم CoreCLR

ليس بعد على الأقل. ما هو DNX؟

Haha .. إنه إطار عمل asp.net متعدد المنصات الجديد. https://github.com/aspnet/DNX

وقت التشغيل هو "dnx451" بدلاً من "net451" ، إلخ.

ماذا يعني "دعم" في هذا السياق؟ هل تقول أنه من المستحيل اختبار ASP.NET 5 من مكتبة اختبار تعتمد على مكتبة .NET 4؟

يعمل ASPNET 5 على منصات متعددة. نحن نكتب ASPNET 5 فقط على النظام الأساسي dnx في الوقت الحالي ، لذا فهي مجموعة مختلفة من مكتبات وقت التشغيل. لم يتم تجميع الكود الخاص بنا حاليًا لـ "net451" ، لذلك تستهدف المكتبات بشكل فعال الأنظمة الأساسية غير المتوافقة

تعمل اختباراتي على ما يرام مع هذا المشروع. 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"
}

}

مثير للاهتمام. سأضطر إلى تنبيه الرجل الذي يعمل على هذا لمعرفة الفرق.
هل فعلت أي شيء خاص لجعله يعمل؟

لا حقا لا. عملت IIRC Autofixture دائمًا مع aspnet 5 ولكن في الماضي واجهت مشكلة مع امتداد xUnit. الآن بعد أن خرج دعم xUnit 2 للتركيز البؤري التلقائي وتشغيل DNX & xUnit معًا بشكل جيد ، فهو يعمل فقط.

يبدو أن الفكرة هنا هي حقًا "دعم CoreCLR" ، وليس DNX. أي شيء يعمل مع .NET Framework 4.5 سيعمل مع 4.5 على DNX. من المحتمل أن تتطلب CoreCLR بعض الجهد لدعمها ، لكن ليس لدي أي فكرة عن مقدار ذلك. أفضل طريقة لمعرفة ذلك هي محاولة بنائه لـ CoreCLR ومعرفة ما يكسر.

نعم ، كان يجب أن أكون واضحًا. قصدت CoreCLR ، وليس DNX فقط.

من مجرد البحث في coreclr repo ، من الصعب بالنسبة لي الحصول على حالة المشروع. هل هو في المعاينة؟ بيتا؟ صدر؟

دون تجربته على الإطلاق ، إذا كان CoreCLR يشبه مكتبات الفئات المحمولة من حيث أن الميزات المدعومة هي تقاطع بين الميزات المتاحة على أنظمة أساسية مختلفة ، فمن غير المحتمل تمامًا أنه سيكون من الممكن تعديل AutoFixture للتشغيل على CoreCLR دون كسر التغييرات.

في الآونة الأخيرة ، كان moodmosaic لطيفًا جدًا لإجراء التحليل لـ AtomEventStore (مشروع أصغر بكثير من AutoFixture) ، وهنا كانت النتيجة أن إصدار PCL كان غير قابل للتنفيذ .

بدون إلقاء نظرة على مصادر AutoFixture على الإطلاق ، أنا أتفق مع تقييمك: من المرجح حدوث تغييرات. ستكون توجيهات #if DNX_* -style ضرورية إذا كان الدعم في الخطة.

يعد CoreCLR ، إلى حد ما ، قيد التشغيل منذ Windows Phone 8.

سوف يتم إطلاق ASP.NET 5 في RC في نوفمبر ، و CoreCLR لنظامي Linux و Mac سيكون أيضًا RC في نوفمبر 2015. جنبًا إلى جنب مع CoreFX. الإصدار 1.0 لكل شيء مخطط له في الربع الأول من 2016.

سأفاجئني كثيرًا إذا كان من الممكن إضافة دعم لـ CoreCLR دون إدخال تغييرات عاجلة ، لذلك أضفت _4.0_ علامة فارقة إلى هذه المشكلة.

بدافع الفضول ، قمت بتشغيل API Portability Analyzer على مجموعة Ploeh.AutoFixture وحصلت على بعض النتائج المثيرة للاهتمام:

انتظر قبل أن تفتح الشمبانيا. لسوء الحظ ، تمثل نسبة 3٪ تقريبًا من الرموز غير المدعومة بعض الرموز الأساسية إلى حد ما:

| نوع الهدف | العضو المستهدف |
| --- | --- |
| System.Console | م: System.Console.get_Out |
| النظام. الخيوط. الخيوط | م: System.Threading.Thread.get_ManagedThreadId |
| النظام. الخيوط. الخيوط | م: 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 | م: 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.get_IsGenericTypeDefinition |
| نوع النظام | م: System.Type.get_IsEnum |
| نوع النظام | م: System.Type.get_BaseType |
| نوع النظام | م: System.Type.get_IsPrimitive |
| نوع النظام | م: System.Type.get_Assembly |
| نوع النظام | م: System.Type.get_IsGenericType |
| نوع النظام | م: System.Type.GetTypeCode (نوع النظام) |
| نوع النظام | م: System.Type.get_IsClass |
| نوع النظام | م: System.Type.get_IsValueType |
| نوع النظام | م: System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | م: System.Reflection.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | م: System.Reflection.PropertyInfo.GetSetMethod |
| System.Exception | M: System.Exception. # ctor (System.Runtime.Serialization.SerializationInfo ، System.Runtime.Serialization.StreamingContext) |
| System.Reflection.MethodBase | م: System.Reflection.MethodBase.GetCurrentMethod |

ومع ذلك ، هناك بعض الحلول:

• استبدل جميع الإشارات إلى الخصائص الموجودة في System.Type بالمراجع المقابلة في System.TypeInfo ، المتوفر من خلال طريقة الامتداد GetTypeInfo(Type) .
• قم بإزالة كافة الإشارات إلى System.SerializableAttribute .
• قم بإزالة كافة الإشارات إلى System.Runtime.Serialization.SerializationInfo (من المحتمل استخدامها فقط في _exception constructors_).
• قم بإزالة كافة الإشارات إلى System.Net.Mail.MailAddress .
• قم بإزالة كافة الإشارات إلى الخاصية System.Reflection.MemberInfo.ReflectedType واستخدم الكائن المنعكس للحصول على تعليق من نوعه.
• استبدل جميع المراجع إلى الخاصية System.Reflection.PropertyInfo.GetSetMethod بالخاصية System.Reflection.PropertyInfo.SetMethod بدلاً من ذلك.

هذه مجرد خطوة أولى وقد تتغير الأشياء مع استمرار تطوير CoreCLR. على الأقل حصلنا على فكرة عامة عما يتطلبه الأمر لجعل التصحيح التلقائي متوافقًا معه.

واو ، شكرًا لك ecampidoglio على إجراء هذا التحليل: +1:

بعض الأنواع غير المتوافقة (مثل MailAddress ) يمكننا الانتقال إلى مكتبة الوظائف الإضافية التي تعمل فقط في إطار العمل الكامل. كنت أفكر بالفعل في سحب بعض الميزات من مكتبة _Ploeh.AutoFixture_ للإصدار 4 .

فكرة استبدال PropertyInfo.GetSetMethod بـ PropertyInfo.SetMethod فكرة جيدة. AFAICT ، سيعمل فقط على .NET 4.5+ ، لكن هذا جيد ، لأن الفرع _v4_ موجود بالفعل على .NET 4.5.

لست متأكدًا مما إذا كانت التسمية "Jump In" مناسبة لهذه المشكلة. عادةً ما يتم استخدامه للإشارة إلى المشكلات الصغيرة والمعزولة ذات الحجم الصغير والتي تكون سهلة إلى حد ما وجديدة صديقة للمساهمين. يبدو أن هذه المشكلة تتطلب فهمًا جيدًا لجزء كبير من قاعدة الشفرة وتاريخها.

chaitanyagurrapu ، ربما أنت على حق.

السبب في أنني أضفت تسمية _jump in_ هو أنني أعتبر أن هذا العمل لا علاقة له إلى حد ما بتفاصيل AutoFixture. نعم: يجب اتخاذ قرارات بشأن كيفية معالجة حالات عدم التوافق المختلفة ، ولكن هناك أيضًا قدرًا كبيرًا من العمل لمعرفة كيفية عمل البنية التحتية للكوود / البنية بالكامل المتعلقة بـ CorCLR ، وهذا الجزء غير مرتبط تمامًا بالتركيب التلقائي.

في الوقت الحالي ، لا أمتلك هذه المهارات ، لذلك أرغب في الحصول على مساعدة في هذا الأمر. القرارات التي يجب اتخاذها فيما يتعلق بقضايا التوافق التي يمكننا مناقشتها هنا ، أو في قضايا Github المخصصة.

لقد بدأت العمل على هذا. أسئلة قادمة :)

يبدو هذا جيدًا بالنسبة لي: +1:

lbargaoanu يبدو جيدًا: +1: تذكر ، إذا كان ذلك ممكنًا ، صغيرًا .

أرغب في نقل MailAddressGenerator إلى مشروع مختلف يستهدف الإطار الكامل في فرع v4 ، حتى أتمكن من إنشاء AutoFixture لـ .NET Core. يمكنني أيضًا إعلان نوع عنصر نائب لـ .NET Core ، لكنني تجنبت التجميع الشرطي حتى الآن. وستكون هناك دائمًا أشياء مدعومة فقط في الإطار الكامل.

إنه في الأعمال . لكن في غضون ذلك ...

للرجوع اليها في المستقبل
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

منشور لطيف! هل يغطي أيضًا المكتبات؟ (لقد بحثت عن مكتبة ولكن لم أجد الكثير ...)

:) هذا كل شيء عن المكتبات ، لكن هذا المنشور وروابطه يجب أن يكونا كافيين.

أرغب في رؤية AutoFixture يعمل على CoreCLR أيضًا ، وعلى استعداد للمساعدة عند الحاجة. بالنظر إلى آخر علاقات عامة لـ Lucian Bargaoanu (# 511 ، و # 513) ، يبدو أن هذه المشكلة قد أصبحت قديمة في بعض المناقشات التي لم يتم حلها.

أود الحصول على الكرة ، لكن لا أعرف ما هي الخطة العامة لذلك ، وكيفية التعامل مع بعض التفاصيل التي كانت تعيق المناقشات. لذلك قد يكون من المفيد الوصول إلى شيء من هذا القبيل ، قبل الدخول في كل التفاصيل.

بعض الأسئلة التي رأيتها تطفو في الجوار أو لدي:

• هل ينبغي تحويل AutoFixture إلى PCL أو استخدام شيء مثل المشاريع المشتركة؟
• ما هي المنصات المطلوبة أو المطلوبة بالتأكيد على المدى الطويل؟ (NET ، CoreCLR ، UWP؟)
• هل التجميعات المشروطة غير مرغوب فيها لمشروع مثل هذا؟

ploeh يمكنني أن lbargaoanu هل لديك ربما بعض المدخلات على هذا؟ شكرا!

أرى أنني نسيت الرد على هذا الموضوع ؛ الرجاء قبول اعتذاري: مسح:

نرحب بأي عمل يمكننا القيام به لإعداد قاعدة رمز AutoFixture لـ .NET Core ، طالما أنه لا يؤدي إلى تدهور قاعدة الكود أو إدخال تغييرات متقطعة.

لا تزال التغييرات المتقطعة ممكنة ، لكن سيتعين عليهم الذهاب إلى فرع _v4_.

على أي حال ، سأحتاج إلى تبرير جيد لأي تغيير يبدو غير مبرر كما هو. على الرغم من أنني لا أستطيع أن أقول إنني أتابع موقف NET Core عن كثب ، يبدو أنه لا يزال هناك الكثير من الضربات ، ولست حريصًا على إدخال تغييرات مضاربة طالما أن الهدف لا يزال يتحرك.

لن أتفاجأ إذا كان التجميع الشرطي ضروريًا في نهاية المطاف ، وأنا لست ضده طالما أننا نستطيع أن نحافظ عليه عقلانيًا. إذا كان لا يزال بإمكاني تشغيل البرنامج النصي للبناء لإنشاء كل ما يلزم لنشره ، فمن المحتمل أن يكون على ما يرام. يجب أن أعترف ، رغم ذلك ، أنه ليس لدي الكثير من الخبرة في هذا الأمر.

أنا أيضًا لا أعرف أي المنصات مطلوبة. بشكل أساسي ، إذا أرسل لنا أي شخص في المجتمع طلبات سحب تبدو قابلة للصيانة ، والتي تعمل على توسيع نطاق AutoFixture ، فسننظر في قبولها.

AFAICT ، سنحتاج إلى استهداف netstandard1.X وهي مجموعة من واجهات برمجة التطبيقات التي من شأنها أن تعمل على أي منصة تنفذها (بما في ذلك netcore عبر النظام الأساسي و net framework على Windows فقط).

راجع https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

بشكل عام ، تحتوي الأرقام الأعلى على واجهات برمجة تطبيقات أكثر ، لكن أنظمة أساسية مدعومة أقل. ربما ينبغي أن نبدأ (نتابع) هذه المناقشة من خلال فهم أي X يجب أن نستهدفه في netstandard1.X .

الفقرة الأولى من هذا المستند تخيفني قليلاً:

نحن نشارك الخطط الأولية لمستقبل بناء مكتبات فئة .NET.
- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

moodmosaic ، هذا يخيفني أيضًا ، لكن الشيء هو أن المفهوم العام لاختيار واجهات برمجة التطبيقات التي

على سبيل المثال ، إذا احتجنا إلى واجهات برمجة تطبيقات للانعكاس من أجل الإصلاح التلقائي ، فسيتم تقليل قائمة الأهداف التي قد نحصل عليها. إذا احتجنا إلى مجموعات متزامنة ، فهذا صحيح. هذه الأنظمة الأساسية موجودة بالفعل (net framework كامل ، Windows phone ، إلخ) ، لذلك أعتقد أنه ليس شيئًا يمكن تغييره إذا ناقشنا واجهات برمجة التطبيقات التي نحتاجها.

قد [أعد] بدء المحادثة ... (إخلاء المسؤولية: ما زلت أتعلم هذه الأشياء أيضًا)

أبدأ بأقل ( netstandard1.0 ) تم تنفيذه بالفعل على أكبر عدد من الأنظمة الأساسية ، وأبحث عن أسباب عدم تمكننا (أو عدم التزامنا) بهذه المنصة.

وفقًا لفهمي ، فإن مجموعة واجهات برمجة التطبيقات netstandard1.0 قديمة جدًا ومقيدة. لا تحتوي على أشياء مثل:

• System.Linq.Parallel (يبدأ من netstandard1.1 )
• System.Console (يبدأ من netstandard1.3 )
• System.Collections.Collections.Collections.Collections.Collections المتزامنة (تبدأ من netstandard1.1 )
• System.ComponentModel.Annotations (يبدأ من netstandard1.1 )
• System.Collections.Specialized (تبدأ من netstandard1.3 )

هذا يقودني إلى الاعتقاد بأنه ليس من العملي أن تستهدف AutoFixture netstandard1.0 .

أتساءل عما إذا كان انتظار المحلل الذي ذكره ecampidoglio هنا هو استراتيجية أفضل.

تحرير: هنا NET API Portability محلل أدوات الريبو وهنا موقع الويب http://dotnetstatus.azurewebsites.net

آسف للكثير من التعليقات غير المرغوب فيها ، سأتوقف الآن :)

لمعلوماتك ، قمت بتشغيل أحدث محلل قابلية النقل على Ploeh.AutoFixture.dll محلي الصنع من الإصدار 4 4a7d415 والملخص هو:

فيما يلي بعض التغييرات التي توصي بها حاليًا:

الإخراج الكامل هنا .

ploeh تتطلب العديد من مكونات Asp.Net Core المستخدمة على نطاق واسع netstandard1.3 على الأقل. تتضمن الأمثلة على ذلك EntityFrameworkCore (يستخدم 1.3) و Mvc (يستخدم 1.6).

إذا استخدم Autofixture أيًا من هذين الخطين كأساس ، أعتقد أنه سيكون في مكان جيد.

هل هناك أي جداول زمنية حول متى يكون دعم NET Core متاحًا؟

تمكنت من إنشاء بناء على .NET Core استنادًا إلى فرع v4. لم أحاول بناء مشاريع اختبارية بالرغم من ذلك. تحقق من هذا الفرع إذا كنت تريد إنشاء حزمة.

FWIW ، إليك المقارنة بين AutoFixture / AutoFixture v4 و uhaciogullari / AutoFixture net-core . إنها تبدو جيدة 👍

حسنًا ، الأمر ليس بهذه البساطة حقًا. يتسبب وجود project.json في حدوث خطأ في إنشاء مشاريع csproj منتظمة في الوقت الحالي. يمكننا ترحيل جميع المشاريع إلى تنسيق project.json لكني لست متأكدًا مما إذا كانت فكرة جيدة للمشاريع الأخرى. لم أقم بفحصها بالتفصيل ولكني أظن أنها مكونات إضافية لبعض أطر عمل الاختبار الأخرى. لا فكرة عما إذا كانوا يدعمون NET Core أيضًا.

شيء آخر هو أن Microsoft أعلنت أنها ستبتعد

توجد طريقة للبناء بدون أخطاء: # 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/

hoetz لا يزال بإمكانك تثبيت إصدار مجتمع vs2017.

هل هناك أي خطة للنظر في هذه القضية؟

من السيئ حقًا كتابة اختبارات للتجمعات القياسية لـ .NET بدون AitoFixture ...

مرحباً بالجميع ، هذا يتطلب من شخص ما من المجتمع التدخل والمساهمة. من الواضح أنه صعب الآن لأن مشكلات نموذج الحوكمة لم يتم حلها بعد (# 703). يحتاج شخص ما أيضًا إلى التدخل في هذه الجبهة أيضًا.

أنا ألعب مع المشكلة. في الوقت الحالي ، أركز فقط على Src \ AutoFixture.sln.

استراتيجيتي هي تحويل Src \ AutoFixture \ AutoFixture.csproj إلى تنسيق المشروع الجديد (VS 2017) بحيث يمكنه دعم كلاً من .NET Framework و .NET Standard.

قمت بتشغيل اختبار قابلية النقل لـ .NET ويجب أن يكون الهدف الأفضل هو .NET Standard 1.5 (انظر الملف المرفق).

بادئ ذي بدء ، لن أقوم بتحويل مشاريع الاختبار ، على الرغم من أنني أفترض أننا قد نرغب في إجراء الاختبار أيضًا في وقت تشغيل .NET Core في المستقبل.

AutoFixtureNetPortabilityTest.zip

مرحبًا Kralizek - لمعلوماتك فقط - لقد نجحت مع netstandard1.3 في # 712

Kralizek خطئي ، يبدو أنني بدأت التخطيط لـ netstandard1.3 ولكن انتهى بي الأمر بـ netstandard1.5

اوشكت على الوصول. جميع الاختبارات خضراء في .NET Framework. البناء كله باللون الأحمر في .NET Standard. :د

لقد قابلت هذه الفئات من المشاكل فقط:

لا حاجة للمولد
حالة واحدة فقط ، MailAddressGenerator ، لأن System.Net.Mail.MailAddress غير متوفر في .NET Standard. الحل: تمت "إزالة" الملف بالكامل بواسطة #if NET40 ... #endif

التسلسل
لا توجد SerializableAttribute و SerializationInfo و StreamingContext في .NET Standard. أيضًا ، لا يحتوي Exception على المُنشئ الذي يأخذ هذين النوعين. باستخدام توجيه المترجم ، قمت بإزالة السمة والمنشئ هذا من جميع الاستثناءات. إزالة السمة بشكل خاص ليست جميلة حقًا.

استخدام التفكير للحصول على معلومات حول النوع
في .NET Standard ، يكون Type أكثر فقرًا. يتم تفويض كل شيء إلى كائن TypeInfo الذي يحتوي على كافة الخصائص المستخدمة. المشكلة هي أن .NET Framework لا يزال يستخدم فئة النوع القديمة.
المحلول:
لقد أنشأت طريقة امتداد تعيد توجيه نفس كائن النوع 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 هل لاحظت أننا نعتزم استهداف> = net45 في الفرع v4 ؟

تضمين التغريدة وذلك بفضل لرؤساء متابعة! 👍

راجع للشغل ، اكتشفت أن System.Threading.Thread متاح كحزمة .

لقد فتح مستوى جديد تمامًا من أخطاء المترجم ... لطيف: P.

NET Standard 2.0 هل يجب أن تضيف الكثير من واجهة برمجة التطبيقات ، فربما تستحق الانتظار؟

لا ليس كذلك. NET Standard 2.0 في الربع الثالث من عام 2017. نحن ملتزمون بعيدًا عن دعم .NET Standard 1.5 ، فلماذا ننتظر الإصدار 2.0؟ لتوليد رسائل البريد في وقت التشغيل لن تدعمه أبدًا؟

أيضًا ، سيكون الإصدار 2.0 في الغالب عبارة عن شريحة من إطار العمل 4.6 مع طرح الكثير من NotSupportedException في كل مكان.

Kralizek عادل بما فيه الكفاية. أنا بالطبع أحب إصدار autofixter بشكل أسرع ، لذلك كان سؤالًا أكثر عمومية.

FWIW ، أنا المساهم الذي أضاف دعمًا لمولد عنوان البريد ، وعلى الرغم من أنه من الجيد أنه جعل AutoFixture يدعم ذلك خارج الصندوق ، فهو بأي حال من الأحوال جانبًا حيويًا من AutoFixture ويستحق الجهد المبذول من أجله انتظرها.

يجب أن يكون لوجود AutoFixture بأدنى مستوى ممكن من .NET Standard الأولوية القصوى ، IMHO. استمر في العمل الجيد ، وإذا كنت تبحث عن أي مساعدة ، أو دعم في اختباره ، فيمكنني بالتأكيد المشاركة.

Kralizek ، فإن

تعرض للعض بسبب الخطأ "Package AutoFixture 3.50.5 غير متوافق مع netcoreapp1.1 (.NETCoreApp ، الإصدار = v1.1)" اليوم عند البدء في إضافة اختبارات إلى عدد من مشاريع .NET Core.

أنا أطالب بنوع من الرد "حالة المزج التلقائي لـ .net core" الذي يعطي اتجاهًا لوقت توفر حزمة nuget المفيدة للغاية لهذا النظام الأساسي (و .net core 2.0 هو بالفعل rtm والإصدار المعلق ..) .

ما الذي يمنعها؟ (شكرا لك مقدما)

نحن نعمل حاليًا على ذلك ويمكنك تتبع التقدم في # 773. لاحظ أن هذه العلاقات العامة تتعلق بالمشروع AutoFixture نفسه. لدينا 9 مشاريع أخرى يجب ترحيلها ، ولكن يجب أن يتم ذلك فقط بعد أن ننتهي من العمل على هذا المشروع.

سيتم إصدار دعم NET Core كـ v4 ، يمكنك العثور على النطاق بالكامل هنا . أتوقع شهرين قبل أن يصبح كل شيء جاهزًا.

في غضون ذلك ، نعمل أيضًا على موجز Dev NuGet (# 762) ، لذا ستتمكن من المشاركة في اختبار المنتج المبكر 😉

zvirja شكرا على التحديث التفصيلي. أنا متأكد من أنه سيكون مفيدًا للمطورين الآخرين أيضًا. سأكون سعيدًا للمشاركة في اختبار المنتج المبكر.

zvirja فقط للتوضيح - الأسلوب الحالي (المؤقت) لكتابة اختبارات الوحدة مقابل تطبيقات / مكتبات .NET Core يستخدم AutoFixture في مشاريع اختبار على سبيل المثال .NET 4.7 وترحيل مشروع (مشاريع) الاختبار إلى NET Core في وقت لاحق؟

هل هذا هو الحل المقترح في الوقت الحالي؟ (طالما يُسمح للتطبيق الذي أكتبه أن يكون .NET Core بالكامل ، فإن كتابة الاختبارات في بيئة عادية .NET 4.7 ليست مشكلة كبيرة).

andersborum لم أفكر مطلقًا في الحل المؤقت. لست متأكدًا من أن جميع واجهة برمجة التطبيقات التي نستخدمها في الإصدار 3 (الحزم المنشورة على NuGet) متوافقة مع .Net Standard 2.0 (لاستخدام ميزة جديدة من .NET Standard).

أخبرنا إذا وجدت طريقة للجمع بين الإصدارين 3 و. نت كور ، حتى نتمكن من تقديم النصيحة للآخرين

فقط لإعلام الجميع - تم دمج .Net Standard support for AutoFixture PR (# 773) في الفرع v4 . يمكنك أن تستهلك الحزمة من خلاصتنا الخاصة .

ملاحظة ، تم ترحيل مكتبة AutoFixture فقط. مكتبات الغراء الأخرى ستتابع لاحقًا.

من الممكن نقل الإصدار 4 إلى nuget.org ، حتى الإصدار ألفا؟ تعذر العثور على أي شيء يمكن مقارنته بالتركيب التلقائي حتى الآن يدعم .netstandard.
هل تم تحديد تاريخ إصدار الإصدار 4 بالفعل؟

RomanKernSW ليس في الوقت الحالي - لم لتغيير مساحة الاسم ، لذلك أفضل القيام بذلك _قبل_ إصدار شيء علنيًا لأن ذلك سيكون بمثابة فاصل كبير بين الإصدارات. من ناحية أخرى ، أريد تغيير مساحة الاسم لاحقًا قدر الإمكان ، حيث إننا ندمج باستمرار master إلى v4 وسيكون من الصعب القيام بذلك بعد التغيير.

هل لديك أي مشاكل مع الخلاصة الخاصة؟ يمكنك إضافة الخلاصة عبر NuGet.config إذا كان ذلك مطلوبًا بشدة.

جلالة لا بد لي من التحقق مما إذا كان من الممكن استخدام nuget.config لاستعادة nuget (.Net Core 2 - معاينة المهمة في VSO). في الوقت الحالي ، لدينا موجز خاص واحد (VSO) مع nuget.org بدون أي ملفات nuget.config. تحتاج إلى وقت لاختبار هذا ...

يحتوي .Net Standard 2.0 على وضع توافق لـ .Net Framework NuGets.
لقد كتبت اختبارات .Net Core باستخدام AutoFixture 3.50.x ولا توجد مشاكل في ذلك
بعيدا.

roarwrecker رائع ، شكرًا للمشاركة! مما يعني أن لدينا وقتًا مؤقتًا أكبر حتى نطرح الدعم الرسمي لـ NuGet: غمزة:

roarwrecker شكرًا ... لم تكن هذه هي المشكلة في .netstandard 1.6. يمكنني تثبيت nuget ، لكنه لا يجمع بدون أخطاء

مرحبًا يا رفاق ، لست متأكدًا من مدى طول عمل .NetCore ، ولكن هل من الممكن الحصول على إصدار ألفا على NuGet؟

selmendorfFrontline نسخ الرد من هنا :

يعد نشر الإصدار التجريبي على NuGet سؤالًا مؤلمًا بعض الشيء بالنسبة لي. بينما بدأنا في دعم .NET Core لمعظم المشاريع ، لدينا خطة لتغيير مساحة الاسم الافتراضية . سيكون هذا تغييرًا هائلاً لعملائنا وسيتوقف تجميع جميع رموز العميل. هذه هي النقطة التي يظهر فيها الارتباك:

• إذا قمنا بإصدار alpha مع مساحة الاسم الحالية وقمنا بتغيير مساحة الاسم بين alpha و RTM ، فسوف يربك عملائنا لأنهم رأوا بالفعل v4 مع مساحة الاسم الحالية. أريد أن يشعر عملاؤنا أن الإصدار 4 تم إطلاقه دائمًا بمساحة اسم جديدة حيث تم تغيير نموذج الحوكمة.
• إذا أصدرنا alpha مع تغيير مساحة الاسم ، فلن نتمكن من دمج فرع master إلى v4 بدون ألم بعد الآن. نلتزم حاليًا بكلا الفرعين ، ولهذا السبب أود تأجيل تغيير مساحة الاسم حتى النهاية. نقطة أخرى هي أن وثائقنا ليست جاهزة حاليًا ، لذلك قد لا يفهم الأشخاص ببساطة سبب عدم صلاحية جميع عمليات استيراد مساحة الاسم وأنهم يحتاجون ببساطة إلى تشغيل استبدال النص. هذا سيجعلهم مخيفين ولن تكون التجربة سلسة كما أتمنى.

أفضل طريقة لحل هذا الموقف هي عدم تحرير alpha وإطلاق RTM فقط. لسوء الحظ ، لا يمكنني تزويدك بالوقت المتوقع للوصول الدقيق لأنه يعتمد على قدرتي (أنا أعمل في هذا المشروع في وقت فراغي) وتوافر المساهمين الآخرين (يجب مراجعة تقاريري الخاصة بي 😉). في رأسي أتخيل الإصدار في غضون شهر أو شهرين وآمل أن يحدث في هذا النطاق. توقف هذا المشروع لمدة 9 أشهر تقريبًا بسبب تغيير نموذج الحوكمة - وهذا هو السبب الرئيسي لمثل هذا التأخير في الدعم.

يرجى استخدام الحزمة من موجز المعاينة في الوقت نفسه. يمكنك ضبط Nuget.config كما هو مذكور أعلاه ، لذلك يجب أن تكون هذه مشكلة.

سأقوم بإغلاق هذه المشكلة بعد دمج # 857 أخيرًا. سيكون جدول التوافق مع .NET النهائي كما يلي:

| المنتج | NET Framework | NET Standard |
| ------------------ | ------------------------ | ------------------------ |
| الإصلاح التلقائي | : 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 |
| بديل تلقائي | : 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 |
| التعبيرات الاصطلاحية : 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 .

ما لم يكن لدى أي شخص رؤية أخرى ، سأتبع هذه الخطة 😃 أشعر أيضًا بمدى اقترابنا من الإصدار ومقدار التأخر

إذهب! إذهب! إذهب!

لقد حاولت نقل Idioms.FsCheck لدعم كل من .NET 452 و .NET Standard 2.0

هل حاولت التبديل إلى إصدار أحدث من F # على ذلك الإصدار؟ IIRC ، إنه موجود على F # 3.1 وقد يكون هذا هو الحال.

عمل عظيم zvirja. هل تعتقد أنه يمكننا إخراج v4؟ كلما اقتربنا ، شعرت بالحماس أكثر :)

أتمنى أن أعرض عليك بيرة :)

هل حاولت التبديل إلى إصدار أحدث من F # على ذلك الإصدار؟ IIRC ، إنه موجود على F # 3.1 وقد يكون هذا هو الحال.

تضمين التغريدة إذا قمت بالتحقق من 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. لهذا السبب أود تأجيل دعم NET Core بواسطة FsCheck إلى أفضل الأوقات.

Kralizek الرجاء مراجعة الرد بعض الإجابات أعلاه .

تحقق للتو في VS 2017.4 ولا يزال يتعذر عليك استهداف أطر عمل متعددة لمشروع F #. لذلك ، أقوم بإغلاق هذه المشكلة في الوقت الحالي لأننا ندعم .NET Core لجميع المشاريع الأخرى.

JFYI: لقد قمت بإصدار v4 rc1 إلى NuGet ، لذا يمكنك الاستهلاك والاختبار دون الحاجة إلى اللعب باستخدام موجز مخصص.