Autofixture: कोरसीएलआर के लिए समर्थन

अभी नहीं, कम से कम। डीएनएक्स क्या है?

हाहा .. यह नया क्रॉस-प्लेटफ़ॉर्म एएसपीनेट ढांचा है। https://github.com/aspnet/DNX

रनटाइम "net451" आदि के बजाय "dnx451" है।

इस संदर्भ में "समर्थन" का क्या अर्थ है? क्या आप कह रहे हैं कि .NET 4 पुस्तकालय पर निर्भरता के साथ परीक्षण पुस्तकालय से ASP.NET 5 का परीक्षण करना असंभव है?

ASPNET 5 कई प्लेटफॉर्म पर चलता है। हम अभी केवल dnx प्लेटफॉर्म पर ASPNET 5 लिख रहे हैं, इसलिए यह रनटाइम लाइब्रेरी का एक अलग सेट है। हमारा कोड वर्तमान में "net451" के लिए संकलित नहीं है, इसलिए पुस्तकालय असंगत प्लेटफार्मों को प्रभावी ढंग से लक्षित कर रहे हैं

मेरे परीक्षण इस प्रोजेक्ट के साथ ठीक चलते हैं। जेसन:

{
"निर्भरता": {

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

}

दिलचस्प। मुझे उस आदमी को बग करना होगा जो इस पर काम कर रहा है यह देखने के लिए कि क्या अंतर है।
क्या आपने इसे काम करने के लिए कुछ खास किया?

नहीं वास्तव में कोई नहीं। आईआईआरसी ऑटोफिक्स्चर हमेशा एस्पनेट 5 के साथ काम करता था लेकिन अतीत में मुझे एक्सयूनीट एक्सटेंशन में परेशानी थी। अब जबकि AF के लिए xUnit 2 समर्थन समाप्त हो गया है और DNX और xUnit अच्छी तरह से एक साथ खेलते हैं, यह बस काम करता है।

ऐसा लगता है कि यहां विचार वास्तव में "कोरसीएलआर के लिए समर्थन" है, डीएनएक्स नहीं। कुछ भी जो .NET Framework 4.5 के लिए काम करता है वह DNX पर 4.5 के लिए काम करेगा। CoreCLR को समर्थन के लिए कुछ प्रयासों की आवश्यकता होगी, लेकिन मुझे नहीं पता कि कितना। यह पता लगाने का सबसे अच्छा तरीका है कि इसे CoreCLR के लिए बनाने की कोशिश करें और देखें कि क्या टूटता है।

हाँ, मुझे स्पष्ट होना चाहिए था। मेरा मतलब कोरसीएलआर था, सिर्फ डीएनएक्स नहीं।

केवल coreclr रेपो में देखने से , मेरे लिए परियोजना की स्थिति को समझना मुश्किल है। क्या यह पूर्वावलोकन में है? बीटा? जारी किया गया?

इसे बिल्कुल भी आजमाए बिना, यदि CoreCLR पोर्टेबल क्लास लाइब्रेरी की तरह कुछ भी है जिसमें समर्थित सुविधाएँ विभिन्न प्लेटफार्मों पर उपलब्ध सुविधाओं का एक प्रतिच्छेदन हैं, तो यह बहुत कम संभावना है कि परिवर्तनों को तोड़े बिना CoreCLR पर चलने के लिए AutoFixture को फिर से निकालना संभव होगा।

हाल ही में, @moodmosaic AtomEventStore (ऑटोफिक्चर की तुलना में बहुत छोटी परियोजना) के लिए विश्लेषण करने के लिए बहुत दयालु था

AutoFixture स्रोतों पर बिल्कुल भी ध्यान दिए बिना, मैं आपके आकलन से सहमत हूं: महत्वपूर्ण परिवर्तन संभव हैं। #if DNX_* -शैली निर्देश आवश्यक होंगे यदि योजना में समर्थन है।

CoreCLR कमोबेश विंडोज फोन 8 के बाद से चल रहा है।

ASP.NET 5 नवंबर में RC होगा, Linux के लिए CoreCLR और नवंबर 2015 में Mac भी RC होगा। CoreFX के साथ। 1Q2016 के लिए नियोजित सभी चीज़ों के लिए रिलीज़ 1.0।

यह मुझे आश्चर्यजनक रूप से आश्चर्यचकित करेगा यदि कोरसीएलआर के लिए ब्रेकिंग परिवर्तन शुरू किए बिना समर्थन जोड़ना संभव था, इसलिए मैंने इस मुद्दे पर _4.0_ मील का पत्थर जोड़ा है।

जिज्ञासा से बाहर, मैं Ploeh.AutoFixture असेंबली पर एपीआई पोर्टेबिलिटी विश्लेषक चलाता हूं और कुछ दिलचस्प परिणाम प्राप्त करता हूं:

शैंपेन खोलने से पहले प्रतीक्षा करें। वह लगभग 3% असमर्थित प्रतीकों, दुर्भाग्य से, कुछ बल्कि मौलिक लोगों के लिए जिम्मेदार है:

| लक्ष्य प्रकार | लक्ष्य सदस्य |
| --- | --- |
| System.Console | एम:System.Console.get_Out |
| सिस्टम.थ्रेडिंग.थ्रेड | एम: सिस्टम। थ्रेडिंग। थ्रेड। get_ManagedThreadId |
| सिस्टम.थ्रेडिंग.थ्रेड | एम: सिस्टम। थ्रेडिंग। थ्रेड। 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 | टी: 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 |
| सिस्टम। प्रकार | M:System.Type.GetTypeCode(System.Type) |
| सिस्टम। प्रकार | एम:System.Type.get_IsClass |
| सिस्टम। प्रकार | एम:System.Type.get_IsValueType |
| सिस्टम। प्रकार | एम: System.Type.get_IsAbstract |
| System.Reflection.MemberInfo | एम: सिस्टम। प्रतिबिंब.MemberInfo.get_ReflectedType |
| System.Reflection.PropertyInfo | एम: System.Reflection.PropertyInfo.GetSetMethod |
| सिस्टम.अपवाद | 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 कंस्ट्रक्टरों में उपयोग किया जाता है)।
• System.Net.Mail.MailAddress सभी संदर्भ हटा दें।
• System.Reflection.MemberInfo.ReflectedType संपत्ति के सभी संदर्भ हटा दें और इसके प्रकार को पकड़ने के लिए परावर्तित वस्तु का उपयोग करें।
• सभी संदर्भों को बदलें System.Reflection.PropertyInfo.GetSetMethod के साथ संपत्ति System.Reflection.PropertyInfo.SetMethod संपत्ति बजाय।

यह केवल एक पहला पास है और चीजें बदल सकती हैं क्योंकि CoreCLR अभी भी विकसित किया जा रहा है। कम से कम हमें इस बात का सामान्य अंदाजा हो गया कि AutoFixture को इसके साथ संगत बनाने के लिए क्या करना होगा।

वाह, धन्यवाद, @ecampidoglio , इस विश्लेषण को करने के लिए: +1:

कुछ असंगत प्रकार (जैसे MailAddress ) हम एक ऐड-ऑन लाइब्रेरी में जा सकते हैं जो केवल पूर्ण ढांचे पर काम करती है। मेरे मन में पहले से ही संस्करण 4 के लिए _Ploeh.AutoFixture_ लाइब्रेरी से कुछ सुविधाओं को निकालने का विचार था ।

PropertyInfo.GetSetMethod को PropertyInfo.SetMethod से बदलने का विचार अच्छा है। AFAICT, यह केवल .NET 4.5+ पर काम करेगा, लेकिन यह ठीक है, क्योंकि _v4_ शाखा पहले से ही .NET 4.5 पर है।

सुनिश्चित नहीं है कि "जंप इन" लेबल इस मुद्दे के लिए उपयुक्त है या नहीं। आमतौर पर इसका उपयोग छोटे, अलग-थलग, काटने के आकार के मुद्दों को इंगित करने के लिए किया जाता है जो काफी आसान और नए योगदानकर्ता के अनुकूल होते हैं। ऐसा लगता है कि इस मुद्दे के लिए कोड बेस और इसके इतिहास के एक बड़े हिस्से की काफी अच्छी समझ की आवश्यकता होगी।

@chaitanyagurrapu , शायद आप सही कह रहे हैं।

मेरे द्वारा _jump in_ लेबल जोड़ने का कारण यह था कि मैं इस कार्य को AutoFixture विवरण से कुछ हद तक असंबंधित मानता हूँ। हां: विभिन्न असंगतताओं को कैसे दूर किया जाए, इस पर निर्णय लेने होंगे, लेकिन यह पता लगाने में भी बहुत काम है कि कोरसीएलआर से संबंधित संपूर्ण कोड/बिल्ड इंफ्रास्ट्रक्चर कैसे काम करता है, और वह हिस्सा ऑटोफिक्स्चर से पूरी तरह से असंबंधित है।

इस समय, मेरे पास ये कौशल नहीं हैं, इसलिए मुझे इसके लिए सहायता प्राप्त करना अच्छा लगेगा। संगतता मुद्दों के संबंध में जो निर्णय लेने की आवश्यकता है, हम यहां या समर्पित जीथब मुद्दों पर चर्चा कर सकते हैं।

मैंने इस पर काम करना शुरू कर

मुझे अच्छा लगता है: +1:

@lbargaoanu अच्छा लगता है: +1: याद रखें, यदि संभव हो तो इसे छोटा रखें ।

मैं MailAddressGenerator को एक अलग प्रोजेक्ट में स्थानांतरित करना चाहता हूं जो v4 शाखा में पूर्ण ढांचे को लक्षित करता है, इसलिए मैं .NET कोर के लिए ऑटोफिक्स्चर बना सकता हूं। मैं .NET कोर के लिए प्लेसहोल्डर प्रकार भी घोषित कर सकता था, लेकिन मैंने अब तक सशर्त संकलन से परहेज किया है। और हमेशा पूर्ण ढांचे में समर्थित चीजें होंगी।

यह काम में है । लेकिन इस बीच...

आगामी संदर्भ के लिए
https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

अच्छा लेख! क्या यह पुस्तकालयों को भी कवर करता है? (मैंने _library_ की खोज की लेकिन बहुत कुछ नहीं मिला...)

:) यह सब पुस्तकालयों के बारे में है, लेकिन यह पोस्ट और इसके लिंक पर्याप्त होने चाहिए।

मुझे AutoFixture को CoreCLR पर काम करते हुए देखना अच्छा लगेगा, और जहाँ ज़रूरत हो वहाँ मदद करने के लिए तैयार हूँ। लूसियन बरगाओनु (#511, और #513) के पिछले पीआर को देखते हुए, ऐसा लगता है कि यह मुद्दा कुछ अनसुलझी चर्चाओं में बासी हो गया है।

मैं गेंद लुढ़कना चाहता हूं, लेकिन यह नहीं जानता कि इसके लिए समग्र योजना क्या थी, और कुछ विवरणों से कैसे निपटें जो चर्चाओं को रोक रहे थे। तो सभी विवरणों में जाने से पहले, ऐसा कुछ करना उपयोगी हो सकता है।

कुछ प्रश्न जो मैंने इधर-उधर तैरते हुए देखे हैं, या जो मेरे पास स्वयं हैं:

• क्या ऑटोफिक्चर को पीसीएल में परिवर्तित किया जाना चाहिए, या साझा परियोजनाओं की तरह कुछ उपयोग करना चाहिए?
• किन प्लेटफार्मों की निश्चित रूप से जरूरत है, या लंबे समय के लिए वांछित हैं? (.NET, CoreCLR, UWP?)
• क्या इस तरह की परियोजना के लिए सशर्त संकलन अवांछित हैं?

@ploeh मैं छवि कर सकता हूं कि इन सभी सवालों का जवाब आपके द्वारा नहीं दिया जा सकता है, लेकिन हो सकता है कि मुख्य योगदानकर्ताओं के पास इस पर कुछ इनपुट हो। @lbargaoanu क्या आपके पास इस पर कुछ इनपुट हो सकता है? धन्यवाद!

मैं देख रहा हूँ कि मैं इस सूत्र का उत्तर देना भूल गया हूँ; कृपया मेरी क्षमायाचना स्वीकार करें: प्लावित:

.NET कोर के लिए ऑटोफिक्चर कोड बेस तैयार करने के लिए हम जो भी काम कर सकते हैं, उसका स्वागत है, जब तक कि यह कोड बेस को नीचा नहीं करता है या ब्रेकिंग परिवर्तन पेश नहीं करता है।

ब्रेकिंग परिवर्तन अभी भी संभव हैं, लेकिन उन्हें _v4_ शाखा में जाना होगा।

किसी भी मामले में, हालांकि, मुझे किसी भी ऐसे बदलाव के लिए अच्छे औचित्य की आवश्यकता होगी जो कि अनुचित लगता है। हालांकि मैं यह नहीं कह सकता कि मैं .NET कोर स्थिति का बारीकी से पालन कर रहा हूं, ऐसा लगता है कि अभी भी बहुत कुछ है, और जब तक लक्ष्य अभी भी आगे बढ़ रहा है, तब तक मैं सट्टा परिवर्तन पेश करने का इच्छुक नहीं हूं।

मुझे आश्चर्य नहीं होगा अगर सशर्त संकलन आवश्यक हो जाएगा, और जब तक हम इसे समझदार रख सकते हैं, तब तक मैं इसके खिलाफ नहीं हूं। अगर मैं अभी भी जो कुछ भी प्रकाशित करने की आवश्यकता है उसे बनाने के लिए बिल्ड स्क्रिप्ट चला सकता हूं, तो शायद यह ठीक रहेगा। हालाँकि, मुझे यह स्वीकार करना होगा कि मुझे इसका बहुत अधिक अनुभव नहीं है।

मुझे यह भी नहीं पता कि कौन से प्लेटफॉर्म चाहिए। अनिवार्य रूप से, यदि समुदाय में कोई हमें ऐसे पुल अनुरोध भेजता है जो अनुरक्षणीय दिखते हैं, और जो AutoFixture की पहुंच को बढ़ाते हैं, तो हम उन्हें लेने पर विचार करेंगे।

AFAICT, हमें netstandard1.X को लक्षित करने की आवश्यकता होगी जो कि एपीआई का सेट है जो किसी भी प्लेटफॉर्म पर चलेगा जो उन्हें लागू करता है (केवल विंडोज़ पर नेटकोर क्रॉस प्लेटफॉर्म और नेट फ्रेमवर्क सहित)।

देखें https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

सामान्य तौर पर, उच्च संख्या में अधिक एपीआई होते हैं, लेकिन कम समर्थित प्लेटफॉर्म होते हैं। हमें शायद इस चर्चा को शुरू करना चाहिए (जारी रखना) यह समझकर कि हमें किस एक्स को लक्षित करना चाहिए netstandard1.X ।

उस दस्तावेज़ का पहला पैराग्राफ मुझे थोड़ा डराता है:

हम .NET क्लास लाइब्रेरी बनाने के भविष्य के लिए शुरुआती योजनाएँ साझा कर रहे हैं।
-- https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

@moodmosaic यह मुझे भी डराता है, लेकिन बात यह है कि हम जिन एपीआई को लक्षित करेंगे, उन्हें चुनने की सामान्य अवधारणा अनिवार्य रूप से किसी भी तरह से आवश्यक होगी। नेटस्टैंडर्ड सिर्फ उन्हें एक प्रसिद्ध नाम और सहमत सबसेट देता है, और उनका वर्णन करने का एक आसान तरीका देता है। यह माना जा रहा है कि हम पहले स्थान पर पोर्टेबल होना चाहते थे।

उदाहरण के लिए, यदि हमें AutoFixture के लिए प्रतिबिंब API की आवश्यकता है, तो हमारे संभावित लक्ष्यों की सूची कम कर दी गई है। अगर हमें समवर्ती संग्रह की आवश्यकता है, तो वही सच है। वे प्लेटफॉर्म पहले से मौजूद हैं (नेट फ्रेमवर्क पूर्ण, विंडोज फोन, आदि), इसलिए मुझे लगता है कि यह ऐसा कुछ नहीं है जो बदल सकता है अगर हम चर्चा करते हैं कि हमें कौन सी एपीआई चाहिए।

मैं [पुनः] बातचीत शुरू कर सकता हूं... (अस्वीकरण: मैं अभी भी यह सामान भी सीख रहा हूं)

मैं सबसे कम ( netstandard1.0 ) से शुरू करता हूं जो पहले से ही सबसे बड़ी संख्या में प्लेटफॉर्म पर लागू किया गया है, और उन कारणों की तलाश करता है कि हम उस प्लेटफॉर्म के लिए प्रतिबद्ध क्यों नहीं (या नहीं करेंगे)।

मेरी समझ के अनुसार, एपीआई का 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 से शुरू होता है)

इससे मुझे लगता है कि ऑटोफिक्चर के लिए netstandard1.0 को लक्षित करना व्यावहारिक नहीं है।

मुझे आश्चर्य है कि क्या यहां @ecampidoglio द्वारा उल्लिखित विश्लेषक की प्रतीक्षा करना एक बेहतर रणनीति है।

संपादित करें: यहाँ .NET API पोर्टेबिलिटी विश्लेषक उपकरण रेपो है और यहाँ वेब साइट है http://dotnetstatus.azurewebsites.net

बहुत अधिक टिप्पणी स्पैम के लिए क्षमा करें, मैं अभी रुकूंगा :)

FYI करें मैंने v4 4a7d415 से स्थानीय रूप से निर्मित Ploeh.AutoFixture.dll पर नवीनतम पोर्टेबिलिटी विश्लेषक चलाया और सारांश है:

यहां कुछ बदलाव दिए गए हैं जिनकी वह वर्तमान में अनुशंसा करता है:

पूरा आउटपुट यहाँ है ।

@ploeh Asp.Net Core के कई व्यापक रूप से उपयोग किए जाने वाले कॉम्पोनेट्स को न्यूनतम netstandard1.3 आवश्यकता होती है। इसके उदाहरणों में EntityFrameworkCore (1.3 का उपयोग करता है) और Mvc (1.6 का उपयोग करता है) शामिल हैं।

यदि Autofixture इनमें से किसी एक को आधार रेखा के रूप में उपयोग करता है, तो मुझे लगता है कि यह एक अच्छी जगह पर होगा।

नेट कोर समर्थन कब उपलब्ध हो सकता है, इस पर कोई समयसीमा?

मैं v4 शाखा के आधार पर .NET कोर पर निर्माण करने में कामयाब रहा। मैंने हालांकि परीक्षण परियोजनाओं के निर्माण की कोशिश नहीं की। यदि आप एक पैकेज बनाना चाहते हैं तो इस शाखा को देखें।

FWIW, यहाँ AutoFixture/AutoFixture v4 और uhaciogullari/AutoFixture net-core के बीच तुलना है । यह अच्छा लग रहा है

वैसे यह वास्तव में इतना सीधा नहीं है। Project.json का अस्तित्व अभी नियमित csproj प्रोजेक्ट बनाने में त्रुटि का कारण बनता है। हम सभी परियोजनाओं को project.json प्रारूप में माइग्रेट कर सकते हैं लेकिन मुझे यकीन नहीं है कि यह अन्य परियोजनाओं के लिए एक अच्छा विचार है। मैंने उन्हें विस्तार से नहीं देखा है, लेकिन मुझे संदेह है कि वे कुछ अन्य परीक्षण ढांचे के लिए प्लगइन्स हैं। पता नहीं अगर वे .NET कोर का भी समर्थन करते हैं।

एक और बात यह है कि माइक्रोसॉफ्ट ने घोषणा की है कि वे जल्द ही project.json से दूर चले जाएंगे और वे वापस csproj पर चले जाएंगे। वे एक आसान प्रवास का वादा करते हैं लेकिन क्या आप इस अस्थायी प्रारूप का उपयोग करने के लिए अपना समय लेना चाहते हैं? यह सब आप पर निर्भर है। मैं अपनी वर्तमान शाखा से एक पैकेज को आगे बढ़ा सकता था लेकिन v4 काम प्रगति पर लगता है।

त्रुटियों के बिना निर्माण करने का एक तरीका है: #712

मैंने वास्तव में आपकी शाखा से निर्माण करने की कोशिश की लेकिन यह एक डीएल उत्पन्न नहीं करता है। यह शायद कुछ कॉन्फ़िगरेशन को याद कर रहा है, लेकिन प्रत्येक प्रोजेक्ट में एक अतिरिक्त फ़ोल्डर बनाना मुझे सौंदर्य की दृष्टि से पसंद नहीं आया।

क्या इस पर कोई अपडेट है?

मुझे लगता है कि जब तक .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 समुदाय संस्करण स्थापित कर सकते हैं।

क्या इस मुद्दे को देखने की कोई योजना है?

AitoFixture के बिना .NET मानक असेंबलियों के लिए परीक्षण लिखना वास्तव में बुरा लगता है...

हाय सब लोग, इसके लिए समुदाय से किसी न किसी को आगे आने और योगदान करने की आवश्यकता है। यह स्पष्ट रूप से अभी मुश्किल है क्योंकि शासन मॉडल के मुद्दों को अभी तक हल नहीं किया गया है (#703)। किसी को उस मोर्चे पर भी कदम बढ़ाने की जरूरत है।

मैं समस्या के साथ खेल रहा हूँ। अभी मैं केवल Src\AutoFixture.sln पर ध्यान केंद्रित कर रहा हूँ।

मेरी रणनीति Src\AutoFixture\AutoFixture.csproj को नए प्रोजेक्ट प्रारूप (VS 2017) में बदलने की है ताकि यह .NET Framework और .NET मानक दोनों का समर्थन कर सके।

मैंने .NET पोर्टेबिलिटी टेस्ट चलाया और सबसे अच्छा लक्ष्य .NET मानक 1.5 होना चाहिए (संलग्न फ़ाइल देखें)।

शुरू करने के लिए, मैं परीक्षण परियोजनाओं को परिवर्तित नहीं करूंगा, हालांकि मुझे लगता है कि हम भविष्य में .NET कोर रनटाइम में भी परीक्षण चलाना चाहेंगे।

AutoFixtureNetPortabilityTest.zip

अरे @Kralizek - बस FYI करें - मुझे #712 में netstandard1.3 साथ सफलता मिली

@Kralizek मेरी गलती, ऐसा लगता है कि मैंने netstandard1.3 लिए योजना बनाना शुरू कर दिया था लेकिन वास्तव में netstandard1.5 साथ समाप्त हुआ

वहाँ लगभग। .NET Framework में सभी परीक्षण हरे हैं। .NET मानक में बिल्ड पूरी तरह से लाल है। :डी

मैं केवल इन श्रेणियों की समस्याओं से मिला:

जनरेटर की जरूरत नहीं
केवल एक मामला, MailAddressGenerator , क्योंकि System.Net.Mail.MailAddress .NET मानक में उपलब्ध नहीं है। समाधान: #if NET40 ... #endif . द्वारा संपूर्ण फ़ाइल को "हटा" दिया गया है

क्रमबद्धता
SerializableAttribute, SerializationInfo और StreamingContext .NET मानक में मौजूद नहीं हैं। साथ ही, अपवाद में कंस्ट्रक्टर नहीं होता है जो उन दो प्रकारों को लेता है। कंपाइलर निर्देश का उपयोग करके मैंने सभी अपवादों से विशेषता और उस निर्माता को हटा दिया है। विशेष रूप से विशेषता को हटाना वास्तव में सुंदर नहीं है।

प्रकार के बारे में जानकारी प्राप्त करने के लिए परावर्तन का उपयोग
.NET मानक में Type बहुत खराब है। सब कुछ एक टाइपइन्फो ऑब्जेक्ट को सौंपा गया है जिसमें उपयोग की जाने वाली सभी गुण शामिल हैं। समस्या यह है कि .NET Framework अभी भी पुराने प्रकार वर्ग का उपयोग करता है।
समाधान:
मैंने एक एक्सटेंशन विधि बनाई है जो समान टाइप ऑब्जेक्ट public static Type GetTypeInfo(this Type type) => type; आगे बढ़ाती है और इस एक्सटेंशन विधि को केवल कंपाइलर निर्देश के माध्यम से .NET Framework में उपलब्ध कराती है। इस ट्रिक ने फाइलों को अछूता छोड़कर कई असंगतताओं को हल किया। नोट: विस्तार विधि को internal के रूप में चिह्नित किया गया है।

वर्तमान विधानसभा प्राप्त करने के लिए प्रतिबिंब का उपयोग
ठीक है, यह एक कठिन था क्योंकि मैं परियोजना लेआउट को पूरी तरह से नहीं जानता। मैंने क्लास पदानुक्रम को तुरंत जांचने के लिए रीशेर्पर का उपयोग किया लेकिन आप लोगों को दोबारा जांच करनी चाहिए।
फ़ाइल 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 पैकेज के रूप में उपलब्ध है।

इसने कंपाइलर त्रुटियों का एक नया स्तर खोल दिया ... अच्छा: पी

.NET मानक 2.0 बहुत अधिक एपीआई वापस जोड़ना चाहिए, शायद यह प्रतीक्षा करने लायक है?

नहीं यह नहीं। .NET मानक 2.0 Q3 2017 में आने वाला है। हम .NET मानक 1.5 का समर्थन करने से एक प्रतिबद्ध दूर हैं, हमें 2.0 की प्रतीक्षा क्यों करनी चाहिए? रनटाइम पर मेल संदेश जनरेट करने के लिए कभी भी इसका समर्थन नहीं करेगा?

इसके अलावा, 2.0 ज्यादातर फ्रेमवर्क 4.6 का एक शिम होने जा रहा है, जिसमें बहुत सारे NotSupportedException को चारों ओर फेंका जा रहा है।

@Kralizek मेला काफी। मैं निश्चित रूप से ऑटोफिक्स्टर को तेजी से रिलीज करना पसंद करूंगा, इसलिए एक और सामान्य प्रश्न था।

एफडब्ल्यूआईडब्ल्यू, मैं योगदानकर्ता हूं जिसने मेल एड्रेस जेनरेटर के लिए समर्थन जोड़ा है, और हालांकि, यह अच्छा है कि इसने ऑटोफिक्चर को बॉक्स के बाहर के लिए समर्थन दिया है, यह किसी भी तरह से ऑटोफिक्चर का एक महत्वपूर्ण पहलू नहीं है और प्रयास के लायक है इसके लिए प्रतीक्षा कीजिए।

न्यूनतम संभव .NET मानक पर AutoFixture होने पर सबसे अधिक प्राथमिकता होनी चाहिए, IMHO। अच्छा काम जारी रखें, और अगर आप किसी मदद की तलाश में हैं, या इसका परीक्षण करने में समर्थन चाहते हैं, तो मैं निश्चित रूप से इसमें शामिल हो सकता हूं।

@Kralizek TypeInfo सामान भी .NET 4.5 में मौजूद है, इसलिए इससे मदद मिलेगी।

कई .NET कोर प्रोजेक्ट्स में परीक्षण जोड़ना शुरू करते समय त्रुटि "पैकेज ऑटोफिक्चर 3.50.5 netcoreapp1.1 (.NETCoreApp,Version=v1.1) के साथ संगत नहीं है" द्वारा काट लिया गया था।

मैं ".नेट कोर के लिए ऑटोफिक्स्चर की स्थिति" के लिए पूछ रहा हूं, जो इस प्लेटफॉर्म के लिए बेहद उपयोगी नगेट पैकेज उपलब्ध होने के लिए एक दिशा देता है (और .net कोर 2.0 पहले से ही आरटीएम और लंबित रिलीज है ..) .

इसे वापस क्या रोक रहा है? (अग्रिम में धन्यवाद)

हम वर्तमान में उस पर काम कर रहे हैं और आप #773 में प्रगति को ट्रैक कर सकते हैं। ध्यान दें, यह जनसंपर्क AutoFixture परियोजना के बारे में ही है। हमारे पास 9 और परियोजनाएं हैं जिन्हें माइग्रेट किया जाना चाहिए, लेकिन इस पर काम खत्म करने के बाद ही ऐसा किया जाना चाहिए।

.NET कोर समर्थन v4 के रूप में जारी किया जाएगा, आप यहां पूरा दायरा पा सकते हैं। मुझे सब कुछ तैयार होने से कुछ महीने पहले की उम्मीद है।

इस बीच, हम देव नुगेट फ़ीड (#762) पर भी काम कर रहे हैं, ताकि आप शुरुआती उत्पाद परीक्षण में भाग ले सकें

@zvirja विस्तृत अपडेट के लिए धन्यवाद। मुझे यकीन है कि यह अन्य डेवलपर्स के लिए भी काम आएगा। मुझे शुरुआती उत्पाद परीक्षण में भाग लेने में खुशी होगी।

@zvirja तो बस स्पष्ट करने के लिए - .NET कोर अनुप्रयोगों/पुस्तकालयों के खिलाफ यूनिट परीक्षण लिखने के लिए वर्तमान (अस्थायी) दृष्टिकोण AutoFixture का उपयोग कर रहा है उदाहरण के लिए .NET 4.7 परीक्षण परियोजनाओं और परीक्षण परियोजना को माइग्रेट करें। बाद में .NET कोर के लिए?

क्या यह फिलहाल के लिए सुझाया गया समाधान है? (जब तक मैं जो ऐप लिख रहा हूं उसे पूरी तरह से .NET कोर होने की अनुमति है, यह वास्तव में एक नियमित .NET 4.7 वातावरण में परीक्षण लिखने के लिए एक बड़ा मुद्दा नहीं है)।

@andersborum मैंने अस्थायी कामकाज के बारे में कभी नहीं सोचा। मुझे यकीन नहीं है कि v3 में हमारे द्वारा उपयोग किए जाने वाले सभी API (पैकेज, NuGet पर प्रकाशित) .NET मानक 2.0 के अनुरूप हैं (.NET मानक की एक नई सुविधा का उपयोग करने के लिए)।

हमें बताएं कि क्या आपको v3 और .Net Core दोनों को संयोजित करने का कोई तरीका मिला है, ताकि हम अन्य लोगों को सलाह दे सकें

बस सभी को सूचित करने के लिए - AutoFixture PR (#773) के लिए .Net मानक समर्थन को v4 शाखा में मिला दिया गया है। आप हमारे निजी फ़ीड से पैकेज का उपभोग कर सकते हैं।

सूचना, केवल ऑटोफिक्चर लाइब्रेरी को माइग्रेट किया गया है। अन्य गोंद पुस्तकालय बाद में पालन करेंगे।

v4 को nuget.org पर ले जाना संभव है, यहाँ तक कि अल्फ़ा संस्करण भी? अब तक .netstandard को सपोर्ट करने वाले ऑटोफिक्स्चर से तुलनीय कुछ भी नहीं मिला।
क्या v4 की रिलीज़ की तारीख पहले ही तय कर ली गई है?

@RomanKernSW इस समय नहीं - हमने अभी तक आधी परियोजनाओं को भी माइग्रेट नहीं किया है (जैसे xUnit, NUnit, NSubstitute समर्थन), इसलिए यह बहुत जल्दी है। इसके अलावा, हमारे पास नाम स्थान बदलने की योजना है, इसलिए मैं यह करना पसंद करूंगा कि _before_ हम सार्वजनिक रूप से कुछ जारी करें क्योंकि यह रिलीज के बीच एक बड़ा ब्रेक होगा। दूसरी ओर, मैं नाम स्थान को यथासंभव बाद में बदलना चाहता हूं, क्योंकि हम लगातार master को v4 में मिलाते हैं और परिवर्तन के बाद ऐसा करना एक नरक होगा।

क्या आपको निजी फ़ीड से कोई समस्या है? आप NuGet.config माध्यम से फ़ीड जोड़ सकते हैं यदि इसकी अत्यधिक आवश्यकता है।

एचएम मुझे यह जांचना होगा कि क्या nuget.config का उपयोग nuget पुनर्स्थापित करने के लिए संभव है (.Net Core 2 - VSO में पूर्वावलोकन कार्य)। अभी, हमारे पास nuget.org के साथ बिना किसी nuget.config फ़ाइल के एक निजी फ़ीड (VSO) है। इसका परीक्षण करने के लिए समय चाहिए ...

.Net Standard 2.0 में .Net Framework NuGets के लिए संगतता मोड है।
मैंने AutoFixture 3.50.x के साथ .Net Core परीक्षण लिखे हैं और कोई समस्या नहीं है
दूर।

@roarwrecker बहुत बढ़िया, साझा करने के लिए धन्यवाद! मतलब जब तक हम NuGet को आधिकारिक समर्थन नहीं देते: पलक:

@roarwrecker धन्यवाद ... यह .netstandard 1.6 पर मुद्दा नहीं था। मैं नगेट स्थापित कर सकता था, लेकिन यह त्रुटि के बिना कभी भी संकलित नहीं होता है

अरे दोस्तों, यह सुनिश्चित नहीं है कि .NetCore काम कितना आगे है, लेकिन क्या NuGet पर अल्फा संस्करण प्राप्त करना संभव है?

@selmendorfFrontline यहाँ से उत्तर की प्रतिलिपि बना रहा

प्री-रिलीज़ संस्करण को NuGet पर प्रकाशित करना मेरे लिए थोड़ा कष्टदायक प्रश्न है। जबकि हमने अधिकांश परियोजनाओं के लिए .NET कोर का समर्थन करना शुरू कर दिया है, हमारे पास डिफ़ॉल्ट नाम स्थान को

• यदि हम मौजूदा नाम स्थान के साथ alpha करते हैं और alpha और RTM के बीच नाम स्थान बदलते हैं, तो यह हमारे ग्राहकों को भ्रमित करेगा क्योंकि उन्होंने पहले से ही मौजूदा नाम स्थान के साथ v4 देखा है। मैं चाहता हूं कि हमारे ग्राहक यह महसूस करें कि शासन मॉडल बदलते ही v4 हमेशा एक नए नाम स्थान के साथ जारी किया गया था।
• अगर हम बदले हुए नाम स्थान के साथ alpha करते हैं, तो हम master को v4 बिना किसी दर्द के मर्ज करने में असमर्थ होंगे। वर्तमान में हम दोनों शाखाओं के लिए प्रतिबद्ध हैं, इसलिए मैं नाम स्थान परिवर्तन को अंत तक स्थगित करना चाहता हूं। एक अन्य बिंदु यह है कि हमारा दस्तावेज़ीकरण वर्तमान में तैयार नहीं है, इसलिए लोगों को यह समझ में नहीं आ रहा है कि सभी नामस्थान आयात अमान्य क्यों हैं और उन्हें बस एक टेक्स्ट प्रतिस्थापन चलाने की आवश्यकता है। यह उन्हें डरावना बना देगा और अनुभव उतना सहज नहीं होगा जितना मैं चाहता हूं।

इस स्थिति को हल करने का सबसे अच्छा तरीका यह होगा कि alpha जारी न किया जाए और केवल RTM जारी किया जाए। दुर्भाग्य से, मैं आपको सटीक ईटीए प्रदान नहीं कर सकता क्योंकि यह मेरी क्षमता पर निर्भर करता है (मैं अपने खाली समय में इस परियोजना पर काम कर रहा हूं) और अन्य योगदानकर्ताओं की उपलब्धता (मेरे पीआर की समीक्षा की जानी चाहिए 😉)। मेरे दिमाग में मैं एक या दो महीने में रिलीज की कल्पना करता हूं और आशा करता हूं कि यह इस सीमा के भीतर होगा। शासन मॉडल परिवर्तन के कारण यह परियोजना लगभग 9 महीने से बंद थी - यही समर्थन में इतनी देरी का मुख्य कारण है।

कृपया इस बीच पूर्वावलोकन फ़ीड से पैकेज का उपयोग करें। जैसा कि ऊपर बताया गया है, आप अपने Nuget.config को ट्यून कर सकते हैं, इसलिए यह एक मुद्दा होना चाहिए।

#857 के अंत में विलय के बाद मैं इस मुद्दे को बंद करने जा रहा हूं। हमारी अंतिम .NET संगतता तालिका निम्नलिखित होगी:

| उत्पाद | .NET फ्रेमवर्क | .NET मानक |
| ------------------ | ------------------------ | ------------------------ |
| ऑटोफिक्चर | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.5 |
| AutoFixture.xUnit | :भारी_चेक_चिह्न: 4.5.2 | :भारी_माइनस_साइन: |
| AutoFixture.xUnit2 | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.5 |
| AutoFixture.NUnit2 | :भारी_चेक_चिह्न: 4.5.2 | :भारी_माइनस_साइन: |
| AutoFixture.NUnit3 | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.5 |
| AutoFakeItEasy | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.6 |
| ऑटोफोक | :भारी_चेक_चिह्न: 4.5.2 | :भारी_माइनस_साइन: |
| ऑटोमोक | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.5 |
| AutoNSubstitute | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.5 |
| AutoRhinoMock | :भारी_चेक_चिह्न: 4.5.2 | :भारी_माइनस_साइन: |
| मुहावरे | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 2.0 |
| मुहावरे.Fsचेक | :भारी_चेक_चिह्न: 4.5.2 | :भारी_माइनस_साइन: |
| अर्थपूर्ण तुलना | :भारी_चेक_चिह्न: 4.5.2 | :भारी_चेक_चिह्न: 1.5 |

Idioms.FsCheck को छोड़कर सभी असमर्थित पुस्तकालयों को अद्यतन नहीं किया जा सकता क्योंकि उनकी निर्भरताएं .Net Standard का समर्थन नहीं करती हैं और यह संभावना नहीं है कि वे (उनमें से अधिकांश अप्रचलित हैं)। मैंने Idioms.FsCheck को .NET 452 और .NET Standard 2.0 दोनों का समर्थन करने के लिए पोर्ट करने का प्रयास किया है (क्योंकि यह तकनीकी रूप से संभव है), हालांकि इसे काम करने में सक्षम नहीं था। ऐसा लगता है कि एफ # एसडीके अभी भी काफी मोटा है और हमें नई रिलीज की प्रतीक्षा करने की जरूरत है। TargetFrameworks नोड को परिभाषित करने के बाद संकलन और प्रोजेक्ट लोड बस विफल हो जाता है।

जब तक किसी के पास दूसरा विजन न हो, मैं इस योजना का पालन करने जा रहा हूं मुझे भी लगता है कि हम रिलीज के कितने करीब हैं और कितना पीछे है

जाओ जाओं जाओ!

मैंने Idioms.FsCheck को .NET 452 और .NET Standard 2.0 दोनों का समर्थन करने के लिए पोर्ट करने का प्रयास किया है

क्या आपने उस पर एक नए एफ # संस्करण में स्विच करने का प्रयास किया है? आईआईआरसी, यह एफ # 3.1 पर है और यह मामला हो सकता है।

बढ़िया काम @zvirja। क्या आपको लगता है कि हम v4 आउट कर सकते हैं? हम जितने करीब आते हैं, उतना ही उत्साहित महसूस करते हैं :)

काश मैं तुम्हें एक बियर की पेशकश कर सकता :)

क्या आपने उस पर एक नए एफ # संस्करण में स्विच करने का प्रयास किया है? आईआईआरसी, यह एफ # 3.1 पर है और यह मामला हो सकता है।

@moodmosaic हाँ। यदि आप FsCheck 2.9.0 की जांच करते हैं तो आप पाएंगे कि यह FSharp.Core (>= 4.1.17) पर निर्भर करता है, इसलिए मेरे पास कोई अन्य विकल्प नहीं था समस्या एसडीके के साथ है। अगर मैं दोनों ढांचे को एक साथ लक्षित करना शुरू करता हूं, तो मैं वी.एस. में समाधान लोड करने में असमर्थ हूं
परियोजना:

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

वीएस में खोलने की कोशिश कर रहा है:

परियोजना के साथ सब कुछ ठीक है - मुद्दा एफ # एसडीके में कहीं है। इसलिए मैं बेहतर समय तक FsCheck द्वारा .NET कोर समर्थन को स्थगित करना चाहता हूं।

@Kralizek कृपया उत्तर को कुछ उत्तर ऊपर देखें ।

बस वीएस 2017.4 में चेक किया गया और अभी भी एफ # प्रोजेक्ट के लिए एकाधिक ढांचे को लक्षित नहीं कर सकता है। इसलिए, मैं इस मुद्दे को अभी के लिए बंद कर रहा हूं क्योंकि हम अन्य सभी परियोजनाओं के लिए .NET कोर का समर्थन करते हैं।

JFYI: मैंने NuGet के लिए v4 rc1