Aspnetcore: لم يعد من الممكن استخدام حزم ASP.NET Core 2.0 الجديدة على .NET Desktop

سيكون هذا تغييرًا غريبًا وسيئًا للغاية. لقد كتبت الكثير من الكود الأساسي لـ netfx-only asp.net ولا أريد أن أرى ضياع هذا الاستثمار. بشكل عام ، سيحتاج عملاء .NET إلى أن يكونوا قادرين على التشغيل البيني بين ASP.NET Core و Desktop code للمستقبل المنظور - تخيل تطبيقات الويب التي تستخدم Active Directory ، أو أتمتة Office COM ، أو التي تقوم بالتصوير المصغر باستخدام بعض النظام. مكتبة ، أو مشاركة التعليمات البرمجية مع تطبيق WPF. من التافه التفكير في الكثير من السيناريوهات مثل هذا وآمل أن نكون قد أسأنا فهم ما يحدث.

نحن حاليًا على AspNetCore 1.1.1 - أي فرع الدعم "الحالي". إذا لم نتمكن من الانتقال إلى الإصدار 2.0 بسبب التبعيات على Net4XX ، فهل هذا يعني أننا لن نكون مدعومين عندما ينخفض ​​2.0 + 3 أشهر؟

نستخدم مزيجًا من WPF و ASP.NET Core ونستهدف في كلتا الحالتين إطار العمل الكامل.
لذا أعتقد أنه لا يوجد 2.0 في المستقبل المنظور؟

لكن الإطار الكامل 4.6.1 سيدعم المعيار 2؟ هل فاتني شيء؟ (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

أليس هذا أن الأدوات الحالية لم يتم تحديثها؟

سيكون الأمر جيدًا تمامًا ومن المتوقع أن نرى asp.net الأساسية تعمل على معيار الشبكة 2. الشيء المزعج هو هذا الاحتمال للانتقال إلى net core app2.0 ، والذي يعني عدم القدرة على استخدام الكود القديم داخل asp.net المواقع الأساسية

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

سيكون من الجيد سماع الفرق تفكر في هذا

أوه ، إذن هل تعتقد أن مشاريع netcoreapp2.0 ستكون ببساطة قادرة على الإشارة إلى netfx libs بفضل توحيد النوع؟ وهذا يفسر الكثير. سؤالي ، إذا كان الأمر كذلك ، هو مقدار الكود الذي سيعمل بالفعل عند تشغيله على windows ولكن على CLR الأساسي ..

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

أنا فضولي للغاية بشأن هذا أيضًا. أنا آمل حقًا أن يكون هذا في خطوة متوسطة (وقصيرة الأجل) أو سوء تفاهم كبير. سيكون بالتأكيد مانعًا لاعتماد معظم تطبيقاتنا أيضًا.

يعد نقل كل شيء إلى Core أمرًا مبالغًا فيه بالنسبة لقاعدة بيانات كبيرة موجودة (دون التوقف عن القيام بذلك) ، والانتقال إلى فئات ASP.NET الجديدة (طلب HttpRequest ، وحدات التحكم ، وما إلى ذلك) كخطوة وسيطة يجب أن تحدث لمشاريعنا الرئيسية.

ربما يستطيعDamianEdwards أو davidfowl التعليق على الخطط هنا؟ أواجه أيضًا مشكلة في العثور على أي تفكير إضافي.

أستطيع أن أرى لماذا هذه في البداية لحظة WTF مخيفة. اسمحوا لي أن أشرح لأنه أقل فظاعة مما يبدو.

• قلت إن عملاء .NET سيحتاجون إلى التعامل مع بعضهم البعض. موافق تماما.
  
  
  
  • يمكننا مشاركة مكتبات الشبكة القياسية بين ASP.NET Core 2.0 وفي كل مكان.
  
  
  • يمكننا حتى الإشارة إلى العديد من تجميعات net461 + من ASP.NET Core 2.0 بسبب أسلوب التوجيه والشبكة القياسية 20
  
  
• قلت إن WebApps قد تحتاج إلى استخدام:
  
  
  
  • AD - تمامًا ، هذه فجوة إذا كنت تريد استدعاء LDAP مباشرة. يمكنك بالتأكيد المصادقة ضد Windows Auth NOW. نخطط لأن يكون لدينا مساحة اسم DirectoryServices لـ Core 2.0 على وجه التحديد في الإطار الزمني الصيفي
  
  
  • الرسم - تمامًا ، هذه فجوة. نحن نخطط للحصول على هذا لـ Core 2.0 حول الإطار الزمني الصيفي. حتى ذلك الحين ، توجد أيضًا خيارات netstandard هذه ImageSharp و ImageResizer وخيارات Mono وما إلى ذلك
  
  
  • أتمتة COM - لم يكن هذا ممكنًا أبدًا في Core 2.0 ، ولكن يمكنك بالتأكيد PInvoke إذا كنت تريد إيذاء نفسك. يمكنك أيضًا استخدام WebAPI المحلي لعملية net461 + إذا كنت تريد حقًا إيذاء نفسك.
  
  
  • رمز المشاركة مع تطبيقات برنامج الأغذية العالمي - نعم. ممكن تمامًا مع netstandard2.0.
  
  
• هذا تغيير غريب يجب القيام به.
  
  
  
  • أشعر برغبة في ذلك ولكن ...
  
  

فكر في الأمر بهذه الطريقة. WPF ليس netstandard2.0 ، فهو يعرف أنه موجود على net461 + وهذا جيد. لقد تم تحسينه ، لكن يمكنه الإشارة إلى libs القياسية. تم تحسين ASP.NET Core 2.0 لـ Core 2.0 ولكن يمكنه الرجوع إلى المكتبات المشتركة. Xamarin هو نفسه.

NET Core جنبًا إلى جنب ويتحرك بسرعة. إنه أسرع من NET (الكامل) يمكن أن يتحرك وهو أمر جيد. من خلال بناء ASP.NET Core 2.0 فوق .NET Core 2.0 (والتي ، تذكر ، هي مجموعة SUPERSET من .NET Standard) وهذا يعني أنه يمكن إنشاء الأشياء بشكل أسرع من NetFx أو حتى Netstandard.

NetCore> Net Standard> NetFx عندما يتعلق الأمر بسرعة التطوير والابتكار.

النقطة المهمة هي ، إذا كنت تقوم بعمل جديد ، فإن netstandard20. إذا كان لديك مكتبات net461 + أقدم ، فيمكن الإشارة إلى معظمها ضمن ASP.NET Core 2.0.

سيتم دعم ASP.NET Core 1.1 الذي يعمل على .NET Framework بشكل كامل لمدة عام بعد إصدار 2.0. يتم دعم عبء العمل هذا بشكل كامل حتى يوليو 2018 على الأقل.

الفجوات الكبيرة المتبقية المفقودة في .NET Core 2 هي System.DirectoryServices و System.Drawing. نحن نعمل على الحصول على حزمة توافق Windows والتي من شأنها تمكين كل من تلك الموجودة على .NET Core على Windows هذا الصيف.

ما نحتاجه منك جميعًا هو قائمة / فهم واضح لماذا تعتقد أنك بحاجة إلى ASP.NET Core 2.0 للتشغيل على net461 +.

اعتقدت أن NET Standard 2.0 يتعلق بالتوافق وقابلية التشغيل البيني الذي يسد الفجوة بين .NET Core و .NET fx الذي ينتظره الجميع - يبدو أن هذا يقتل ذلك.

لأي سبب من الأسباب ، سيكون هناك الكثير من العملاء الذين سيكون لديهم تبعيات تتطلب .NET 4.x سواء كانت تبعيات خارجية مخصصة ، أو مكونات تجارية ، أو تبعيات lib قديمة ، إلخ.

هل النية هي ألا يتمكن العملاء من إنشاء تطبيقات ASP.NET Core 2.0 تعمل على Desktop CLR حتى يتمكنوا من الرجوع إلى .NET 4.x deps الموجودة لديهم؟

shanselman شكرًا على الرد - الكثير من الأمثلة الجيدة هناك.

متابعة عن المكتبات:
هل ستبقى جميع libs التجريدية مجمعة بشكل متقاطع؟ على سبيل المثال ، إذا كنت أستخدم HttpRequest ، فإن الحفاظ على 1.x و 2.x يعتمد على إصدار ASP.NET Core الذي تستخدمه (والذي يتم تعيينه الآن بشكل واضح إلى TFM على الأقل) سيكون شيئًا أفضل تجنب ... لذلك آمل أن تظل التجريدات على netstandard . هل هذه هي الخطة العامة؟

نحن بالفعل نحتفظ بمتغيرات متعددة للأشياء التي تعتمد على ASP.NET/MVC لأن System.Web HttpRequest مختلفة تمامًا ، لذلك فهذه مكتبة أخرى تمامًا (على سبيل المثال MiniProfiler مقابل . MiniProfiler.AspNetCore ). أريد فقط التأكد من أننا نضع في اعتبارنا عدد المتغيرات التي نحملها على صيانتها لأي مؤلفي lib إذا تحركت تبعياتهم من netstandard ... ونأمل فقط تجنب هذا الصداع معًا.

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

لدي سؤالان / مخاوف:

• يبدو أن استهلاك مكتبات .NET Framework من ASP.NET Core يجب أن يكون له حد أدنى من الاحتكاك. هذا عظيم! ماذا عن طريقة بديلة؟ من المحتمل أن تكون هناك مكتبات وتطبيقات .NET Framework أو netstandard تقوم بتضمين أجزاء أو مكونات من Mvc وغيرها من مكتبات ASP.NET الأساسية الداعمة (أعرف ذلك لأن لدي زوجان). تلك سوف تنكسر ، صحيح؟ هل هناك أي نصائح حول كيفية التغلب على هذا السيناريو؟ إذا لم تعد مكتبات الشبكات القياسية قادرة على استهلاك مكتبات ASP.NET Core ، يبدو أن هذا يمثل مشكلة كبيرة بالنسبة لسيناريوهات ASP.NET Core المضمنة.

• من منظور غير تقني ، يبدو أن هذا سيسبب الكثير من الالتباس. خارج الأشخاص النشطين على GitHub ، تابع عبر Twitter ، وما إلى ذلك ، هناك بالفعل قدر كبير من الالتباس حول الأنظمة الأساسية المختلفة ، وما إلى ذلك. يمكنني رؤية المطورين الذين يتابعون بشكل جزئي فقط أو الذين يستيقظون الآن للتو لتسريع الشعور بالإحباط الشديد عندما يذهبون إلى استخدام ASP.NET Core (ربما بعد برنامج تعليمي قديم) ولا يمكنهم جعله يعمل على أنظمة .NET Framework الأساسية الخاصة بهم. لست متأكدًا مما يمكن فعله حيال ذلك ، إذا كان هناك أي شيء.

يمكننا حتى الإشارة إلى العديد من تجميعات net461 + من ASP.NET Core 2.0 بسبب أسلوب التوجيه والشبكة القياسية 20

لسوء الحظ ، هذا لا يعني أن المكتبة التي تم تجميعها وتصميمها لإطار العمل الكامل ستعمل على .NET Core (الخطر هو أن الأشياء الكبيرة ستنفجر في وقت التشغيل!).

العديد من واجهات برمجة التطبيقات "القديمة" التي أعيد تقديمها في .NET Core 2.0 هي بذرات لن تعمل أبدًا (وظيفيًا). ناهيك عن أنه لا يزال هناك العديد من واجهات برمجة التطبيقات المفقودة ، وحتى مناطق كاملة تم استبعادها عمدًا من .NET Core (IdentityModel ، خادم WCF ، الاتصال عن بُعد ، دعم AppDomain الكامل ، إلخ.)

محاولة إقناع الناس بأنهم يستطيعون "بأمان" ترحيل تطبيقات ASP.NET Core 1.0 w / .NET لسطح المكتب إلى ASP.NET Core 2.0 w / .NET Core - IMHO - كذبة.

NET Core جنبًا إلى جنب ويتحرك بسرعة. إنه أسرع من NET (الكامل) يمكن أن يتحرك وهو أمر جيد. من خلال بناء ASP.NET Core 2.0 فوق .NET Core 2.0 (والتي ، تذكر ، هي مجموعة SUPERSET من .NET Standard) وهذا يعني أنه يمكن إنشاء الأشياء بشكل أسرع من NetFx أو حتى Netstandard.

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

تضمين التغريدة

• صحيح أنه لا توجد إمكانية ضمنية للإشارة إلى netcoreapp2.0 من net461 أو حتى netstandard2.0 . يذهب الجسر في اتجاه واحد. يمكنك دائمًا التغلب على هذه المشكلة عن طريق تحديد TFMs لاحتياطي الحزمة ، ولكن من الواضح أن هذا يمثل فتحة هروبًا ، وليس سيناريو مدعومًا (على الرغم من أنه سيكون كافيًا لإلغاء حظر العديد من الأشخاص). إنه قدر غير ضئيل من العمل بالنسبة لنا لدعم الأنظمة الفرعية لـ ASP.NET Core خارج المكدس الأكبر (وهو ما يعنيه استهداف netstandard ).
• يذهب احتمال حدوث ارتباك في كلا الاتجاهين. على سبيل المثال ، لدينا الكثير من التعليقات بأن حقيقة أن "ASP.NET Core" يمكن تشغيله على .NET Framework (وهو ليس .NET Core) أمر محير. هذا التغيير يجعل ASP.NET Core جزءًا من .NET Core stack بشكل فعال مما يعني أنه إذا كنت تستخدم ASP.NET Core ، فأنت تستخدم .NET Core.

shanselman راجع للشغل ، لم تقل لماذا لم يكن التجميع المتقاطع خيارًا. مكونات ASP.NET الأساسية التي يمكن أن تستفيد من netcoreapp2.0 - فقط واجهات برمجة التطبيقات يمكن أن تحتوي على كل من net46 / netstandard1.x / netstandard2.0 و netcoreapp2.0 TFMs و جعل الأشياء الجديدة الرائعة / السريعة .NET Core فقط.

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

أنت أيضًا تشير إلى أن تقسيم TFM النظيف صحيح ، وهو ميزة لهذه الخطة ، حيث يمكن لحزمة واحدة الآن استهداف ASP.NET Core 1.x و 2.0+ في وقت واحد باستخدام TFM كمحور.

ألعب مع فكرة "التطبيقات المختلطة". على سبيل المثال ، تطبيق WPF يعرض واجهة برمجة تطبيقات الويب أو خادمًا يقدم كل من REST API ونقاط نهاية WCF (قد يكون هذا للتوافق مع العملاء الأقدم). أصبحت هذه السيناريوهات مستحيلة مع هذا التغيير وجعل ASP.NET Core مناسبًا فقط للتطبيقات الجديدة بدلاً من أن يكون "مجرد مكتبة".

PinpointTownes كما ذكر shanselman ، نحن مهتمون جدًا بالمتطلبات المحددة والحواجز التي يمتلكها العملاء فيما يتعلق بالحاجة إلى الاستمرار في استهداف .NET Framework مباشرة. أشار عملنا مع العملاء في هذا القارب حتى الآن إلى أن System.DirectoryServices و System.Drawing وحاجز رقم 1 و 2 ولدينا خطة لمعالجة ذلك. علاوة على ذلك ، فإننا ننظر في التعليقات وسنقيمها.

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

DamianEdwards شكرًا على التوضيح الإضافي. معيار الشبكة -> مكتبات ASP.NET Core هي نوع من الصفقة الكبيرة بالنسبة لي. لقد قمت بتضمين Kestrel (الذي يبدو أيضًا أنه ينتقل إلى netcoreapp) في العديد من مكتبات الشبكات القياسية. لقد قمت أيضًا بتضمين Razor في عدة أماكن ، وأعلم أنك تعمل على إصدار جديد أكثر نمطية ، ولكن إذا كان هذا يستهدف netcoreapp فقط ، فسيؤذي ذلك أيضًا. هناك أيضًا الكثير من المكتبات التي تعد "جزءًا" من ASP.NET Core ولكن لها الكثير من الفوائد خارجها.

بمعنى آخر ، أنا مهتم أكثر بإزالة قدرة مكتبات netstandard على استهلاك حزم ASP.NET Core أكثر مما أنا عليه الآن. يبدو أن هذا يزيل فئة كاملة من حالات الاستخدام من الاعتبار.

ستستمرdaveaglick Razor نفسها (المحرك) في استهداف netstandard . مرة أخرى ، هناك تكلفة مرتبطة بدعم أنظمة فرعية معينة لرسم بياني كبير ومعقد (مثل ASP.NET Core 2.0) على أنظمة أساسية مختلفة. بالنسبة لأشياء مثل التضمين ، توجد خيارات أخرى (تضمين المصدر ، والنسخ ، وما إلى ذلك) ولكنها بالطبع تأتي مع المفاضلات الخاصة بها.

نسمعك بالتأكيد عن الفئات المختلفة لحالات الاستخدام ، فلدينا بالفعل مجموعات مختلفة من العملاء يجب مراعاتها عند تصميم وشحن كومة مثل مجموعتنا.

أشارك اهتماماتdaveaglick هنا: إن رغبة ASP.NET Core في استخدام أحدث واجهات برمجة التطبيقات أمر مفهوم تمامًا ، ولكن كل شيء آخر يتطلب الأمر نفسه يصبح أكثر صعوبة. لا تحصل على أي خيار بعد 1.0 من الاستقرار أو الترقية ، فأنت في أسرع قطار متاح netcoreapp2.0 وهذا هو الخيار الوحيد. إذا كان لا يمكن استهلاك كل البتات (حتى التجريدات الأساسية) دون جعل المستخدمين يستهلكون netcoreapp2.0 ، فهذا يعني أنه لا يوجد فعليًا netstandard2.0 لهذا الخط بأكمله من المكتبات ... والجميع هذا يعتمد عليهم.

أحصل على مجموعة التطبيقات الأساسية تتحرك ، لكنني لا أتفق بالضرورة مع التجريدات بشكل خاص. كانت إحدى النقاط الرئيسية في الأفكار التجريدية هي تجنب الاقتران الضيق مثل هذا ، على الأقل من وجهة نظري كمستهلك. سأكون فضوليًا جدًا لرؤية بعض الأمثلة حيث لا يحتوي netstandard2.0 على واجهات برمجة التطبيقات اللازمة لهم ولكن لا يحتوي netcoreapp2.0 - هل هناك بعض الأمثلة؟ هل هذا بشكل رئيسي حول الأنواع الجديدة في معلمات الطريقة؟ لا أشك في وجود أسباب كثيرة ، فأنا أشعر بالفضول الشديد - رؤية الأمثلة من شأنها أن تساعد في إظهار تكلفة الصيانة التي ليس لدينا الكثير من الأفكار اليومية عنها.

حالة Kestrel أكثر تعقيدًا ، لكنني بالتأكيد أرى الحجج لامتلاكها على أحدث مجموعة API. أتخيل أنه سيتم إنشاء واجهات برمجة تطبيقات جديدة باستمرار لـ Kestrel نظرًا للعمل الذي تقوده.

PinpointTownes كما ذكر shanselman ، نحن مهتمون جدًا بالمتطلبات المحددة والحواجز التي يمتلكها العملاء فيما يتعلق بالحاجة إلى الاستمرار في استهداف .NET Framework مباشرة.

بصفتي مستشارًا ، ساعدت مجموعة من العملاء في نقل تطبيقاتهم إلى ASP.NET Core ، وكان علي غالبًا استهداف .NET Desktop لأتمكن من استخدام مكتبات الطرف الثالث (مغلقة المصدر) اعتمادًا على IdentityModel / WCF أو الاعتماد على AppDomain الدعم.

عدم وجود هذه الأشياء في ASP.NET Core 2.0 سيكون بمثابة مانع رئيسي لهم.

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

في .NET Core ، يُرجع RSA.Create() RSACng مثيل $ # $ 1 $ # $ على Windows ، ولكن على .NET Desktop ، يتم إرجاع مثيل RSACryptoServiceProvider . ومع ذلك ، تحاول العديد من المكتبات - بما في ذلك BLC نفسها - تحويل RSA إلى RSACryptoServiceProvider ، والتي ستفشل دائمًا على .NET Core ، حيث لا يمكن تحويل RSACng إلى RSACryptoServiceProvider .

@ نيك كرافر أي التجريدات بالذات؟ تكمن مشكلة نقل الأفكار المجردة فقط في أنك ستنتهي بعد ذلك برغبة في كل ما يبني على تلك الأفكار التجريدية أيضًا ( إلا إذا كنت تقول حرفيًا أنك تحتاج فقط إلى Microsoft.AspNetCore.

davidfowl نعم ، فقط الأفكار المجردة: على سبيل المثال HTTP و Hosting و HTML و Logging. يبدو أن التعليقات السابقة تمت تغطيتها Microsoft.Extensions.* خلال التعليقات السابقة ، وهي معظم هذه التعليقات. هؤلاء هم الذين أتفاعل معهم اليوم.

للحصول على مثال ملموس: لا ترد MiniProfiler Middleware على أي شيء سوى التجريدات ( رابط )

إذا كنت تستخدم MVC وما إلى ذلك ، حسنًا ، فأنت على netcoreapp2.0 أي حال ، وهذا ما هو عليه (و IMO ، هذا جيد). لكن لدي حاليًا حرية تقسيم واجهات برمجة التطبيقات منطقيًا حيث تتم مشاركتها والقيام بذلك بسهولة لأنها تجريدية. أنا معجب جدًا بالانقسام الحالي ، من فضلك لا تغلقه دون داع.

هيه. بصفتي استشاريًا ، سمعت بالتأكيد "ماذا؟ يعمل ASP.NET Core على سطح المكتب .NET Framework !؟" السؤال عدة مرات. حقيقة أن "ASP.NET Core" يحتوي على ".NET Core" في الاسم أمر مؤسف حقًا.

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

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

يتضمن ذلك عميلي الحالي ، الذي لديه مكتبة / إطار عمل قديم كبير للغاية ، يستهدف .NET Framework ، تستهلكه العديد من مشاريع ASP.NET Core التي يتم تطويرها حاليًا بالتوازي. بحلول الوقت الذي تدخل فيه هذه الأنظمة حيز الإنتاج ، سيكون هناك وقت قليل أو معدوم إما أ) نقل كل شيء إلى .NET Core ، أو ب) نقل كل شيء إلى إطار عمل ASP.NET بالكامل ، قبل أن يصبح ASP.NET Core 1.x غير مدعوم.

هل تكفي حقاً سنة واحدة من الدعم هنا؟ أستطيع أن أتخيل أن هناك حالات أخرى مماثلة هناك ...

khellang كما ذكرنا سابقًا ، سيكونون قادرين على متابعة الرجوع إلى المكتبات / أطر العمل التي تستهدف .NET Framework ، وسيعمل ذلك بشكل جيد على افتراض أن واجهات برمجة التطبيقات التي يسمونها جزء من إغلاق netstandard2.0 . هل تعلم ما إذا كانوا يعتمدون على أشياء خارج هذا الفضاء؟ هذا ما نود حقًا الحصول على تعليقات عليه حتى نتمكن من تقييم أولوية نقل واجهات برمجة التطبيقات (مثل System.DirectoryServices و System.Drawing ).

إذن ، فإن استضافة واجهة برمجة تطبيقات ويب (لنقل طبقة الاتصال) أو حتى مآخذ توصيل asp.net الأساسية القادمة ستصبح مستحيلة بالنسبة لخدمة Windows الحالية أو تطبيق WPF لسطح المكتب؟ (مع الإصدارات المدعومة).

أتخيل أنه ستكون هناك قائمة بالأشياء التي كانت في السابق netstandard1.x والتي أصبحت الآن netcoreapp2.0

لقد تصفحت المستودعات ويبدو أن أشياء محددة لـ MVC هي netcoreapp2.0 لكن HttpAbstractions ، Logging ، Configuration ، وما إلى ذلك لا تزال netstandard أم أن هناك المزيد من التغيير؟

NickCraver أرى أنك تستخدم الامتدادات ولكنك لا تزال تستخدم System.Web. هل لديك خطط لتحويل Microsoft.AspNetCore.Http.HttpContext مع System.Web.HttpContext ؟ هل لديك فكرة عن المقدار الذي تحتاجه من API؟

إذا كنت تستخدم MVC وما شابه ، حسنًا فأنت على netcoreapp2.0 على أي حال ، وهذا ما هو عليه (و IMO ، هذا جيد). لكن لدي حاليًا حرية تقسيم واجهات برمجة التطبيقات منطقيًا حيث تتم مشاركتها والقيام بذلك بسهولة لأنها تجريدية. أنا معجب جدًا بالانقسام الحالي ، من فضلك لا تغلقه دون داع.

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

ستعمل خدمات dasMulli windows بمجرد أن يتم نقل واجهة برمجة التطبيقات (هناك أيضًا مكتبات مفتوحة المصدر تدعم خدمات Windows على .NET Core).

تطبيق WPF لسطح المكتب؟ (مع الإصدارات المدعومة).

نعم. لن يكون هذا هو الافتراضي بعد الآن. لن ندعمه خارج الصندوق بعد الآن مع .NET Core 2.0.

davidfowl لست متأكدًا من أنك نظرت إلى القطع الصحيحة هناك:

ولكن لا تزال تستخدم System.Web

... ليس في نفس المكتبات ، بسبب هذا الانقسام. لتحقيق الحد الأدنى من النفقات العامة وليس حمولة شاحنة من التبعيات للمستهلكين ، هناك MiniProfiler لـ ASP.NET MVC <6 (System.Web) و MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (الكثير من NuGet ).

أعتقد أنك تتحدث عن بقايا System.Web التي كانت على MiniProfiler.Shared - كنت أنتظر تنظيفها حتى تم إصلاح مشكلة NuGet الليلة الماضية على تجميعات إطار العمل. أنا فقط أزلته لتوضيح الأمور.

DamianEdwards لست 100٪ عند إغلاق netstandard2.0 ، لكن سأكون سعيدًا (بعد الحصول على إذنهم) من تشغيل محلل قابلية النقل ومشاركة النتائج. هل لا يزال محلل قابلية النقل شيء محدث؟

أصبح ASP.Net Core بسرعة Python 3 * الجديدة ؛ فقط أسوأ. يبدو هذا وكأنه تحرك في الاتجاه الخاطئ بالنسبة لي. هذا يعني فقط أن الكثير من السيناريوهات ستجبر المطورين على الحفاظ (وكتابة) كود جديد على "المنصات القديمة" لسنوات عديدة قادمة بدلاً من التحرك. لا يبدو أن "التنمية الأسرع" حجة جيدة جدًا إذا كان كل ما يعنيه ذلك هو الوصول إلى مكان أسوأ / غير مناسب "أسرع".

* تعجبني Python 3 ، لكنها انتهت ما يقرب من عقد من الزمان وما زال مجتمع Python ممزقًا

فقط للتوضيح - هل هناك أي مانع تقني (أشياء رائعة) أم أن هذا فقط لتوفير تكلفة الحفاظ على التوافق في المستقبل؟
أعتقد أن معظمنا كان يعلم أن هذه الخطوة ستأتي ولكن لم يتوقعها أحد قريبًا .. نظرًا لأن وقت الانتقال لا يزال مستمراً (مثل libs يتم نقلها ، معيار net 2.0 قاب قوسين أو أدنى ولكن لم يتم إنشاء libs بعد من أجله) - سيكون من الرائع الاحتفاظ بدعم net * لإصدار واحد على الأقل (على سبيل المثال 2.0 ، وليس 2.1).

shanselman أرى نقاطك وأنا شخصياً أوافقك الرأي ، لكن _alot_ من الناس لن يروا الأمر بهذه الطريقة.

لا تتمثل المشكلة الأساسية في استدعاء تجميعات net46 من الأساس ، بل يتعامل المواطنون مع ذلك في معظم الحالات. تكمن المشكلة في كود net46 الحالي و asp.net core 1. * الكود يعمل على 46. كما ذكر أحدهم ، فإن الهدف الكامل من netstandard هو السماح للكود ، بما في ذلك asp.net ، بالعمل في كل مكان ، سيبدو هذا كخطوة بعيدا عن ذلك وربما حتى فشل تلك الرؤية لبعض الناس.

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

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

إذا كنت تريد أن تؤذي نفسك

هذا هو بالضبط. لن يراها مطورو Net46 وإدارته على هذا النحو ، وسوف يرون ذلك لأنك _ أنت ، Microsoft ، تريد إلحاق الأذى بهم من أجل مواكبة أحدث إصدار. قد يقول المرء "حسنًا ، لا تتحرك إذن" ولكن بدعم من asp.net core 1.x قصير بقدر ما هو عليه نوعًا ما ، على الأقل من منظور المديرين الذين يجب أن يتحملوا المسؤولية إذا علة يسبب التوقف أو فقدان المعلومات. (حتى لو كان الإطار غير مسؤول)

الكثير من المطورين الذين دفعوا حقًا إلى asp.net core 1.1 سيشعرون أيضًا بالخيانة لأنهم لن يكونوا الآن قادرين على الانتقال إلى 2.0 بدون النواة. قد يكون هذا مبررًا وقد لا يكون ، لكنني أقول لك فقط ، سيشعر الكثير من الناس بهذه الطريقة ، وسيكونون هم الذين يتعين عليهم الرد على زملائهم الأكثر تحفظًا

هل أي من هذا يهم؟ هل سيموت asp.net core2 / dotnet core2 بسبب هذا؟ لا ، لكنه سيؤدي إلى إبطاء التبني وكسر النظام البيئي وهذا أمر محزن حقًا. أريد أن يكون الناس قادرين على استخدام كل هذه الأشياء الرائعة القادمة في الإصدار 2.0 ، وسيؤثر قطع التجميع المتقاطع إلى معيار الشبكة على ذلك. بالتأكيد ، لن يواجه معظم الأشخاص الذين يقضون وقتًا طويلاً في هذه المستودعات مشكلة ، فهي Joe and Jane dev وحتى أكثر من ذلك ، مديرهم هو المشكلة.

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

للتأقلم مع الصيف ، أنا متأكد من أن هذا القرار لم يتم اتخاذه بسهولة ، ولكن إذا كان عليك القيام بذلك ، فأعتقد أنه يجب أن تكون حذرًا حقًا بشأن الرسائل .. عليك إظهار أن الهجرة إلى asp.net core ، خاصة من 1. x على net46 بسيط للغاية ومصقول للغاية. القصة للإشارة إلى المكتبات القياسية الأخرى من net46 كمراجع للمشروع وبخلاف ذلك يجب أن تكون صلبة للغاية. أعتقد أنك بحاجة إلى إظهار / عنوان هذا بشكل صريح لتجنب ذعر الناس

khellang pagingterrajobst لسؤال محلل قابلية النقل.

تضمين التغريدة

نعم ، لقد قمنا للتو بتحديث VSIX لعام 2017 ، لكنني ببساطة أستخدم إصدار سطر الأوامر من هنا .

NickCraver بالتأكيد ، يمكنك كتابة قطعة من البرامج الوسيطة التي تستهدف netstandard ، ما فائدة ذلك بالنسبة لك كمؤلف مكتبة إذا كان ASP.NET Core يدعم netcoreapp2.0.

@ aL3891 ملخص عظيم! تتمثل إحدى المشكلات الكبيرة التي نواجهها في المضي قدمًا في كيفية الاستفادة من واجهات برمجة التطبيقات الجديدة للأشياء الموجودة أيضًا في معيار الشبكة. ستحصل .NET Core على واجهات برمجة تطبيقات جديدة نحتاجها لتنفيذ ميزات جديدة (أحدها هو دعم SSLStream ALPN لدعم HTTP2 في Kestrel). لذلك يمكنك أن تجادل بأننا نبقى على شبكة الإنترنت ونستخدم باستمرار الإصدار الأعلى (الذي لا يدعمه .NET Framework حتى الآن) ولكن بعد ذلك سنكون في نفس المركب.

تتمثل إحدى المشكلات الكبيرة التي نواجهها في المضي قدمًا في كيفية الاستفادة من واجهات برمجة التطبيقات الجديدة للأشياء الموجودة أيضًا في معيار الشبكة. ستحصل .NET Core على واجهات برمجة تطبيقات جديدة نحتاجها لتنفيذ ميزات جديدة (أحدها هو دعم SSLStream ALPN لدعم HTTP2 في Kestrel).

وفقًا لـ https://github.com/dotnet/corefx/issues/4721 ، لن يكون دعم ALPN لـ SslStream جاهزًا لـ .NET Core 2.0. بافتراض تنفيذ ذلك في النهاية بعد بضعة أشهر ، فهل يعني ذلك أنه سيتمكن المرء من استخدامه عند استهداف TFM netcoreapp2.0 ؟ في هذه الحالة ، ماذا سيحدث إذا قررت إصدار مكتبة تستند إلى netcoreapp2.0 تستخدم واجهات برمجة تطبيقات جديدة لم تكن جزءًا من الشكل الأولي netcoreapp2.0 إذا كان المستخدمون يستخدمون وقت تشغيل أقدم من NET Core. ؟ هل ستتحطم؟ أم هل سيتوافق netcoreapp2.x مع netstandard1.x ، الذي لا يمكن تغيير عقده بدون زيادة إصدار TFM؟

davidfowl للتطبيقات الأخرى لأي قطعة من المكدس والاختبار. ولأن الطريقة التجريدية (لا تتطلب MVC) كتقسيم لائق بين مكتبتين بدلاً من "افترض أن كل شخص لديه MVC ويريد كل التبعيات".

إذا لم تكن التجريدات عبارة عن أفكار مجردة بالفعل ومرتبطة بإحكام بـ ASP.NET Core نفسها ، فلماذا لا نزيل هذه الحزم فقط؟ إنه سؤال صادق ، لأن ذلك سيجعل الحياة أسهل وأكثر وضوحًا إذا كان هذا هو الهدف العام للعلاقة. أحاول أن أفهم الهدف من وجود التجريدات كحزم منفصلة إذا كانت مرتبطة بشكل فعال بتطبيق / استخدام بسيط. أفترض أنه لا يوجد شخص خارج Microsoft يريد أو لديه الموارد لتكريسها لخادم ويب منافس netcoreapp2.x (يسعدني أن يتم تصحيحه هناك!).

هل يمكنك توضيح الهدف من عمليات التجريد في عالم netcoreapp2.x ؟ أو إذا كانت هناك خطط لإهمالهم ببساطة في الإصدار 2.0؟

وفقًا لـ dotnet / corefx # 4721 ، لن يكون دعم ALPN لـ SslStream جاهزًا لـ .NET Core 2.0. بافتراض تنفيذ ذلك في النهاية بعد بضعة أشهر ، فهل يعني ذلك أنه سيتمكن المرء من استخدامه عند استهداف netcoreapp2.0 TFM؟ في هذه الحالة ، ماذا سيحدث إذا قررت إصدار مكتبة تستند إلى netcoreapp2.0 تستخدم واجهات برمجة تطبيقات جديدة لم تكن جزءًا من شكل netcoreapp2.0 الأولي إذا كان المستخدمون يستخدمون وقت تشغيل .NET Core أقدم؟ هل ستتحطم؟ أم سيتم محاذاة netcoreapp2.x مع netstandard1.x ، الذي لا يمكن تغيير عقده دون زيادة إصدار TFM؟

سوف يتماشى إصدار ASP.NET x مع إصدار .NET Core x فقط. سيتم تحديث TFM لتتماشى مع كل إصدار من .NET Core. إنه منتج واحد يمكن أخيرًا التعامل معه على هذا النحو. هذا أحد التبسيط الرئيسي الذي نقوم به كما ذكر DamianEdwards أعلاه. لن نكسر الأشخاص الذين يبنون المكتبات عن طريق إضافة واجهات برمجة تطبيقات جديدة في جوهرها دون تغيير TFM.

تضمين التغريدة

للتطبيقات الأخرى لأي قطعة من المكدس والاختبار.

ما التطبيقات الأخرى؟ هل هناك أجزاء أخرى من المكدس تقوم بتطبيق ASP.NET Core.

إذا لم تكن التجريدات عبارة عن أفكار مجردة بالفعل ومرتبطة بإحكام بـ ASP.NET Core نفسها ، فلماذا لا نزيل هذه الحزم فقط؟ إنه سؤال صادق ، لأن ذلك سيجعل الحياة أسهل وأكثر وضوحًا إذا كان هذا هو الهدف العام للعلاقة. أحاول أن أفهم الهدف من وجود التجريدات كحزم منفصلة إذا كانت مرتبطة بشكل فعال بتطبيق / استخدام بسيط. أفترض أنه لا يوجد شخص خارج Microsoft يريد أو لديه الموارد لتكريسها لخادم ويب netcoreapp2.x منافس (يسعدني أن يتم تصحيحه هناك!).

هل يمكنك توضيح مغزى الأفكار المجردة في عالم netcoreapp2.x؟ أو إذا كانت هناك خطط لإهمالهم ببساطة في الإصدار 2.0؟

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

ببساطة ، تدور الأفكار التجريدية حول تقليل عدد التبعيات ، وليس حول إمكانية نقل النظام الأساسي.

لن نكسر الأشخاص الذين يبنون المكتبات عن طريق إضافة واجهات برمجة تطبيقات جديدة في جوهرها دون تغيير TFM.

قلتم يا رفاق أنك تريد اختيار netcoreapp2.0 - فقط لأنه كان يتحرك بشكل أسرع - مقارنة بـ .NET Desktop وبالتبعية ، .NET Standard - ولكن ما الهدف من استهداف netcoreapp2.0 بدلاً من netstandard2.0 إذا لم تستطع الاستفادة من NET Core APIs الجديدة دون تغيير TFM؟ (على سبيل المثال ، netcoreapp2.1 )

قلتم يا رفاق أنك تريد اختيار netcoreapp2.0 فقط لأنه كان يتحرك بشكل أسرع - مقارنة بـ .NET Desktop ومن ثم .NET Standard - ولكن ما الهدف من استهداف netcoreapp2.0 بدلاً من netstandard2.0 إذا كان بإمكانك ألا تستفيد من NET Core APIs الجديدة دون تغيير TFM؟ (على سبيل المثال netcoreapp2.1)

آسف ، لقد أخطأت في الكلام ، أعني netcoreapp2.x وليس netcoreapp2.0 .

حسنًا ، أنا في حيرة من أمري الآن.

آسف ، لقد أخطأت ، أعني netcoreapp2.x وليس netcoreapp2.0.

لست متأكدًا من فهمي. هل تقصد أنه سيكون هناك معادلة بين حزم ASP.NET Core 2.1 و netcoreapp2.1 TFM؟

هل تقصد أنه سيكون هناك تكافؤ بين حزم ASP.NET Core 2.1 و netcoreapp2.1 TFM؟

نعم. فكر في 2 كواحد في نفس الشيء. انظر https://github.com/aspnet/Home/issues/2022#issuecomment -299544884

إذن ما الذي يمنعك من تبني نمط مشابه ولكن مع netstandard ؟ سيكون هذا هو أفضل نهج ، IMHO: يمكن اعتماد واجهات برمجة التطبيقات الجديدة عبر TFMs الجديدة ولا يزال بإمكان الأشخاص الذين يحتاجون إلى دعم .NET Desktop تشغيل تطبيقات ASP.NET Core الخاصة بهم في إطار العمل الكامل.

ASP.NET Core 2.1 / .NET Core 2.1 / .NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2 / .NET Core 2.2 / .NET Desktop 4.8 -> netstandard2.2 .

PinpointTownes نظرًا لأن .NET Framework على سطح المكتب لا يمكنه الشحن بالسرعة الكافية ، وهذا هو جوهر معظم مشكلات الإصدار مع Core. إنها مشكلة صعبة في سلسلة هائلة.

لن يتحرك .NET Standard بنفس سرعة .NET Core. لا مكان قريب منه في الواقع. يؤدي الانتقال في .NET Standard بشكل أساسي إلى ترك جميع الأنظمة الأساسية في الخلف ، حتى يتم اللحاق بالركب ، ويكون .NET Framework هو أبطأ حركة والأكبر في الوقت نفسه.

رمز نقطة ، مع ذلك 'لست متأكدًا من السرعة التي يُفترض أن يتم بها شحن .NET Framework (على سبيل المثال ، تم نقل واجهات برمجة تطبيقات ECDSA الجديدة من CoreFX إلى NetFX في أقل من عام ، والذي يبدو أنه إطار زمني معقول لمكونات التشفير الحساسة هذه ).

التجميع المتقاطع عبارة عن نفقات عامة يجب موازنتها مع احتياجات العملاء والمنتجات.

عندما يكون لديك دقيقة واحدة ، أود أن أعرف المزيد عن الطبيعة الدقيقة للحمل الناجم عن التجميع المتقاطع. شكرا.

ما نحتاجه منك جميعًا هو قائمة / فهم واضح لماذا تعتقد أنك بحاجة إلى ASP.NET Core 2.0 للتشغيل على net461 +. كن محددًا حتى نتمكن من سد تلك الفجوات والسماح للجميع بالنجاح.

في الوقت الحالي ، نحتاج إلى إصدار الإطار الكامل لمكتبات عملاء WCF - لأن إصدارات netstandard / netcore (https://github.com/dotnet/wcf) ليست قريبة من الاكتمال.

عندما يكون لديك دقيقة واحدة ، أود أن أعرف المزيد عن الطبيعة الدقيقة للحمل الناجم عن التجميع المتقاطع. شكرا.

سيكون هناك وقت في المستقبل القريب جدًا حيث لا يمكننا حرفيًا ملء ميزات مثل دعم ALPN لـ SSLStream. كما أننا لم نبدأ حتى في توسيع أرجلنا وإضافة واجهات برمجة التطبيقات إلى .NET Core ، حتى الآن تعثرنا في إعادة نقل الأشياء إلى .NET Standard و .NET Core 2.0 (الغرض الكامل من .NET Standard 2.0) . سنقوم بإضافة واجهات برمجة تطبيقات جديدة واستهلاكها أخيرًا في ASP.NET Core في اليوم الأول.

في الوقت الحالي ، نحتاج إلى إصدار الإطار الكامل لمكتبات عملاء WCF - لأن إصدارات netstandard / netcore (https://github.com/dotnet/wcf) ليست قريبة من الاكتمال.

ctolkien هذه مشكلة وهذا هو السبب في أننا نقلنا عميل WCF في المقام الأول. هل تعرف ما الذي يمنعك؟ هذه فرصة جيدة لمساعدتنا في تحديد الأولويات.

davidfowl https://github.com/dotnet/wcf/issues/8

قد يكون هناك المزيد ، كانت هذه فقط العقبة الأولى التي واجهناها قبل الانتقال إلى إطار العمل الكامل wcf.

سيكون هناك وقت في المستقبل القريب جدًا حيث لا يمكننا حرفيًا ملء ميزات مثل دعم ALPN لـ SSLStream.

كيف يكون ذلك مشكلة؟ AFAICT ، لم يقل أي شيء هنا على الإطلاق أن نكهات .NET Desktop و .NET Core لـ ASP.NET Core يجب أن تدعم نفس مجموعة الميزات بالضبط. إذا كانت الميزة غير متوفرة على .NET Desktop بسبب فقدان واجهات برمجة التطبيقات (مثل HTTP 2/0) ، فلماذا لا تجعلها NET Core فقط وتطرح PlatformNotSupportedException لإخبار المطور أن الميزة التي يبحث عنها هي غير متوفر؟
سيكون أفضل بكثير من جعل جميع حزم ASP.NET Core .NET Core فقط ، على الرغم من أنه من غير المحتمل أن تستخدم معظمها واجهات برمجة تطبيقات BCL جديدة.

davidfowl أعتقد أن أحد المخاوف الرئيسية هو أن الأشياء لا يتم إصلاحها على سبيل المثال netcoreapp2.3 ، يتم إصلاحها في netcoreapp2.4 . إذا كان ASP.NET Core يركز على أسرع قطار ، فكم من الوقت تحصل على الحب مع كل إصدار ثانوي؟ إذا اضطررنا إلى الترقية باستمرار ، فيجب على كل مستهلك الترقية باستمرار.

هذا رائع للحصول على الأحدث والأفضل ، لكنه ليس الأفضل لمعظم الشركات. لذلك يتعين علينا إما الاحتفاظ بالعديد من الإصدارات (كل إصدار ثانوي) مع مكتباتنا لكل مستهلك لـ ASP.NET Core (لعدم الاعتماد على الأحدث ومواكبة) ، أو سحب المستخدمين إلى أحدث إصدار لمواكبة ذلك. هذا ليس صديقًا لأشياء مثل البيئة التي تم التحقق من صحتها.

ما لم تكن التجريدات بحاجة إلى السرعة (أمثلة؟) ، فسيكون من الأفضل فصلها. بهذه الطريقة لن تقوم بسحب النظام البيئي بأكمله مع كل ترقية. أعتقد أني قلق أكثر من أنهم سيكونون على netcoreapp ، ولكن سيتم تحديثهم باستمرار وكل شيء مرتبط بإحكام.

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

PinpointTownes :

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

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

هذا فشل وقت التشغيل وسلوك غير مرغوب فيه إلى حد كبير.

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

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

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

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

AFAICT ، لم يقل أي شيء هنا على الإطلاق أن نكهات .NET Desktop و .NET Core لـ ASP.NET Core يجب أن تدعم نفس مجموعة الميزات بالضبط. إذا كانت الميزة غير متوفرة على .NET Desktop بسبب فقد واجهات برمجة التطبيقات (مثل HTTP 2/0) ، فلماذا لا تجعلها .NET Core فقط

النصف الأول من ذلك هو netstandard . إن التفريق بين netcoreapp هو بالضبط ما يفعلونه هنا. بدون استثناءات مقصودة. إنه عقد مناسب في هذا الطريق.

تريد أن تسير في اتجاه الشيء الذي يمكن إصلاحه وتحسينه بشكل أسرع عند وجود فجوات ، وليس العكس. يمكن إصلاح استثناءات "PlatformNotSupported" في المكتبة غدًا ، بدلاً من انتظار تحديث المنصة بعد 3 أشهر من الآن. يمكن لـ .NET Core دعمها بشكل أسرع لأن الكود الفعلي يأتي معها ، وليس بشكل منفصل كوكلاء إعادة توجيه في معظم الأوقات.

[PinpointTownes] إذا كانت الميزة غير متوفرة على .NET Desktop بسبب فقد واجهات برمجة التطبيقات (مثل HTTP 2/0) ، فلماذا لا تجعلها .NET Core فقط وتطرح PlatformNotSupportedException لإخبار المطور بأن هذه الميزة يبحث عنه غير متوفر؟

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

يسمح اتباع اتجاه netcoreapp بشحن الإصلاحات في إصدارات ثانوية.

كيف يختلف ذلك عن نهج 1.0؟ قال davidfowl إن واجهات برمجة التطبيقات الجديدة ستتطلب TFMs جديدة ، مما يعني أنه سيتعين عليك إلغاء الاشتراك في LTS للحصول على إصلاحات تعتمد على NET Core APIs الجديدة. ليس حقا الوضع المثالي.

إن التفريق بين تطبيق netcoreapp هو بالضبط ما يفعلونه هنا.

التمييز جيد تمامًا وأنا أوافق بالتأكيد على أن NET Core هو الهدف المفضل لـ ASP.NET Core. لكن هذا لا يعني التخلي عن .NET Desktop تمامًا ، خاصةً عند وجود بدائل مثل التجميع المتقاطع.

نحن بحاجة إلى تحقيق التوازن بين البساطة في سطح API والوصول إلى إنتاجية المطور.

بالتأكيد. لكنك تحتاج أيضًا إلى موازنة ذلك مع الحقائق القديمة - التي تم تطويرها لـ .NET Desktop واستخدام ميزات غير متوفرة على .NET Core - يجب أن تعمل بشكل جيد في ASP.NET Core 2.0 ، تمامًا كما فعلت في الإصدار 1.0.

بدلاً من ذلك ، سنقوم إما بإسقاط دعم إصدارات أنظمة .NET الأساسية التي لا تحتوي على الميزات أو تقديم الميزة كحزمة NuGet مستقلة لا يتم دعمها في كل مكان.

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

قد يكون من المفيد الحصول على ريبو forward-port في dotnet حيث يمكن للأشخاص تقديم طلبات API لعناصر معينة يعتبرونها مفقودة من .NET Core من .NET Framework؟

ثم يمكن القيام بالتعليقات والمراجعات والإرشادات خارج الضوضاء اليومية لريبوس التعليمات البرمجية؟ أو مراجعة عامة لواجهة برمجة التطبيقات / ريبو المواصفات (نوع من مثل csharplang vs roslyn)

سيكون أيضًا خيارًا جيدًا لـ: "لدي مشكلة في التحويل وأحتاج إلى البحث عن مشكلة متعلقة بـ X api" في حين أن corefx مزعجة جدًا لذلك.

[benaadams] هل من المفيد الحصول على إعادة توجيه للمنافذ في dotnet حيث يمكن للأشخاص تقديم طلبات API لعناصر معينة يعتبرونها مفقودة من .NET Core من .NET Framework؟

أود أن أقول إن هذه مجرد مشكلات في CoreFx. كما نعد بشكل عام: إذا تمت مشاركة النوع بين .NET Framework و .NET Core ، فإننا نعتزم نقل أعضاء مضافين حديثًا إلى .NET Framework. في حالات نادرة جدًا ، قد لا يكون هذا ممكنًا ، لكن الحصة في الأرض هي أنه يتم النظر فيها تلقائيًا.

[benaadams] أو مراجعة عامة لواجهة برمجة التطبيقات / ريبو خاص

لست متأكدًا من أنه يستحق ذلك. مراجعات API ثقيلة إلى حد ما بالفعل ؛ يبدو أن استخراجها إلى ريبو آخر يضخم ذلك. أفضل أن نستمر في تبسيط CoreFx بحيث تكون إضافة واجهات برمجة تطبيقات جديدة بسيطة مثل القيام بذلك في ASP.NET على سبيل المثال.

كما ذكرنا سابقًا ، سيكونون قادرين على متابعة الرجوع إلى المكتبات / أطر العمل التي تستهدف .NET Framework ، وسيعمل ذلك بشكل جيد على افتراض أن واجهات برمجة التطبيقات التي يسمونها جزء من إغلاق netstandard2.0

DamianEdwards ماذا عن واجهات برمجة التطبيقات وليس في إغلاق netstandard2.0؟ معظم مكتبات الطرف الثالث مغلقة المصدر. كيف يمكنني معرفة أن كل حالة حافة في إغلاق netstandard2.0؟
كما لمح PinpointTownes ، هذا يشبه نوعًا ما لعب الروليت الروسي.

ستساعد أدوات MJomaa هنا ولكن من الواضح أن الطريقة الوحيدة لمعرفة ذلك على وجه اليقين هي تشغيلها بالفعل. هذا في الواقع لا يختلف عن مكتبة .NET Standard التي تعمل على إطار عمل مدعوم من .NET Standard. لا تحل API الحالية محل الحاجة إلى اختبار هذه المكتبات. هذا لا يعني أن تطبيقات netstandard لا تهدف إلى أن تكون متوافقة ، لكنها عبارة عن حواف ، على سبيل المثال https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

هذه هي واجهات برمجة التطبيقات الموجودة في NS 2.0 ولكنها ليست في .NET Framework 4.6.1.

لقد شعرت بالتوتر حقًا بشأن هذا التغيير ، لكن بعد قراءة الموضوع يبدو جيدًا من الناحية النظرية. لدينا 5 تطبيقات ASP.NET Core مع 4 منها في إطار عمل كامل ، ولكن هذا كان في الغالب فقط كوننا دفاعيًا أكثر من أي شيء آخر وسلك الطريق الأقل مقاومة.

أعتقد أن نوعًا من الأدوات المخبوزة في VS مثل .NET Core Portability Analyzer يمكن أن تساعد المطورين الذين لم يكونوا محدثين على Twitter / GitHub ولا يدركون وجود هذا الامتداد. تتبادر إلى الذهن النافذة المنبثقة "اقتراح امتداد" ، لكنني لست متأكدًا من الإجراء الذي سيتخذه الشخص لبدء ذلك. هل تحاول إضافة net46x lib إلى تطبيق ASP.NET Core 2+ ربما؟

لا تستطيع Microsoft التحكم مثل دعم الجهات الخارجية مع Telerik و Syncfusion وما إلى ذلك ، وستكون أداة حظر محتملة أيضًا اعتمادًا على ما تفعله.

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

لترديد ما قاله الآخرون. لقد تحدثت مع ما لا يقل عن 10 مطورين لم يكونوا يعرفون أن ASP.NET Core يمكن أن يعمل في إطار عمل كامل. كانت لدي نفس التجربة مثل @ aL3891 على الرغم من أن المطورين كانوا سعداء حقًا بأنهم يستطيعون تشغيل ASP.NET Core في إطار عمل كامل وستعمل libs الداخلية الخاصة بهم فقط. مرة أخرى - ستكون الرسائل حول NET Core 2.0 التي تحتوي على غالبية كبيرة من حالات الاستخدام مهمة جدًا جدًا. الجزء المتعلق بالحصول على حل Windows فقط على الأقل لمثل System.DirectoryServices في الأعمال سيكون مهمًا أيضًا. الكثير من مطوري NET الذين تحدثت معهم لتجاهلهم عندما يسمعون أن NET Core هو متقاطع ويهتمون أكثر بكودهم الحالي الذي يعمل أكثر من x-plat / perf.

يا رفاق ، هذا نوع من القمامة :(
لقد قمنا ببناء ASP.NET Core بسبب خيار استخدامه مع netfx ، وقمنا ببناء أشياء كان من المفترض أن تستمر لمدة 5-10 سنوات ، وليس لمدة عام واحد كحد أقصى من الدعم. هذا ما يعنيه اسم ASP.NET في مجال الأعمال ولهذا السبب تختاره المؤسسات الكبيرة بطيئة الحركة بدلاً من أطر عمل الشهر. دعني أنتقل إلى حالات الاستخدام الملموسة ..

أنا أعمل في مجموعة أدوات تبني خطًا من مكتبات الأعمال والتطبيقات لاستخدامها داخليًا في شركة ما وبيعها لعملاء "المؤسسات". معظمهم من المنظمات الحكومية في حالتنا ولكني متأكد من أنك ستسمع نفس الشيء من القطاع الخاص. لدينا أطر عمل داخلية تقوم بترميز أنماط الأعمال إلى تجريدات مشتركة - فكر في "IDatabaseConnection" و "IEntityProvider" و "IWizardFlow" و "ICodeGenerator" - ونبني واجهات RAD الأمامية فوق هذه الخلفية القابلة للتوصيل.

في مجموعتنا ، يعد ASP.NET Core "مكونًا إضافيًا" - إنها وجهة HTTP ، تُستخدم كتجريد لمخزن البيانات ولخدمات الاستضافة وما إلى ذلك. إنها أيضًا "واجهة أمامية" - من الواضح أن مجموعة من تطبيقات LOB توجد مواقع ويب ، وهي إطار عمل جديد رائع لتطبيقات الويب. لذلك لدينا متطلبات التشغيل البيني ثنائية الاتجاه - كود AN-C الذي يشير إلى مكونات أخرى عشوائية ، وكود عشوائي آخر يشير إلى AN-C.

نحن معجبون تمامًا بـ Core CLR وقابلية النقل ، وقد نقلنا مجموعة من مكوناتنا لاستهداف أو معيار شبكة متعددة الأغراض. لدينا تطبيق واحد مستضاف على Linux حتى الآن ونأمل في الحصول على المزيد في المستقبل. ومع ذلك ، لا توجد طريقة يمكن من خلالها نقل كل شيء في أي وقت قريب! لا يزال لدينا رمز نشط مطور بشكل نشط يعتمد عليه

• مصادقة NTLM (بما في ذلك السيناريوهات المتقدمة حول الرموز المميزة و SPNs)
• النظام: الرسم على النحو الوارد أعلاه (تجعد مثير للاهتمام هنا: نحتاج إلى تنسيقات صور قديمة مثل TIFF ، والتي لا تدعمها مكتبات OSS الجديدة)
• الاتصال بـ WCF / SOAP apis - لا يزال هناك أطنان وأطنان منها
• واجهات برمجة تطبيقات Windows (بما في ذلك RSACng و ECDSA و CSP لرموز PKI)
• WPF guis - لا يقوم عملاؤنا بالتبديل إلى نظام التشغيل Windows 10 في أي وقت قريب ، وحتى عندما يفعلون ذلك لن يرغبوا في تطبيقات المتجر
• إمكانية التشغيل المتداخل لـ Microsoft Office (خاصة الوصول والإكسل) لاستيراد البيانات وتصديرها
• قابلية التوسع في Visual Studio
• المكونات الإضافية لجهات خارجية مثل موفر Oracle ADO.NET

لن يتم دعم بعض هذه التقنيات من خلال Core CLR. لكنها تقنيات حقيقية ، وهي أساس تطوير التطبيقات الجديدة - نحتاج إلى إصدار من .NET يمكنه الوصول إلى هذه الأشياء. في الوقت الحالي ، يمكن التحكم في موقفنا: فنحن نعزل التبعيات "القديمة" (حقًا: خاصة بالمنصة) في مكوناتها الخاصة التي تكون محددة بـ net461. بعد ذلك ، تعتمد تطبيقات الأعمال المحددة على netfx إذا احتاجت إلى هذه الميزات ، وليس غير ذلك. أتخيل مستقبلًا يكون فيه هذا نادرًا بالنسبة للتطبيقات الجديدة .. ولكن من الصعب تخيل أنه سيكون 0٪.

لقد قمت بكل هذا العمل على csproj و SDK لأن interop مهم. ASP.NET Core هو الجزرة ، والسبب في الرغبة في التشغيل المتداخل. لا أعتقد أنه من المنطقي إزالته. ولا ، "يمكنك تحميل مراجعك في اتجاه واحد ، ولكن من المحتمل أن تفشل في وقت التشغيل" ليست قابلية للتشغيل البيني.

gulbanana هل يمكنك وصف أجزاء النظام التي تستخدم ASP.NET Core لماذا يجب أن تكون في نفس العملية مثل .NET Framework. أقدر القائمة (ملحقات Visual Studio ، إمكانية التشغيل المتداخل للمكتب ، إلخ) ولكن هل تم تضمين ASP.NET Core في جميع هذه الأماكن اليوم (ليس لدي صورة جيدة من الوصف أعلاه)؟

أيضًا ما الذي كنت تستخدمه قبل وجود ASP.NET Core؟ أم أن هذا مجرد مسعى جديد لم يستخدم ASP.NET مطلقًا ولكنه أخذ رهانًا لمدة 5-10 سنوات على ASP.NET Core على .NET Framework كونه شيئًا؟ هل نظرت إلى كاتانا؟

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

NTLM / م

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

نظام الرسم

يستخدم هذا في تطبيق الويب الذي ينشئ صورًا مصغرة وتحريرات أساسية للصور (التدوير ، تراكب العلامة المائية). يعود تاريخ العديد من الصور المستخدمة إلى زمن الديناصورات ، لذلك توجد أشياء مثل TIFF هناك. إنها بيانات تحتفظ بها إدارة حكومية تتعلق بقوائم عقارات معينة وإدارة الأراضي. في هذه الحالة ، كان التطبيق في البداية ASP.NET MVC ، وتم ترقيته / إعادة كتابته من خلال MVC 2 و 4 و 5 والآن Core.

VSIX

هذه حالة تضمين AN-C في netfx بدلاً من العكس. لدينا امتدادات Visual Studio لتوليد الكود والتي تقوم بتشغيل "قوالب" لسيناريوهات RAD المختلفة. تم إنشاء بعض هذه القوالب لتطوير الويب والإشارة إلى أنواع AN-C في وقت التصميم (تم إنشاؤها باستخدام المعالج المسبق / وقت التشغيل T4).

تشفير

أعتقد أن هذا واحد بالفعل يجب أن يكون قيد التنفيذ - لدينا سيناريوهات الترخيص حيث يكون الرمز حساسًا للغاية من الناحية الأمنية. بشكل عام ، تقوم بفك تشفير ملفات الترخيص والتحقق منها فيما يتعلق بالبيئة التي يعمل بها الرمز - هذه مكتبة شائعة تُستخدم في الواجهة الخلفية لتطبيقات الويب وكذلك تطبيقات سطح المكتب. في النهاية ، يبدو أن NET Core سيحصل على دعم تشفير كافٍ بحيث يمكن نقله ، لكنه لم يحدث اليوم. على سبيل المثال ، لدينا خيار واحد اليوم هو دعم رمز Fortinet / ePass2003 PKI ، حيث لا تدعم برمجياتهم الوسيطة Core بالتأكيد (وليس هناك إطار زمني للقيام بذلك).

أوراكل ADO.NET

لا يجب أن يكون استخدام Entity Framework 6 مع واجهة Oracle الخلفية قيد التنفيذ ولكن من المؤكد أنه سيكون غير مريح لمواقعنا الإلكترونية لإضافة طبقة إضافية فقط للوصول إلى قاعدة البيانات!

WPF Interop

نستخدم Microsoft.Extensions.Logging في جميع تطبيقات سطح المكتب لدينا هذه الأيام - يجب أن تكون عمليات التسجيل المجردة نفسها قيد التنفيذ ، حتى لو لم تكن التطبيقات كذلك.

أما ما استخدمناه قبل ASP.NET Core - ASP.NET MVC! يمكننا العودة ولكن سيكون من العار أن نتخلى عن كل الفوائد.

باعتباري مهندسًا معماريًا ، فإن الخطأ في عدم النظر في ما إذا كان "ASP.NET Core يعمل في إطار عمل كامل" سيستمر إلى ما بعد الإصدار الأول. بصراحة لم يخطر ببالي أبدًا أنه لن يحدث ذلك. أنا فقط لم أتخيل احتمال أنه في وقت مبكر من عام 2018 ، على سبيل المثال ، قد لا يكون هناك إصدار مدعوم يمكنه تحميل مستندات Office ...

هناك شيء واحد لست واضحًا بشأنه وهو مكان استخدام ASP.NET Core في كل من هذه السيناريوهات التي ذكرتها.

NTLM / م

هذا منطقي وأود أن أفهم ما هي واجهات برمجة التطبيقات التي ينتهي بها الأمر بالتخطيط. هل هذه مجرد System.DirectoryServices؟ يتم العمل بنشاط على هذا واحد (يمكنك رؤيته في corefx).

نظام الرسم

هذه فجوة معروفة نتطلع إلى معالجتها. ليس لدي أي إجابات هنا حتى الآن ولن أقترح إعادة الكتابة باستخدام ImageSharp (على الرغم من أن هذا خيار). هذا سوف يحتاج إلى معالجة.

VSIX

أين هو ASP.NET Core هنا؟ هل يعمل داخل امتداد استوديو مرئي؟

تشفير

هل هناك مشكلة corefx لهذا واحد؟ لماذا لا يتم نقلها فقط؟ على عكس .NET Framework ، يتم فصل إصدارات .NET Core عن نظام التشغيل لذلك من الممكن أن يحدث هذا عاجلاً وليس آجلاً إذا اعتبر أنه مهم. (إخلاء المسؤولية: لا أعرف ما يكفي عن العملات المشفرة لفهم الآثار المترتبة على القيام بهذه المنصة المشتركة).

أوراكل ADO.NET

من أين يأتي ASP.NET Core هنا؟ هل تقول فقط إن موفر Oracle لم يتم نقله إلى .NET Core حتى الآن؟

نستخدم Microsoft.Extensions.Logging في جميع تطبيقات سطح المكتب لدينا هذه الأيام - يجب أن تكون عمليات التسجيل المجردة نفسها قيد التنفيذ ، حتى لو لم تكن التطبيقات كذلك.

Microsoft.Extensions. * ستظل على مستوى الشبكة ، لذا فأنت مغطى هناك.

لماذا لا يوجد إعلان / مناقشة؟
أحب ما يفعله فريق aspnet / .net الأساسي ، لكن لدي نفس مخاوفjhurdlow.

يسعدني أن أسمع عن MEL في النقاط الأخرى-

NTLM

هذه فئة واحدة تُستخدم في معظم تطبيقاتنا. إنها تستخدم واجهة برمجة التطبيقات API تافهة للغاية ، وهي أشياء نأمل أن يتم نقلها من الناحية النظرية (لكنها لم تكن كذلك).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

تستخدم قوالب codegen الخاصة بـ asp.net core نظام الإجراء / التوجيه (IFileProvider إلخ) لاكتشاف وحدات التحكم وطرق العرض وما إلى ذلك وملء السقالات الخاصة بنا. نحن لا نستضيف مضيف ويب ASP.NET داخل الاستوديو المرئي ، فقط نتفحص تطبيقات ASP.NET.

تشفير

أظن أنه سيتم نقل الخوارزميات التي نستخدمها ، لكنها لم تكن كذلك بعد. سيبدو كل هذا مختلفًا كثيرًا إذا كانت الفرضية ، مثل ، إعلان عن خطة طويلة الأجل لإسقاط الدعم لـ asp.net-core-on-netfx ومناقشة متى قد يكون ذلك ممكنًا!

وحي

نعم ، سيتم حل هذا الأمر في حالة حدوث منفذ Oracle (بافتراض أنه كامل الميزات وما إلى ذلك).

حالة استخدام أخرى:
يقوم أحد تطبيقاتنا باستيراد البيانات القديمة من تطبيق Access. في الوقت الحالي ، يتم تشغيل عملية الاستيراد على خادم في موقع ويب asp.net الأساسي. يستخدم COM interop لتحميل acedao.dll من محرك accdb / jet القابل لإعادة التوزيع ، ويقرأ الجداول في تجريدات الكيانات الخاصة بنا ، ثم يحفظها في قاعدة بيانات SQL أكثر حداثة.

هذه حالة أخرى من "يمكن أن يكون خارج proc ، ولكن لماذا يجب أن يكون". كنا في الأساس نستخدم AN-C كواجهة أمامية لموقع ويب WebAPI 2 أو شيء من هذا القبيل ، وفي هذه الحالة عدنا إلى هذا الاعتماد على الماضي :(

بشكل عام ، هدفنا هو نقل الغالبية العظمى مما نقوم به إلى .NET Core. نود أكبر قدر ممكن من التشغيل المتداخل لأطول فترة ممكنة أثناء تحريك الأشياء ...

ماهذا الهراء !!! 😨
هل تقول أن ASP.NET Core 2 لن يستهدف Full .NET framework 4.x بعد الآن !!!
لقد بدأنا للتو مشروعًا منذ شهر واحد باستخدام ASP.NET Core 1.1 واستهدفنا .NET 4.6 لأننا نشير إلى بعض Full .NET Lib. وكنا بصدد الترقية إلى ASP.NET Core 2. ولكن ما أسمعه من هذا المنشور ... 😞
انظر ، لقد اخترنا ASP.NET Core بسبب فوائده (DI ، ودمج API و MVC ، ... قوي) ، لذا ، يرجى تقديمه كصديق للتغيير.

لقد بدأنا للتو مشروعًا منذ شهر واحد باستخدام ASP.NET Core 1.1 واستهدفنا .NET 4.6 لأننا نشير إلى بعض Full .NET Lib

ماذا تفعل تلك المكتبات؟ هل قرأت الرد الأولي لـ shanselman https://github.com/aspnet/Home/issues/2022#issuecomment -299536123؟ من الممكن الرجوع إلى بعض مكتبات .NET Framework في .NET Core 2.0 (بافتراض أنها تظل ضمن المجموعة الفرعية من واجهات برمجة التطبيقات).

ماذا تفعل تلك المكتبات؟ هل قرأت الرد الأولي لـ shanselman # 2022 (تعليق)؟ من الممكن الرجوع إلى بعض مكتبات .NET Framework في .NET Core 2.0 (بافتراض أنها تظل ضمن المجموعة الفرعية من واجهات برمجة التطبيقات).

davidfowl نعم لقد قرأت تعليق shanselman ، فنحن نستخدم بعض Libs التي تصنعها الشركة ، وبعض تلك الاستخدامات lib لـ WCF ، كل تلك Libs مستقرة ، وتستهدف .NET 3.5 ، ولا يمكننا لمسها.

سيكون هذا وضعًا شائعًا جدًا. أرغب في معرفة ما إذا كان قد تم جمع أي معلومات (تتبع عن بُعد؟) حول عدد مستخدمي ASP.NET Core الموجودين على .NET Core مقابل .NET Framework حتى الآن.

أنا شخصياً لست عاطفياً بشأن هذا ، لكن بعض الملاحظات:

• يستخدم معظم العملاء الذين لديّ اليوم مجموعة إطار عمل asp.net الأساسية 1.x / لأنهم خائفون من المشاركة في الأشياء الجديدة
• نقول من أرقام تنزيل الحزمة nuget ، اعتماد نواة asp.net ليس رائعًا. بهذه الخطوة سيكون من الأصعب قليلاً بيع شيء لا يبيع جيدًا في الوقت الحالي.
• إنه لأمر رائع أنك حددت عناصر LDAP على أنها فجوة (أعتقد أنني لم أر أي شخص في السنوات العشر الماضية يستخدم هذه المكتبات ولكن ربما هذا أنا فقط). ستكون المشكلة الأكبر هي libs الطرف الثالث. ستكون هذه هي الأسباب الحقيقية لعدم انتقال الأشخاص إلى .net core

هذا الموقف برمته هو مرة أخرى مثال جيد آخر على اتخاذ MS قرارًا دون أي تنبيه مسبق. فقط لأن بعض الأشخاص يتابعون عمليات تسجيل الوصول ، يوجد مؤشر الترابط هذا هنا.

قد أكون مخطئًا ، لكنني اعتقدت أن NET Core الآن تحت إدارة DNF - لذا فإن هذه القرارات لم تعد داخلية بحتة من MS بعد الآن.

تعد عناصر LDAP / AD سببًا في حاجتي للبقاء على رأس net462 في الوقت الحالي. أود أن أذهب تمامًا ، BAM -> NetCore تمامًا ، لكن هذا عيب.

أنا أستخدم أيضًا XML-RPC.net في أحد مشاريعي. إنه يستخدم بعض التفكير الجاد. تذكر ذلك ، ولست متأكدًا مما إذا كان NetCore 2 سيدعمه تمامًا. سآخذ لتجربة محلل قابلية النقل لمعرفة ذلك على وجه اليقين.

أجد أن هذا الموقف برمته محبط بعض الشيء بسبب السرعة والسهولة لقرار مهم مثل هذا يؤثر على مستقبل .NET يمكن أن يحدث بدون أي شفافية ، في اللحظة الأخيرة ، مرة أخرى. تم استثمار الكثير من الطاقة في بيع نظام .NET البيئي الحالي عند الترحيل إلى ASP.NET Core مع الرسائل (حسب فهمي) وهي أن .NET Standard 2.0 سيركز على التوافق وسيكون الإصدار الذي يسد الفجوة مع .NET v4.x لإنتاج منصة .NET متينة ومستقرة يمكن للنظام البيئي الاعتماد عليها أخيرًا. أنا شخصياً لا أعتقد أن .NET Core ستنطلق بالفعل إلا بعد إصدار .NET Standard 2.0 حيث توقعت أن تكون "الأرض المستقرة الموعودة" التي ننتظرها جميعًا - الآن ليس لدي أي فكرة عن ".NET Standard 2.0 "يعني ، ما الذي سيتم تغطيته بالضبط والمكتبات المخطط لها أن تكون .NET Core فقط.

نظرًا لعدم وجود إعلان رسمي سابق ، أو طلب للحصول على تعليقات ، أو استفتاء أو سبب منطقي ، فإن هذا القرار "يبدو" أنه تم تنفيذه بدون مشاركة مجتمعية أو تحليل التأثير على نظام .NET البيئي الحالي ومن المحتمل أن يؤدي إلى تجزئة النظام البيئي بأكمله بالنسبة للكثيرين السنوات القادمة. تؤدي إزالة دعم .NET v4.x إلى إزالة مسار الترحيل السلس للعديد من المؤسسات لتتمكن من ترحيل قواعد الرموز الموجودة لديها إلى نموذج التطوير الجديد لـ ASP.NET. لن يشجعهم ذلك على القفز إلى .NET Core بشكل أسرع ، فهو يمنعهم بشكل فعال من محاولة ذلك ، مما يتسبب في تجزئة هائلة تؤدي إلى كسر النظام البيئي .NET إلى قسمين. لا أرى كيف سينتهي الأمر باختلاف Python 2/3 التي تضررت بشكل لا يمكن إصلاحه بسبب التجزئة التي ما زالت غير قادرة على التعافي منها منذ ما يقرب من عقد من الزمان.

معظم قواعد أكواد .NET الحالية عبارة عن حقل بني يتم تطويره خلف الكواليس بواسطة مطوري .NET "dark matter" ، ولن يكون لدى معظمهم أي فكرة عن اتخاذ هذا القرار نظرًا لأن .NET Core 1.1 يدعم .NET v4.x وكانت الرسائل الخاصة بـ .NET Standard 2.0 تعد بتحسين التوافق. أتوقع رد فعل عنيفًا كبيرًا بمجرد وصول الأخبار وتأثير هذا القرار إلى الوطن أخيرًا. سيشعر العديد من مطوري البرامج الذين كانوا يبيعون اعتماد NET Core داخليًا داخل مؤسستهم بالخيانة نظرًا لأنهم انتقلوا بشكل فعال إلى نظام أساسي مسدود (إذا لم يتمكنوا من الانتقال بشكل كامل إلى .NET Core لأي سبب من الأسباب ) حقيقة قاسية سيحتاجون إلى مواجهتها بعد أن ينجحوا في القرار الهائل بإقناع أصحاب المصلحة في مؤسستهم بالموافقة على الموارد اللازمة لهجرتهم الحالية.

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

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

لماذا لا تجري استطلاعًا على ما يريده مطورو .NET أكثر؟ أي منصة صلبة ومستقرة مصقولة أو منصة "سريعة الحركة" توفر ميزات جديدة بشكل أسرع؟ أتفهم أنه سيتطلب جهدًا أقل بكثير حتى لا تقلق بشأن ميزات النقل الخلفي إلى .NET v4.x ولكن سيكون من المفيد أن يكون لديك إصدار من ASP.NET Core يركز بشكل أساسي على تقديم نظام أساسي متوافق ثابت مع فترة طويلة المصطلح الذي يمكن تشغيله على .NET v4.x أو .NET Core.

هل أبحرت هذه السفينة أم أن هناك خيارًا للاحتفاظ بـ ASP.NET Core 2.0 كما هو؟ على سبيل المثال ، مع معظم المكتبات والأفكار المجردة التي يغطيها .NET Standard 2.0 ثم في إصدار ASP.NET Core 3.0 التالي ، أعلن أن النظام الأساسي التالي سيكون .NET Core فقط؟ سيسمح ذلك للمؤسسات بالاستمرار في المضي قدمًا واعتماد ASP.NET Core 2.0 والسماح لبقية النظام البيئي باللحاق بالركب ، باستخدام أدوات ومكتبات مستقرة ومدعومة جيدًا ، مع وجود تقسيم نظيف من حيث منصة .NET Core فقط / تبدأ الميزات.

من الممكن الرجوع إلى بعض مكتبات .NET Framework في .NET Core 2.0 (بافتراض أنها تظل ضمن المجموعة الفرعية من واجهات برمجة التطبيقات).

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

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

أتمنى أن تكونوا أقل رغبة في تشعب قاعدة المستخدمين لديك.

وجهة نظري عند إنشاء مكتبة هي تسهيل استخدامها قدر الإمكان ، لأكبر عدد ممكن من الأشخاص ، في أكبر عدد ممكن من الأماكن. إنه ألم في الرقبة (ابحث عن توجيهات المترجم #if في Newtonsoft.Json وستحصل على أكثر من 1300 نتيجة) ولكن "إنها تعمل فقط" هي نقطة بيع قوية.

لماذا لا تجري استطلاعًا على ما يريده مطورو .NET أكثر؟ أي منصة صلبة ومستقرة مصقولة أو منصة "سريعة الحركة" توفر ميزات جديدة بشكل أسرع؟ أتفهم أنه سيتطلب جهدًا أقل بكثير حتى لا تقلق بشأن ميزات النقل الخلفي إلى .NET v4.x ولكن سيكون من المفيد أن يكون لديك إصدار من ASP.NET Core يركز بشكل أساسي على تقديم نظام أساسي متوافق ثابت مع فترة طويلة المصطلح الذي يمكن تشغيله على .NET v4.x أو .NET Core.

سؤال حقيقي ، يدعم ASP.NET Core 1.x حاليًا .NET Framework و .NET Core. لنفترض أنها كانت النظام الأساسي الثابت الذي ذكرته أعلاه ، أننا قمنا بإصلاح الأخطاء ودعمنا في كلتا فترتي التشغيل ولكننا لم نحصل على المزيد من الميزات. هل سيكون ذلك كافيا؟

يعد كل من ASP.NET Core و .NET Core بمثابة منصات غنية بالميزات سريعة الحركة لـ .NET في هذه المرحلة. إنه إصدار من .NET غير مرتبط بأي نظام تشغيل ويمنحنا المرونة اللازمة للابتكار بسرعة والإصدار بشكل أسرع.

هل أبحرت هذه السفينة أم أن هناك خيارًا للاحتفاظ بـ ASP.NET Core 2.0 كما هو؟ على سبيل المثال ، مع معظم المكتبات والأفكار المجردة التي يغطيها .NET Standard 2.0 ثم في إصدار ASP.NET Core 3.0 التالي ، أعلن أن النظام الأساسي التالي سيكون .NET Core فقط؟ سيسمح ذلك للمؤسسات بالاستمرار في المضي قدمًا واعتماد ASP.NET Core 2.0 والسماح لبقية النظام البيئي باللحاق بالركب ، باستخدام أدوات ومكتبات مستقرة ومدعومة جيدًا ، مع وجود تقسيم نظيف من حيث منصة .NET Core فقط / تبدأ الميزات.

نحن دائمًا منفتحون على التعليقات ولم يتم شحن ASP.NET Core 2.0 بعد. إذا كان ASP.NET Core 3.0 هو الإصدار الذي أسقط .NET Framework ، فهل سيؤدي ذلك إلى تحسين الأمور؟ إذا نظرت إلى بعض التعليقات الواردة من gulbanana و ikourfaln ، فهناك تقنيات من المحتمل ألا يتم نقلها أبدًا وبالتالي لن تعمل أبدًا على .NET Core ، ألا يعني هذا دعم .NET Framework إلى حد كبير إلى الأبد؟ ألن نجري هذه المناقشة نفسها بعد عام من الآن؟ ربما بحلول ذلك الوقت ، سيكون النظام البيئي أو المكتبات التي تدعم NET Core أكبر حجمًا بحيث يكون لها تأثير أقل؟ ماذا عن مكتبات المؤسسات التي لن يتم تحديثها أبدًا (أو حيث تم فقد كود المصدر)؟ هل سيتغير هؤلاء في عام؟

وجهة نظري عند إنشاء مكتبة هي تسهيل استخدامها قدر الإمكان ، لأكبر عدد ممكن من الأشخاص ، في أكبر عدد ممكن من الأماكن. إنه ألم في الرقبة (ابحث عن توجيهات المترجم #if في Newtonsoft.Json وستحصل على أكثر من 1300 نتيجة) ولكن "إنها تعمل فقط" هي نقطة بيع قوية.

لا توجد إهانة JamesNK ولكن JSON.NET هو محلل JSON وفي الغالب حزمة واحدة (أعرف أن هناك عددًا قليلاً). يحتوي ASP.NET Core على> 200 حزمة.

بلا إهانة ولكن أنا رجل واحد أعمل بدوام جزئي. مشكلتك أصعب ولكن لديك موارد أكثر بشكل كبير.

بعد قراءة هذا والبحث في التبعيات التي لدينا ، أنا أقل اقتناعًا بأن هذه فكرة جيدة.

كما هي الخطط ، لا يمكننا نقل أي من تطبيقاتنا إلى netstandard / netcoreapp حتى يتوفر System.DirectoryServices ( إصدار CoreFX # 2089 هنا ). لذلك بينما يمكننا نقل إلى ASP.NET Core 1.x ، لا يمكننا الانتقال إلى 2.0. بالنظر إلى التطبيقات هنا: Opserver ، Stack Overflow نفسها ، تطبيقاتنا الداخلية ... لن يكون أي شيء جاهزًا لأن الإصدار 2.0 جاهز ليكون في هذه المرحلة. وفقًا للوقوف هذا الأسبوع ، ستستمر الأمور المهمة مثل DirectoryServices في إصدار 2.x لاحقًا.

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

خلاصة القول هي أننا إذا احتجنا إلى مصادقة AD (جزء كبير من النظام الأساسي) ، فقد تم التخلي عننا في السطر 1.x. هذا هو المكان الذي كنت أتجه إليه مع تطبيقاتنا ... ولكن إذا كان هذا هو الاتجاه ، فلا فائدة من بذل الجهد هنا حتى تتوفر القطع التي أحتاجها في الوجهة.

إذا كان بإمكاننا قول هذه الأشياء الهامة مثل System.DirectoryServices ، System.Drawing ، والعناصر المهمة الأخرى التي يحتاجها الناس ستكون جاهزة مع ASP.NET Core 2.0 ، فإن رأيي يتغير كثيرًا. إذا كانت فكرة لاحقة (كما تظهر الجداول الحالية) ، فالرجاء الاستمرار في دعم .NET Framework حتى يتم ذلك.

التحرك بسرعة شيء عظيم. أحبها. أنا أقوم بتشغيل ألفا في الإنتاج الآن. لكن لا شيء من ذلك مهم إذا لم ينجح في حالة الاستخدام الخاصة بك في المقام الأول.

الشيء الوحيد الذي أعاني منه شخصيًا هو "النظام الأساسي الثابت" مقابل "الميزات الجديدة". من ناحية ، نريد أن تكون المنصة مستقرة وموثوقة ومتوافقة ، ومن ناحية أخرى لا أحد يريد البقاء على 1.x لأنه لا يحتوي على ميزات 2.x. هل هناك ميزات رائعة في ASP.NET Core 2.x تجذب الأشخاص في هذا الاتجاه أم أنها مجرد حقيقة أن لدينا ميزات أكثر مما كانت لدينا في 1.x (لأنها جديدة ولامعة)؟

إذا كان هذا هو الأخير ، فهل هؤلاء الناس يهتمون بالاستقرار؟ إذا كانت الإجابة بنعم ، فلماذا لا يكون ASP.NET Core 1.x كافياً؟

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

موافق ، ولكن في رأيك ، كيف يرتبط ذلك بـ ASP.NET Core 2.x إسقاط دعم .NET Framework؟ عندما تأتي المزيد من التبعيات عبر الإنترنت ، فإنها ستعمل في كل مكان بمعنى ما ، مع تقدم النظام الأساسي ، ستحصل مجموعة واسعة من أوقات التشغيل على الفوائد. ستتمكن جميع إصدارات تطبيقات ASP.NET Core فجأة من الاستفادة من هذه الميزات.

إذا كان هذا هو الأخير ، فهل هؤلاء الناس يهتمون بالاستقرار؟ إذا كانت الإجابة بنعم ، فلماذا لا يكون ASP.NET Core 1.x كافياً؟

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

هل هناك ميزات رائعة في ASP.NET Core 2.x تجذب الأشخاص في هذا الاتجاه أم أنها مجرد حقيقة أن لدينا ميزات أكثر مما كانت لدينا في 1.x (لأنها جديدة ولامعة)؟

الدعم - هذا ما ندفع من أجله.

إذا كانت الإجابة بنعم ، فلماذا لا يكون ASP.NET Core 1.x كافياً؟

لأن الدعم ينتهي بعد حوالي عام من الإصدار (وفقًا لسكوت أعلاه). وبالكاد أنتهي من نقل Stack Overflow بحلول ذلك الوقت.

كيف يرتبط ذلك بـ ASP.NET Core 2.x إسقاط دعم .NET Framework؟

لأن المكتبات التي يجب أن أمتلكها ليست موجودة. وأنا لا أعرف متى سيكونون كذلك. لذلك سأكون عالقًا في 1.x ولدي قنبلة موقوتة حتى ينتهي الدعم. هل سيكون لدي الوقت الكافي للتنقل من 1.0 إلى 2.x (أو 3.x) قبل انتهاء الدعم؟ على الاغلب لا.

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

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

وجهة نظري حاليًا هي: هناك نظام أساسي جديد يعمل حتى حوالي يوليو 2018. بعد ذلك: لا أعرف شيئًا ، آمل فقط أن يتوفر ما أحتاجه netstandard / netcoreapp بحلول ذلك الوقت. وآمل أن يكون لدي الوقت الكافي للتنقل قبل انتهاء الدعم. على الرغم من ذلك ، لم يتم الدفع لي مقابل الأمل ، فقد دفعت لي لاتخاذ قرارات النظام الأساسي لشركتنا ، و ASP.NET Core هو رهان سيء (بالنسبة لنا) مع هذا التغيير ولا يوجد تاريخ لإصدار يعمل.

دعني أقدم ملخصًا من سطر واحد: بدون دعم .NET Full Framework ، لا يقدم ASP.NET Core نظامًا أساسيًا مدعومًا لحالات الاستخدام الخاصة بنا على مدار العامين المقبلين.

كإصدار قصير ، هذا هو:

الأولوية 1: هذا يجب أن يعمل على net461 ، بغض النظر عن ifdefs ، فإن perf موجودة.
الأولوية 2. إذا كان بإمكانك جعله أسرع بمعدل 10 مرات على .NET Core 2.0 ، فهذا رائع. إنه سبب عظيم للأشخاص لاختيار النظام الأساسي و / أو الهجرة عندما يستطيعون ذلك.

الشيء الرئيسي هنا هو أنه بالنسبة للدعم طويل المدى ، لا يزال يتعين عليه العمل على إطار العمل الكامل ، حتى لو كان أبطأ هناك.

الأولوية 1: هذا يجب أن يعمل على net461

وإذا كان NET Core متوافقًا تمامًا مع net461 (في حدود المعقول) ؛ لذلك فإن أي شيء مكتوب لـ net461 يعمل على Core ؛ هل سيكون ذلك بعد ذلك على ما يرام؟

بشكل أساسي ، في هذه المرحلة ، يكون لديك نظام أساسي أكثر استقرارًا من net4x حيث يمكنك القيام بذلك جنبًا إلى جنب ومكتفٍ ذاتيًا (لمسة x-plat أيضًا). في حين أن net461 يحتوي على تغييرات الجهاز بالكامل إلى 4.6.1 و 4.6.2 و 4.7 وما إلى ذلك

من الواضح أن بعض الأشياء لن تنجح أبدًا ؛ مثل الثقة الجزئية - لكن ذلك لم ينجح أبدًا على أي حال.

سؤال حقيقي ، يدعم ASP.NET Core 1.x حاليًا .NET Framework و .NET Core. لنفترض أنها كانت النظام الأساسي الثابت الذي ذكرته أعلاه ، أننا قمنا بإصلاح الأخطاء ودعمنا في كلتا فترتي التشغيل ولكننا لم نحصل على المزيد من الميزات. هل سيكون ذلك كافيا؟

أرغب في رؤية إصدار LTS من ASP.NET Core 2.0 مثل Ubuntu / Redhat مع إصدارات LTS التي يدعمونها لأكثر من 5 سنوات. سيوفر هدفًا متوافقًا قويًا يمكن لبقية النظام البيئي أن يكون لديه الثقة للالتزام بتبنيه.

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

ألن نجري هذه المناقشة نفسها بعد عام من الآن؟ ربما بحلول ذلك الوقت ، سيكون النظام البيئي أو المكتبات التي تدعم NET Core أكبر حجمًا بحيث يكون لها تأثير أقل؟ ماذا عن مكتبات المؤسسات التي لن يتم تحديثها أبدًا (أو حيث تم فقد كود المصدر)؟ هل سيتغير هؤلاء في عام؟

في عالم مثالي ، سوف يدعم كل من .NET v4.x و .NET Core ASP.NET Core في المستقبل المنظور وهي فقط ميزات .NET Core جديدة فقط والتي ستكون متاحة فقط في حزم .NET Core فقط. ولكن إذا كان MS مصممًا على ترك .NET 4.x خلفك ، فسيكون إصدار ASP.NET 2.0 LTS قبل أن تنفصل رسميًا هو أفضل شيء تالي. حسب التعريف ، لا أحد يعتمد على ميزات جديدة غير موجودة حتى الآن ، لذا لن يضطر أي شخص للترقية إلى .NET Core-only v3.0.

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

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

أرى نقطتين / خيطين رئيسيين يخرجان من هذه المحادثة:

1. طلب دعم .NET desktop في vnext. (هذه 99٪ من الردود هنا)
2. عدم التشاور مع المجتمع حول مثل هذا القرار المهم. (الردود 2 أو 3 هنا).

TL ؛ DR ؛

• هل يمكننا أن نكون أكثر انفتاحًا مع التغييرات الكبيرة المهمة في vnext.
• خصص بعض الوقت لبعض RFC من المجتمع حول هذه التغييرات vnext.

ذكر mythz ذلك بشكل جيد في الجملة الافتتاحية له (في هذه المرحلة) ، أحدث تعليق ثانٍ:

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

هذا ما أصابني شخصيًا حقًا وأحب بعض الردود / التعليقات الرسمية من الأشخاص المناسبين في MS الذين يجرون هذه المكالمات. "نحن" حول هذا المجتمع لفترة طويلة - وجوه مألوفة وأسماء مألوفة ومن العدل أن نقول - كلنا نتبع نفس الأهداف الإيجابية. حتى أنني سأستمر في القول "نحن" عائلة كبيرة جدًا وممتدة ، وكلها ثآليل.

لذلك أشعر أنه مع الاتجاه الجديد الذي اتخذته MS (OSS-all-the-Things ، إلخ) ومع بعض سلاسل mega-uber-.NET الأخيرة في آخر 12/18 شهرًا (اقرأ: التعلم من تجارب المناقشة المجتمعية تلك ) ... أن "نحن" جميعًا في هذا معًا وأن بعضًا من هذه الأشياء الكبيرة Really-Big-Things ™ ️ ستتم مناقشتها في العلن ، في وقت مبكر.

لذا - هل يمكننا من فضلك التحدث عن بعض هذه القرارات الكبيرة في العلن ، قبل توزيع الورق؟ الحصول على بعض التشاور والمناقشة الإيجابية المجتمع؟

ملاحظة: أنا أقبل أن هذا المشروع (المشاريع) ليست ديمقراطية وأن _القرارات_ تم اتخاذها من قبل MS. لا مشاكل. أنا لا أنتقد ذلك. أنا أتحدث عن طريقة الخطوات السابقة لذلك. أيضًا ، أنا لا أطلب _ كل شيء _ ليتم طرحه في RFC ، إلخ. فقط عنصر التذكرة الرئيسي الفردي - مثل ما بدأ هذا الموضوع.

ولكن إذا كان MS مصممًا على ترك .NET 4.x خلفك ، فسيكون إصدار ASP.NET 2.0 LTS قبل أن تنفصل رسميًا هو أفضل شيء تالي. حسب التعريف ، لا أحد يعتمد على ميزات جديدة غير موجودة حتى الآن ، لذا لن يضطر أي شخص للترقية إلى .NET Core-only v3.0.

أنا لا أفهم. لا أحد يعتمد على الميزات الموجودة في ASP.NET 2.0 حتى الآن إما لأنها غير موجودة في أي إصدار. إذن أليس ASP.NET Core 1.x هذا الإصدار؟ إنه يعمل على إطار كامل و Core 1.0 و core 2.0 ويمكن أن يكون بمثابة نقطة انطلاق لـ ASP.NET Core 2.x؟

تضمين التغريدة

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

نعم ، لكن من الصعب حقًا ضمان نفس المستوى من الجودة عندما يكون .NET Framework هو المستقر الكبير المدعوم والمرتبط بمكون نظام التشغيل. كما قال terrajobst ، سيتم بالتأكيد تدبير بعض الأشياء في وقت ما ولكن البعض الآخر سوف يحتاج إلى معرفة. الحقيقة هي أن ASP.NET Core يعمل بشكل أفضل على .NET Core لأن لدينا القدرة على تسريع المكدس بالكامل مرة واحدة. حتى الآن ، هناك اختلافات كبيرة في الأداء بين فترتي التشغيل ولم نأخذ بعد التبعيات على واجهات برمجة التطبيقات الجديدة بسبب دعم .NET Framework. بينما نمضي قدمًا ، سنضيف واجهات برمجة تطبيقات جديدة قد تظهر أو لا تظهر على .NET Framework في وقت ما ولا نريد أن نعيد السرعة بوتيرة وقت التشغيل الأكثر استقرارًا وأبطأ حركة (.NET Framework).

تضمين التغريدة

لأن الدعم ينتهي بعد حوالي عام من الإصدار (وفقًا لسكوت أعلاه). وبالكاد أنتهي من نقل Stack Overflow بحلول ذلك الوقت.

لست متأكدًا من أن هذا دقيق تمامًا. عندما يكون الإصدار 2.0 متاحًا ، فسيظل 1.1 مدعومًا. إذن ما هو هذا "الدعم" الذي تتحدث عنه؟ هل تقصد دعمًا مدفوعًا أم تقصد أننا سنصلح المشكلات عند ظهورها؟

لأن المكتبات التي يجب أن أمتلكها ليست موجودة. وأنا لا أعرف متى سيكونون كذلك. لذلك سأكون عالقًا في 1.x ولدي قنبلة موقوتة حتى ينتهي الدعم. هل سيكون لدي الوقت الكافي للتنقل من 1.0 إلى 2.x (أو 3.x) قبل انتهاء الدعم؟ على الاغلب لا.

كما قلت ، ستضيء هذه المكتبات بغض النظر عن إصدار .NET Core. أعتقد أن ما تقوله هو أنك تريد استخدام أحدث إصدار من ASP.NET Core (أيًا كان ذلك) وتريد دعمه على .NET Framework حتى تتوفر مكتبات كافية على .NET Core بحيث يكون المنفذ من السهل بالنسبة لك سيناريو محدد.

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

كيف تؤثر إصدارات ASP.NET Core على ذلك؟ إذا أسقطنا دعم .NET Framework في 3.0 (كما يبدو أن الناس يتهربون من هذا الموضوع) ، ألن تكون في نفس الطريق المسدود بغض النظر؟ سيكون لديك تطبيق ASP.NET Core 2.0 الخاص بك قيد التشغيل على إطار العمل لمدة عام وعندما يتم إصدار 3.0 ، لن تتمكن من الترقية. ستكون قادرًا على القيام بذلك على أي حال باستخدام ASP.NET Core 1.1.x الذي يعمل على .NET Framework ويكون مدعومًا حتى عندما يكون ASP.NET Core 2.0 خارج.

وجهة نظري حاليًا هي: هناك نظام أساسي جديد يعمل حتى حوالي يوليو 2018. بعد ذلك: لا أعرف شيئًا ، آمل فقط أن يكون ما أحتاجه متاحًا على netstandard / netcoreapp بحلول ذلك الوقت. وآمل أن يكون لدي الوقت الكافي للتنقل قبل انتهاء الدعم. على الرغم من ذلك ، لم يتم الدفع لي مقابل الأمل ، فقد دفعت لي لاتخاذ قرارات النظام الأساسي لشركتنا ، و ASP.NET Core هو رهان سيء (بالنسبة لنا) مع هذا التغيير ولا يوجد تاريخ لإصدار يعمل.

إذن سنة أخرى هي وقت كافٍ للجميع؟ هذا ليس الشعور الذي أحصل عليه من هذا الموضوع.

الأولوية 1: هذا يجب أن يعمل على net461 ، بغض النظر عن ifdefs ، فإن perf موجودة.
الأولوية 2. إذا كان بإمكانك جعله أسرع بمعدل 10 مرات على .NET Core 2.0 ، فهذا رائع. إنه سبب عظيم للأشخاص لاختيار النظام الأساسي و / أو الهجرة عندما يستطيعون ذلك.

الشيء الرئيسي هنا هو أنه بالنسبة للدعم طويل المدى ، لا يزال يتعين عليه العمل على إطار العمل الكامل ، حتى لو كان أبطأ هناك.

السبب الوحيد الذي يجعل .NET Framework يعمل بشكل جيد كما هو الحال اليوم هو أننا كنا نعتزم دعمه. لم يأت مجانًا ، إنه ليس "فقط أسرع في النواة" ، كان علينا تصميم النظام عن قصد حتى يكون من الممكن تشغيله على .NET Framework. على الرغم من أنك لا تراها حتى الآن ، فإن فجوة الميزات ستزداد بين الاثنين بمجرد أن نقرر (وقررنا) أن نأخذ التبعيات على واجهات برمجة التطبيقات غير الموجودة في .NET Framework حتى الآن. يمكننا أن نفعل ما يقوله PinpointTownes والبدء في رمي NotSupportedException عندما تظهر هذه الثغرات في الميزات ولكن IMO هذه تجربة سيئة للغاية.

لقد أنفقنا ميزانية تطوير كبيرة على نقل تطبيق ASP.net MVC5 الخاص بنا إلى إطار عمل ASP.net الأساسي الكامل لجعله يعمل بشكل جيد مع Azure Service Fabric. كان المشروع بأكمله متعدد الأشهر حيث كان هناك عدة أسابيع مخصصة لنقل تطبيق الويب الخاص بنا (وبصراحة ، المصارعة مع أدوات VS2015 المحرجة).

السبب الوحيد الذي نجح هو أن إطار العمل الكامل كان مدعومًا ، نظرًا لأننا نقوم حاليًا بتشغيل SignalR على ASP.net الأساسية ( لإحباطdavidfowl ). بقدر ما أستطيع أن أقول ، لا يزال SignalR غير مدعوم على Asp.net Core؟

ثم قضينا أسبوعًا أو نحو ذلك في الانتقال إلى أدوات VS2017 الجديدة. بخير.

_ لاحظ أنه حتى هذه اللحظة لا توجد تحسينات على المنتج على الإطلاق ، إنه مجرد تعديل شكل الكود ليناسب متطلبات النظام الأساسي والأدوات لـ Microsoft.

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

أولاً ، احصل على كل شيء يحمل علامة Microsoft التجارية والذي يستخدمه الأشخاص في إطار العمل الكامل الأساسي لـ ASP.net والذي يعمل حاليًا على ASP.net فقط. ثانيًا ، اكتشف ما الذي يمنع النظام البيئي من اعتماد ASP.net الأساسي كما هو مطلوب (إن وجد). بعد ذلك ، وبعد ذلك فقط ، قم بإسقاط دعم Netfx كما تتم مناقشته.

يمكننا أن نفعل ما يقوله PinpointTownes والبدء في طرح NotSupportedException عندما تظهر هذه الثغرات في الميزات ولكن IMO هذه تجربة سيئة للغاية.

هذا ليس بالضبط ما قلته: عند الانتقال إلى الترجمة المتقاطعة ، يجب أن يكون ifdefs الخيار المفضل بالتأكيد لاستبعاد واجهات برمجة التطبيقات غير المتوفرة على نظام أساسي معين ، ولكن إذا كان يجب أن يكون لديك توقيع واجهة برمجة التطبيقات هذا في الجمهور لأي سبب من الأسباب عقد ، ثم يمكنك الذهاب مع NotSupportedException .

أنا لا أفهم. لا أحد يعتمد على الميزات الموجودة في ASP.NET 2.0 حتى الآن

أتوقع أن معظم المطورين ينتظرون NET Standard 2.0 الثابت والمتوافق بدرجة عالية والذي تدعمه تبعياتهم قبل أن يلتزموا بالترحيل إلى ASP.NET Core. لن يرغبوا في استخدام .NET Core 1.1 الآن مدركين أنه قد تم تحديثه في EOL وأن MS ليس لديها تاريخ جيد في تقديم دعم طويل المدى لأي إصدار قديم من DNX / .NET Core. إذا كان هناك إصدار LTS مستقر للغاية ومتوافق للغاية يمكن لبقية النظام البيئي اعتماده بأمان ، فيجب أن يكون لدى المؤسسات كل ما تحتاجه لتشغيل أنظمتها عليه ولن يشعروا بأنهم ملزمون بالترقية إلى .NET Core vNext حيث سيكون لديهم كل شيء لديهم تحتاج إلى الإصدار 2.0 وعندما يحين الوقت ، سيكون من الأسهل كثيرًا التخطيط لترحيلهم من ASP.NET Core 2.0 / .NET v4.6 إلى إصدار .NET Core فقط في المستقبل.

تضمين التغريدة

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

موافق على كل شيء هناك ولكني لا أرى كيف يؤثر هذا القرار على أي شيء قلته. أريد كل هذه الأشياء نفسها 👍.

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

صحيح ، أليس هذا ASP.NET Core 1.x؟ إذا تم تمديد الدعم في 1.x ، ألن يكون ذلك كافياً؟ يمكننا فقط التأكد من أن ASP.NET Core 1. وهو netstandard 1.x يعمل على .NET Core 2.0 (وهو موجود بالفعل) ودعم ذلك لمدة عام آخر أو نحو ذلك.

هذا ليس بالضبط ما قلته: عند الذهاب مع التجميع المتقاطع ، يجب أن تكون ifdefs هي الخيار المفضل بالتأكيد لاستبعاد واجهات برمجة التطبيقات غير المتوفرة على نظام أساسي معين ، ولكن إذا كنت بحاجة لأي سبب من الأسباب إلى الحصول على توقيع API هذا في العقد العام ، فيمكنك اذهب مع NotSupportedException.

أنا لا أتحدث حتى عن فضح API العام. أنا أتحدث عن واجهات برمجة التطبيقات التي نحتاج إلى الاتصال بها والتي لن تكون موجودة في معيار الشبكة. #ifdefs لا تساعد هنا. سوف نرمي فقط كلما زادت الفجوات.

davidfowl أسئلة صالحة تمامًا - إجابات:

هل تقصد دعمًا مدفوعًا أم تقصد أننا سنصلح المشكلات عند ظهورها؟

إصلاحات نشطة للمشكلات - هل سيتلقى 1.x إصلاحات لجميع الأشياء التي نكسرها ، أم سيتم إخبارنا بالترقية للإصلاح في بعض الحالات؟ (ملاحظة: هذه ترقية لا يمكننا القيام بها حتى تكون مكتباتنا مثل DirectoryServices موجودة ... وحتى إذا لم نستطع أن تكون قريبة من كونها مجانية أو رخيصة ، فمن المحتمل أن تكون أشهر على الأقل). نحن كبار ، نحن سريعون ، سنجد فواصل في الإطار. لدينا لكل إصدار رئيسي وثانوي لسنوات. الدعم أمر بالغ الأهمية بالنسبة لنا.

أعتقد أن ما تقوله هو أنك تريد استخدام أحدث إصدار من ASP.NET Core

كلا ، أريد إصدارًا يعمل ومسارًا للمضي قدمًا. مع 1.x ، لدينا النصف الأول فقط. حتى هذه القضية ، كان النوع الثاني يفترض.

كيف تؤثر إصدارات ASP.NET Core على ذلك؟

لأنك إذا أسقطت الدعم لإطار العمل الكامل ، فنحن مضطرون لإجراء تغيير كبير للبقاء في الدعم.

إذا أسقطنا دعم .NET Framework في 3.0 (كما يبدو أن الناس يتهربون من هذا الموضوع) ، ألن تكون في نفس الطريق المسدود بغض النظر؟

يمكن؟ النقطة المهمة هي وجود تكافؤ في حالات الاستخدام قبل إجراء الغوص. إنها مهنتي ، لا يمكنني أن أخبر شركتنا بالقفز عندما لا يدعمنا الجانب الآخر. سيكون هذا مجرد تصرف غير مسؤول من جانبي. إذا كانت حالات الاستخدام الخاصة بنا مدعومة في الإطار الزمني 2.x ، فسيكون هناك مسار واضح للمضي قدمًا وسيكون المراهنة على ASP.NET Core أكثر أمانًا.

إذن سنة أخرى هي وقت كافٍ للجميع؟

الطول المطلق للوقت لا يهم حقًا - يجب أن يكون توافق حالة الاستخدام + الوقت (IMO). إذا نجحت حالات الاستخدام لدينا اليوم (على سبيل المثال ، AD المصادقة) ، فعندئذٍ تكون سنتين كافية ، نعم. لكن هذا ليس هو الحال حاليًا ، لذا فإن الاتفاق على أن نقطة زمنية عشوائية من الآن على ما يرام ، في أفضل الأحوال ، سابق لأوانه.

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

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

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

بصفتي قائدًا معماريًا / منصة ، يجب أن أقرر الرهانات التي نضعها. حاليا ، هذا رهان سيء. عندما يدعمك الإصدار 1 ولكن الإصدار 2 لا يدعمك ولكن نأمل أن يحدث في يوم من الأيام ، فهذه مقامرة سيئة حقًا يمكن تحقيقها مع وقت ومال الآخرين. على الأقل بالنسبة لنا ، اخترنا .NET للميزات والنظام البيئي والدعم. حاليًا ، في الكلمة الجديدة ، انتقلنا من كل هؤلاء الثلاثة إلى 1. النظام البيئي ليس موجودًا بعد (سطح واجهة برمجة التطبيقات ، libs) ، والدعم أقصر بكثير مما اعتدنا عليه ، بدون أي مسار ترقية مضمون و مقدار الوقت غير معروف للقيام بذلك.

تضمين التغريدة

السبب الوحيد الذي نجح هو أن إطار العمل الكامل كان مدعومًا ، نظرًا لأننا نقوم حاليًا بتشغيل SignalR على ASP.net الأساسية ( لإحباطdavidfowl ). بقدر ما أستطيع أن أقول ، لا يزال SignalR غير مدعوم على Asp.net Core؟

حتى SignalR 2 غير مدعوم في ASP.NET Core (على الرغم من أن الناس قاموا باختراقه لجعله يعمل). لا يزال SignalR قيد التطوير ولن يخرج مع ASP.NET Core 2.0 ، بل سيأتي لاحقًا.

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

هل هناك ميزات تحتاجها في ASP.NET Core 2.0؟ أم أنك تتكهن فقط أنك ستحتاج في النهاية إلى الترقية إلى ASP.NET Core التالي وفي هذه المرحلة لن تعمل الأشياء على .NET Framework؟

أولاً ، احصل على كل شيء يحمل علامة Microsoft التجارية والذي يستخدمه الأشخاص في إطار العمل الكامل الأساسي لـ ASP.net والذي يعمل حاليًا على ASP.net فقط. ثانيًا ، اكتشف ما الذي يمنع النظام البيئي من اعتماد ASP.net الأساسي كما هو مطلوب (إن وجد). بعد ذلك ، وبعد ذلك فقط ، قم بإسقاط دعم Netfx كما تتم مناقشته.

كجزء من netstandard 2.0 ، تم إنجاز الكثير من العمل لتحديد واجهات برمجة التطبيقات المهمة لإعادتها بحيث تكون المكتبات التي تستهدف .NET Framework متوافقة في معظمها مع النظام الثنائي. بالطبع هناك مناطق لن تعمل مثل WCF و WPF وما إلى ذلك ، لكنها ستساعد كما أجرينا بعض الأبحاث وتقريبًا 60٪ من المكتبات متوافقة مع واجهة برمجة تطبيقات netstandard 2.0 (صححني إذا كنت مخطئًا في هذا الرقم terrajobst) وقد يعمل فقط على .NET Core 2.0.

صحيح ، أليس هذا ASP.NET Core 1.x؟ إذا تم تمديد الدعم في 1.x ، ألن يكون ذلك كافياً؟

توقعت أن يكون .NET Standard 2.0 هو النظام الأساسي المستقر الذي يربط بين التوافق مع .NET 4.x لذا فمن المنطقي أن يكون دعم LTS قريبًا من ذلك. لا أحد يتوقع أن يكون 1.1 / .NET v4.x في منتصف إصدار EOL لذا سيكون من المحترم الإعلان عن LTS على أحدث إصدار عند إصداره ، وليس سحب دعم .NET 4.x قبل إصداره ، لا- يقوم المرء بعمل LTS بأثر رجعي للإصدارات القديمة من هذا القبيل.

أعلم أننا نحتفظ بحزم NET Core الخاصة بنا في حزم منفصلة *.Core حتى نتمكن من البقاء في إيقاع إصدار منفصل يتبع أحدث إصدار من .NET Core في اللحظة التي ندمج فيها في حزم NuGet الرئيسية ، فهذا يعني نحن ملتزمون بإصدار مستقر ندعمه رسميًا ، لذلك نحتاج إلى أن نكون واثقين جدًا من أن لدينا إصدارًا يمكننا دعمه للمستقبل المنظور والذي توقعته من .NET Standard 2.0 ، وليس .NET Standard الحالي 1.1 / 1.3 / 1.6 مزيج. أتذكر أنه كان هناك أيضًا وقت كان فيه إصدار فجوة توقف 1.7 / 8 والذي سيكون غير متوافق مع الإصدار 2.0 الذي يكسر توقعات الإصدار القياسي لـ .NET والتي لا تشير إلى نظام أساسي مستقر.

لقد كنت أتوقع بفارغ الصبر أن يكون الهدف من .NET Standard 2.0 هو توفير مساحة السطح المتوافقة للغاية والثبات الذي تشتد الحاجة إليه.

حتى SignalR 2 غير مدعوم في ASP.NET Core (على الرغم من أن الناس قاموا باختراقه لجعله يعمل). لا يزال SignalR قيد التطوير ولن يخرج مع ASP.NET Core 2.0 ، بل سيأتي لاحقًا.

لست متأكدًا من قصدك لهذا البيان ، لكنني أشعر أنه يعزز مخاوفي.

هل هناك ميزات تحتاجها في ASP.NET Core 2.0؟ أم أنك تتكهن فقط أنك ستحتاج في النهاية إلى الترقية إلى ASP.NET Core التالي وفي هذه المرحلة لن تعمل الأشياء على .NET Framework؟

أريد الانتقال إلى netstandard2 في وقت ما لأسباب. سأحتاج إلى الانتقال لنقل تطبيق الويب الخاص بي إلى asp.net core 2 لذلك ، أليس كذلك؟

كجزء من netstandard 2.0 ، تم إنجاز الكثير من العمل لتحديد واجهات برمجة التطبيقات المهمة لإعادتها بحيث تكون المكتبات التي تستهدف .NET Framework متوافقة في معظمها مع النظام الثنائي. <...>

بالتأكيد ، وأنا أحب ما يتم إجراؤه باستخدام netstandard ، ولكن إذا كان هناك شيء مفقود من netstandard ، يمكنك العمل حوله لأنه يمكنك استهداف إطار عمل كامل في التطبيقات التي تحتاج إليه. لدينا الآن عدد قليل من مكتبات netstandard 1.3 (مصدرنا) المشتركة عبر: Xamarin.iOS و Xamarin.Android و net46 و Asp.net core 1.1 - لأننا نستطيع أن نضيف وظائف مفقودة في معيار الشبكة مع إطار عمل محدد يستهدف المكتبات ، بما في ذلك net46 في تطبيق الويب الأساسي asp.net الخاص بنا.

السبب _ الوحيد _ لامتلاكنا هذه المكتبات القياسية هو أننا نحتاج إلى نقل تطبيق الويب الضخم الخاص بنا (كما ذكرت سابقًا). أرغب في عدم الاضطرار إلى توسيع قاعدة الشفرة الخاصة بمنصتنا لأنظمة أساسية أخرى ، وبدلاً من ذلك استمر في الارتقاء في سلسلة netstandard. لا أريد حقًا أن أكون عالقًا في معيار الشبكة 1.3 لأنه لا يوجد مسار للانتقال إلى asp.net الأساسية 2.

إصلاحات نشطة للمشكلات - هل سيتلقى 1.x إصلاحات لجميع الأشياء التي نكسرها ، أم سيتم إخبارنا بالترقية للإصلاح في بعض الحالات؟ (ملاحظة: هذه ترقية لا يمكننا القيام بها حتى تكون مكتباتنا مثل DirectoryServices موجودة ... وحتى إذا لم نستطع أن تكون قريبة من كونها مجانية أو رخيصة ، فمن المحتمل أن تكون أشهر على الأقل). نحن كبار ، نحن سريعون ، سنجد فواصل في الإطار. لدينا لكل إصدار رئيسي وثانوي لسنوات. الدعم أمر بالغ الأهمية بالنسبة لنا.

لا أعتقد أن هناك مشكلة في الدعم. لا أعتقد في الواقع أن هذه ستكون مشكلة كبيرة وإذا كانت تجعل الناس يشعرون بمزيد من الثقة في الرهان ، فربما يكون الأمر يستحق تمديد الدعم لـ 1.x إلى إطار زمني أطول.

كلا ، أريد إصدارًا يعمل ومسارًا للمضي قدمًا. مع 1.x ، لدينا النصف الأول فقط. حتى هذه القضية ، كان النوع الثاني يفترض.

هذا يعني فقط أنك بحاجة إلى البقاء في 1.x حتى يتم نقل جميع تبعياتك ، أليس كذلك؟

NickCraver كل شكواك تتحدث عن أشياء مفقودة في .NET Core بدلاً من ASP.NET Core. في .NET Core 1.x و ASP.NET Core 1.x يتم شحن هذين الكيانين معًا ولكنهما منفصلان تمامًا. لم أسمع سببًا واحدًا لرغبتك في استخدام ASP.NET Core 2.0 على وجه التحديد بخلاف المخاوف الصالحة المتعلقة بدعم v1 لشيء ما و v2 لا يدعمه. أعتقد أننا سنجري نفس المناقشة بالضبط خلال عام إذا كان هناك سبب آخر لعدم قدرتك على النقل إلى .NET Core فقط (ربما أثناء تطوير ASP.NET Core في إطار العمل الكامل ، أخذت بعض التبعيات الجديدة التي لن يتم استدارتها أبدًا كمثال).

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

أنا هنا أجيب وأرد لأنني أحاول معرفة سبب حاجتنا إلى دعم .NET Framework إذا كان الأمر كذلك ، إلى متى. ما زلت أحصل على أجواء مختلطة حول هذا الموضوع حول تلك الأطر الزمنية. هناك أيضًا خوف عام يمكنني فهمه حول "الترحيل إلى ASP.NET Core 1.x" ولكن لا يوجد شيء ملموس من حيث الميزات المحددة المطلوبة في 2.x.

أحد الأشياء الرئيسية التي أحبها حول اقتران .NET Core و ASP.NET Core هو أنه يحل بعض إصدارات الجنون والتسمية. الكثير من الناس لا يعرفون حتى أن ASP.NET Core يعمل على .NET Framework (حتى أنه يربك القادمين الجدد إلى المكدس). ومع ذلك ، لدينا الكثير من العملاء لديهم الكثير من الاحتياجات المختلفة ونحن نستمع إلى ملاحظاتهم.

تضمين التغريدة

لقد كنت أتوقع بفارغ الصبر أن يكون الهدف من .NET Standard 2.0 هو توفير مساحة السطح المتوافقة للغاية والثبات الذي تشتد الحاجة إليه.

بالتأكيد ، ولكن كما قلت ، يتم فصل ASP.NET Core و .NET Core و .NET Standard في 1.x تمامًا. يمكنك استخدام أي مكتبة .NET Standard على أي إصدار من .NET Core يدعمها. لذلك إذا كان .NET Core 2.0 هو LTS جديد ، فلا يزال بإمكاننا الإعلان عن دعم ASP.NET Core 1.x عليه.

تضمين التغريدة

أريد الانتقال إلى netstandard2 في وقت ما لأسباب. سأحتاج إلى الانتقال لنقل تطبيق الويب الخاص بي إلى asp.net core 2 لذلك ، أليس كذلك؟

لا ، هذا ليس صحيحًا. يمكنك الانتقال إلى netstandard 2 وقتما تشاء دون نقل تطبيق الويب الخاص بك إلى ASP.NET Core 2.0.

السبب الوحيد لامتلاكنا هذه المكتبات القياسية هو أننا نحتاج إلى نقل تطبيق الويب الضخم الخاص بنا (كما ذكرت سابقًا). أود ألا أضطر إلى توسيع قاعدة الشفرة الخاصة بمنصتنا لمنصات أخرى ، وبدلاً من ذلك استمر في الارتقاء في سلسلة معايير الشبكة. لا أريد حقًا أن أكون عالقًا في معيار الشبكة 1.3 لأنه لا يوجد مسار للانتقال إلى asp.net الأساسية 2.

لا تحتاج إلى أن تكون عالقًا في معيار الشبكة 1.3. الشيئين غير مرتبطين.

عندما يدعمك الإصدار 1 ولكن الإصدار 2 لا يدعمك ولكن نأمل أن يحدث يومًا ما ، فهذه مقامرة سيئة حقًا ....

أعتقد أن هذا هو جوهر القضية. لدينا تعليقات تفيد بأن _ بعض_ الفجوات ( DirectoryService ، وآخرون) معروفة وسيتم معالجتها. نحن بحاجة إلى شيء ملموس أكثر من ذلك.

أنا موافق على استهداف ASP.NET Core لـ .NET Core ومعنا نفقد القارب 2.0 إذا كانت خارطة الطريق واضحة بشأن الوقت الذي يمكننا فيه توقع هذه الفجوات (وأي فجوات) ستتم معالجتها (مرة أخرى ، على افتراض أن هناك وقتًا كافيًا للتنقل من قبل 1.X يصبح غير مدعوم).

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

تضمين التغريدة

لا ، هذا ليس صحيحًا. يمكنك الانتقال إلى netstandard 2 وقتما تشاء دون نقل تطبيق الويب الخاص بك إلى ASP.NET Core 2.0.

ممتاز. في هذه الحالة ، طالما تضمن Microsoft أن 1.x مدعوم (جميع أنواع إصلاحات الأخطاء والدعم التشغيلي) حتى تقدم للعملاء مسار ترحيل 2.x مناسب (مثل SignalR) ، فأنا مرتاح في الانتظار حتى نبدأ تحتاج asp.net الأساسية 2.

هذا يعني فقط أنك بحاجة إلى البقاء في 1.x حتى يتم نقل جميع تبعياتك ، أليس كذلك؟

صحيح ، لكن يجب أن يكون ذلك ضمن إطار زمني معروف. ليس لدينا تواريخ ، الشيء الوحيد الذي قيل لنا حتى الآن هو "ليس في 2.0" ... لذلك هذا ليس جيدًا. على سبيل المثال ، تم طلب System.DirectoryServices منذ منتصف عام 2015 ، ولا يزال مفقودًا ومع ذلك يتكرر غالبًا باعتباره الأكثر طلبًا من قبل المستخدمين (متبوعًا بـ System.Drawing ). إن القول بأننا نجلب .NET Standard 2.0 إلى حوالي 60٪ من تكافؤ واجهة برمجة التطبيقات ، لكننا نفقد البتات التي طلبها المستخدمون ، يرسل بالتأكيد إشارات مختلطة حول ما هو مهم.

تتحدث جميع الشكاوى الخاصة بك عن أشياء مفقودة في .NET Core بدلاً من ASP.NET Core.

هذا غير صحيح. أحتاج إلى البتات التي نحتاجها للتشغيل (مثل AD auth) على منصة مدعومة. الشيء المفقود هو الدعم من الأخير. دعم 1.x هو بالتأكيد شاغلي الرئيسي. ليس لدينا مسار مدعوم للمضي قدمًا أو أي جداول زمنية للوقت الذي يمكننا فيه توقع ذلك.

أعتقد أننا سنجري نفس المناقشة بالضبط خلال عام

لا أعتقد أن هذا هو الحال. المشكلة هي أننا لم نتمكن من الشحن اليوم . واجهات برمجة التطبيقات ليست هناك. طالما لم تكن هناك نقطة زمنية واحدة كنا قادرين على نقلها ، فإن المناقشات حول المستقبل تظل محل نقاش. أتوقع أن يتم إهمال دعم .NET Framework الكامل في ASP.NET Core بمجرد وجود تكافؤ ويمكن لمعظم المستخدمين الانتقال. وأتوقع أن يكون لهذا الإصدار إطار زمني طويل للدعم حتى ينتقل الناس إليه.

إذا كانت خدمات الدليل والرسم وما إلى ذلك تأتي في 2.x ثم رائعة. يجب أن يدعم هذا الإصدار .NET Framework ، وأن يكون إصدار LTS. ويجب أن يسقط 3.x دعم إطار العمل الكامل.

أحد الأشياء الرئيسية التي أحبها حول اقتران .NET Core و ASP.NET Core هو أنه يحل بعض إصدارات الجنون والتسمية. الكثير من الناس لا يعرفون حتى أن ASP.NET Core يعمل على .NET Framework (حتى أنه يربك القادمين الجدد إلى المكدس). ومع ذلك ، لدينا الكثير من العملاء لديهم الكثير من الاحتياجات المختلفة ونحن نستمع إلى ملاحظاتهم.

عادل بما فيه الكفاية ، ولكن كل الجنون هناك ثانوي لـ "هل يعمل حتى؟". حاليًا ، هذا رقم ثابت. ASP.NET و .NET Core / Standard / أيًا كان قد يكون مجموعتان من الأشياء داخل Microsoft (وأنا أفهم ذلك تمامًا) ، لكن بالنسبة للمطورين ، لا تزال منصة واحدة. يحتاج جانب ASP.NET إلى أن تكون واجهات برمجة التطبيقات مفيدة للكثيرين ، وهي ليست موجودة بعد. تؤدي هذه الخطوة إلى مزيد من التخفيضات في واجهات برمجة التطبيقات المتاحة. قد يحصل فريق ASP.NET على ما يريدونه ، ولكن هذا على حساب الأشخاص الذين نحتاجهم.

تضمين التغريدة

أعتقد أن هذا هو جوهر القضية. لدينا تعليقات على أن بعض الثغرات (DirectoryService ، وآخرون) معروفة وسيتم معالجتها. نحن بحاجة إلى شيء ملموس أكثر من ذلك.

صحيح ، لكن يجب أن يكون ذلك ضمن إطار زمني معروف. ليس لدينا تواريخ ، الشيء الوحيد الذي قيل لنا حتى الآن هو "ليس في 2.0" ... لذلك هذا ليس جيدًا. على سبيل المثال ، تم طلب System.DirectoryServices منذ منتصف عام 2015 ، ولا يزال مفقودًا ولكنه يتكرر غالبًا باعتباره الأكثر طلبًا من قبل المستخدمين (متبوعًا بـ System.Drawing).

هذه الثغرات مرتبطة بـ NET Core نفسها على الرغم من أنني أستطيع أن أفهم القلق من عدم معرفة متى ستكون هذه التبعيات متاحة وهذا هو السبب في أن مساعدتنا في تحديد أولوياتها سيكون أمرًا جيدًا. والخبر السار هو أن netstandard 2.0 و netcoreapp2.0 وضعا العمل الجماعي لجعل المكتبات الأخرى أسهل في النقل. أتوقع أنه بمجرد أن نشحن 2.0 ، سيكون من الأسهل بكثير إحضار التبعيات الأخرى عن طريق نقل مجموعات من التعليمات البرمجية فوق قاعدتنا المتوافقة للغاية.

هل سيتم تشغيل CSOM في netcore 2؟ سيكون هذا مانعًا كبيرًا لنا ومنطقة واحدة لم أسمع أي شيء عنها.

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

كنت على الطريق لاعتماد الإصدار 1.0 بافتراض أن 2.x (أو أي شيء تم تطويره / إصلاحه بشكل نشط) سيدعم إطار العمل الكامل حتى تصبح واجهات برمجة التطبيقات (API) المهمة جاهزة (أنا جاد - أنت تعرف مقدار العمل الذي قمت به في المكتبات بالفعل ). لكن في هذه المرحلة ، لا يمكنني فعل ذلك في Stack ... كان افتراضًا سيئًا. لا يمكنني أن أخبر فرقنا باستخدام .NET Core بضمير حي بينما مستقبل أي منفذ غير مؤكد تمامًا. أتمنى حقًا أن أتمكن من ذلك ، لكن الأمر لا يستحق المخاطرة والألم في الوقت الحالي.

تضمين التغريدة

أتوقع أن يتم إهمال دعم .NET Framework الكامل في ASP.NET Core بمجرد وجود تكافؤ ويمكن لمعظم المستخدمين الانتقال. وأتوقع أن يكون لهذا الإصدار إطار زمني طويل للدعم حتى ينتقل الناس إليه.

ما هو مقياس "معظم المستخدمين" هنا؟ ما هي قائمة التبعيات التي يجب تغطيتها حتى نتمكن من إسقاط الدعم؟ تختلف قائمتك عن المستخدمين الآخرين في هذه القائمة. أتوقع أيضًا أن يقول بعض الأشخاص إلى الأبد أو حتى يصل .NET Core إلى تكافؤ .NET Framework (وهو أمر غير واقعي تمامًا). سأظل أفترض أن ASP.NET Core 1.x جيد بما يكفي لهذا الغرض ويجب أن ننظر في توسيع الدعم لذلك حتى الوقت المذكور.

هذا غير صحيح. أحتاج إلى البتات التي نحتاجها للتشغيل (مثل AD auth) على منصة مدعومة. الشيء المفقود هو الدعم من الأخير. دعم 1.x هو بالتأكيد شاغلي الرئيسي. ليس لدينا مسار مدعوم للمضي قدمًا أو أي جداول زمنية للوقت الذي يمكننا فيه توقع ذلك.

ما هو مكون ASP.NET مفقود لهذا السيناريو؟ عندما تقول 1.x مقابل 2.x ، سيكون من المفيد ذكر ASP.NET Core مقابل .NET Core.

إذا كانت خدمات الدليل والرسم وما إلى ذلك تأتي في 2.x ثم رائعة. يجب أن يدعم هذا الإصدار .NET Framework ، وأن يكون إصدار LTS. ويجب أن يسقط 3.x دعم إطار العمل الكامل.

لقد ذكرت هذا من قبل ، ما هي ميزات ASP.NET Core التي تحتاجها بحيث لا يكفي ASP.NET Core 1.x لهذا؟

ASP.NET و .NET Core / Standard / أيًا كان قد يكون مجموعتان من الأشياء داخل Microsoft (وأنا أفهم ذلك تمامًا) ، لكن بالنسبة للمطورين ، لا يزال هناك نظام أساسي واحد

متفق عليه ولكننا بحاجة إلى توضيح FUD بشأن هذه المناقشة حتى نتمكن من تقييم التأثير بشكل صحيح. يستهدف ASP.NET Core 1.x .NET Standard 1.x (1.0 - 1.6) و .NET Framework 4.5.1. هذا يعني أنه يمكن تشغيله على أي نظام أساسي يدعم تلك الإصدارات من netstandard و .NET Framework. هذا يعني أن ASP.NET Core 1.x سيعمل على .NET Core 2.0.

تضمين التغريدة

هل سيتم تشغيل CSOM في netcore 2؟ سيكون هذا مانعًا كبيرًا لنا ومنطقة واحدة لم أسمع أي شيء عنها.

ليس لدي فكرة ما هذا. هل هذا https://msdn.microsoft.com/en-us/library/ff798388.aspx؟ إذا كان الأمر كذلك ، لم يتم القيام بأي عمل لدعمه بشكل صريح. قد يعمل فقط على أساس توافق .NET Framework في .NET Core 2.0 ولكن أعتقد أنه لن يتم نقله إلى .NET Core (فقط بناءً على 5 دقائق من النظر إليه) ، ولكن قد أكون مخطئًا.

ما هو مقياس "معظم المستخدمين" هنا؟ ما هي قائمة التبعيات التي يجب تغطيتها حتى نتمكن من إسقاط الدعم؟ تختلف قائمتك عن المستخدمين الآخرين في هذه القائمة. أتوقع أيضًا أن يقول بعض الأشخاص إلى الأبد أو حتى يصل .NET Core إلى تكافؤ .NET Framework (وهو أمر غير واقعي تمامًا). سأظل أفترض أن ASP.NET Core 1.x جيد بما يكفي لهذا الغرض ويجب أن ننظر في توسيع الدعم لذلك حتى الوقت المذكور.

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

ما هو مكون ASP.NET مفقود لهذا السيناريو؟ عندما تقول 1.x مقابل 2.x ، سيكون من المفيد ذكر ASP.NET Core مقابل .NET Core.

لقد ذكرت هذا من قبل ، ما هي ميزات ASP.NET Core التي تحتاجها بحيث لا يكفي ASP.NET Core 1.x لهذا؟

أعني دعم أحدث ASP.NET Core الذي يدعم Full Framework (وبالتالي المكتبات التي أحتاجها). أتمنى أن تكون 2.x ، لأننا نريد وحدات وصفحات شفرات وما إلى ذلك. لدينا استخدامات للكثير من ميزات 2.x. ولكن يبدو أن خيارنا الوحيد هو 1.x في هذه المرحلة. لا يمكننا الانتقال من ASP.NET 5 إلى ASP.NET Core ومن الإطار الكامل مع جميع libs العمل لدينا إلى netcoreapp في خطوة واحدة. هذا كثير. إنه مكلف للغاية. إنها مخاطرة كبيرة. والآن نحن غير متأكدين مما إذا كان بإمكاننا القيام بهذه الخطوة المكلفة والمحفوفة بالمخاطر داخل نافذة الدعم. هذا وضع سيء - سيء جدًا لدرجة أنه من الأفضل عدم التحرك (كما هي الأمور اليوم). أعتقد أن هذا أمر مؤسف حقًا.

ما هو مكون ASP.NET مفقود لهذا السيناريو؟ عندما تقول 1.x مقابل 2.x ، سيكون من المفيد ذكر ASP.NET Core مقابل .NET Core.

• ما لم تكن هناك طريقة للتعامل مع مصادقة / استعلامات AD من خلال بعض Microsoft.Authentication. * NuGet package ، فهذا شيء مهم. أنا حاليًا في نفس القارب ، لكن نظرًا لأنني أقوم بتشغيل .NET Core 1.1 فوق .NET 462 ، سأكون قادرًا على تنفيذ ذلك. بخلاف ذلك ، كيف سأتمكن من الاستعلام عن أي مجموعات إعلانية أو بيانات وصفية من خلال الوسائل المدعومة؟ لقد رأيت في corefx repo أن هناك الكثير من العمل يحدث على System.DirectoryServices رغم ذلك ، لذلك أنا سعيد بذلك على الأقل.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . حاليًا ، لا يمكنني الوصول إلى ذلك إلا عند التشغيل على .NET Core أعلى .NET Framework الكامل. أعتقد أنه أكثر ملاءمة ، حيث لا يزال بإمكاني استخدام DbDataReader / SqlDataReader .

في الأساس ، أحتاج إلى معرفة أنه سيكون هناك ضمان لبعض الطرق المدعومة للتعامل مع مصادقة AD أثناء استخدام ASP.NET Core 2.x ، دون الحاجة إلى .NET Framework الكامل.

لقد كنت أفكر في هذا كثيرًا اليوم وأجد أن مخاوفي مختلفة عن معظم تلك الموجودة هنا (لا يعني أن هذه المخاوف ليست بنفس الأهمية ، إن لم تكن أكثر من ذلك).

ما زلت عالقًا في حالة استخدام حزم ASP.NET Core على netstandard . حتى هذه المشكلة كنت أفترض (ربما بشكل خاطئ) أن netstandard كان الهدف الفعلي للمكتبات. بمعنى آخر ، سيكون السلوك المقصود لمؤلفي المكتبة هو استهداف netstandard ما لم يكن هناك سبب ضروري ومقنع لا. هذا لا يضمن فقط التوافق مع Framework ولكن مع الأنظمة الأساسية الأخرى مثل Xamarin و UWP. يبدو أن العمل على .NET Standard 2.0 يدعم ذلك من خلال محاولة توحيد مساحة سطح واجهة برمجة التطبيقات لأوقات التشغيل المختلفة في هدف مشترك لا يحتاج إلى التفكير فيه.

بالنسبة لي ، يشير هذا التغيير إلى شيء مختلف. صحيح ، في نهاية اليوم ، يعد ASP.NET Core مجرد مكتبة وربما يكون لديه "أسباب ضرورية ومقنعة" لعدم دعم مساحة السطح المشتركة netstandard . لكنها أيضًا واحدة من مكتبات .NET الأكثر وضوحًا التي طورتها Microsoft ، ومن خلال القول "نريد الأحدث والأفضل ، لذلك سنتوقف عن دعم netstandard " ، فهذا يشير إلى جميع مطوري المكتبات الآخرين (أو في على الأقل بالنسبة لي) ربما يجب عليهم التوقف عن المحاولة الجادة لدعم netstandard والبدء فقط في استهداف وقت التشغيل الأساسي. لماذا تهتم بكل عناصر التوافق هذه عندما لا تهتم Microsoft كثيرًا بها؟ NET Core 4 lyfe. وربما يكون هذا للأفضل - إنه بالتأكيد مختلف عما اعتقدت أننا نذهب إليه مع أوقات تشغيل متعددة ومساحة سطح API موحدة في الغالب.

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

أخيرًا ، أنا قلق إلى حد ما (على الرغم من أنه أقل قليلاً) بشأن التعليقات هنا أنه بمجرد أن يكون من الممكن إضافة واجهات برمجة تطبيقات جديدة إلى Core للمراجعة بالتزامن مع ASP.NET. على وجه الخصوص ، قد لا تصل واجهات برمجة التطبيقات الجديدة هذه إلى netstandard أو .NET Framework. أنا أفهم بالتأكيد أنه قد يكون هناك بعض الأشياء المثيرة التي يمكن القيام بها إذا تم التخلي عن مخاوف الإرث والتوافق أو تخفيفها. لكن لكي أكون صريحًا ، لقد حصلت على انطباع بأن فريق ASP.NET Core غالبًا ما يكون هناك يدفع للأمام. هذا ليس بالضرورة أمرًا سيئًا ، ولكنه أدى أيضًا إلى عدد من التوصيفات الأوسع نطاقًا التي كان لا بد من التراجع عنها. لا يسعني إلا أن أتساءل عما إذا كان هذا ، والتطور السريع اللاحق لوقت التشغيل الأساسي ، سيؤدي إلى كسر مجموعة أوقات التشغيل بشكل كبير بمرور الوقت (ومرة أخرى ، لن يتم ترك Windows / Framework فقط - هناك أيضًا Xamarin و Mono و UWP وما إلى ذلك).

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

تضمين التغريدة

أعني دعم أحدث ASP.NET Core الذي يدعم Full Framework (وبالتالي المكتبات التي أحتاجها). أتمنى أن تكون 2.x ، لأننا نريد وحدات وصفحات شفرات وما إلى ذلك. لدينا استخدامات للكثير من ميزات 2.x.

الآن هو 1.1.1 (لا توجد وحدات في 2.0) ، Razor Pages هي واحدة جيدة ، وآخر هو SignalR. هذان هما الشيءان اللذان أرى أنهما الأكثر إيلامًا كجزء من هذا.

لا يمكننا الانتقال من ASP.NET 5 إلى ASP.NET Core ومن الإطار الكامل مع جميع libs العمل لدينا إلى netcoreapp في خطوة واحدة. هذا كثير. إنه مكلف للغاية. إنها مخاطرة كبيرة. والآن نحن غير متأكدين مما إذا كان بإمكاننا القيام بهذه الخطوة المكلفة والمحفوفة بالمخاطر داخل نافذة الدعم. هذا وضع سيء - سيء جدًا لدرجة أنه من الأفضل عدم التحرك (كما هي الأمور اليوم). أعتقد أن هذا أمر مؤسف حقًا.

غير أنه على الرغم من؟ سيكون الانتقال من ASP.NET Core 1.x إلى 2.x أو 3.x بافتراض أنه تم نقل تبعياتك أمرًا تافهًا. إذا كنت تخطط للانتقال إلى ASP.NET Core بشكل عام ، فإن الانتقال إلى 1.1 يعد خطوة أولى جيدة ولن تقوم بحفظ أي عمل لتجنب ذلك.

تضمين التغريدة

في الأساس ، أحتاج إلى معرفة أنه سيكون هناك ضمان لبعض الطرق المدعومة للتعامل مع مصادقة AD أثناء استخدام ASP.NET Core 2.x ، دون الحاجة إلى .NET Framework الكامل.

حتى يتم دعم System.DirectoryServices على .NET Core ، فهل هناك سبب لعدم استخدام ASP.NET Core 1.x على .NET Framework؟

حتى يتم دعم System.DirectoryServices على .NET Core ، فهل هناك سبب لعدم استخدام ASP.NET Core 1.x على .NET Framework؟

هذا ما أفعله حاليًا. إنني أتطلع فقط على أمل ألا أضطر للقلق بشأن .NET Framework إذا لم أكن بحاجة إلى ذلك. حاليًا ، يقيدني على جهاز Windows الخاص بي لأن مساحة الاسم System.DirectoryServices.AccountManagement غير موجودة في Mono. في نفس هذه الأمور ، هل سيكون هناك System.DirectoryServices.AccountManagement متاحًا خارج قيود Windows؟ تجبرني هذه القطعة الصغيرة على التنقل بين الأجهزة أثناء تصحيح أخطاء مشروع MVC الخاص بي وتطبيق Xamarin.iOS الخاص بي محليًا.

إذا كنت تخطط للانتقال إلى ASP.NET Core بشكل عام ، فإن الانتقال إلى 1.1 يعد خطوة أولى جيدة ولن تقوم بحفظ أي عمل لتجنب ذلك.

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

أستمر في الرجوع إلى DirectoryServices لأن هذا ما أعرفه لا يعمل على netcoreapp2.0 اليوم. بالطبع ستكون هناك أشياء أخرى نجدها تقع في نفس القارب. نحتاج إلى دعم ASP.NET Core + full framework + لعدة سنوات على بعض الأنظمة الأساسية. مع 1.x ، لا نحصل على الكثير من المكاسب ، في الواقع نحصل على القليل جدًا. الأداء ليس حجة رائعة لأننا نعرض بالفعل الصفحات في حوالي 18 مللي ثانية ويتضاءل مع وقت النقل. 2.0 مع ذلك ، يقدم عددًا قليلاً من العناصر الجيدة. صفحات Razor واحتمالية المكونات الإضافية تجعلها جذابة للغاية للتنقل إليها. لدرجة أن يكون لها ما يبررها.

في الوقت الحالي ، الإصدار الوحيد الذي يجب استخدامه مع الدعم (1.1.x مع دعم أطول ، هو ما أتوقعه بعد قراءة هذا الموضوع) لا يستحق الانتقال إليه. سيكون هناك الكثير من الوقت والجهد للوصول إلى ما نحن عليه اليوم. يقدم 2.x على الأقل بعض التحسينات والقطع اللائقة التي نرغب في الاستفادة منها. يساعدون في تبرير تكلفة الانتقال.

الأداء ليس حجة رائعة لأننا نعرض بالفعل الصفحات في حوالي 18 مللي ثانية

في تشدق بسيط في OT ، أود أن أعرف كيف يمكنك عرض الصفحات في حوالي 18 مللي ثانية على NickCraver . هذا رائع

تضمين التغريدة

ما زلت عالقًا في حالة استخدام حزم ASP.NET Core على شبكة الإنترنت. حتى هذه المشكلة كنت أفترض (ربما بشكل خاطئ) أن معيار الشبكة هو الهدف الفعلي للمكتبات. بعبارة أخرى ، سيكون السلوك المقصود لمؤلفي المكتبات هو استهداف معيار الشبكة ما لم يكن هناك سبب ضروري ومقنع لا. هذا لا يضمن فقط التوافق مع Framework ولكن مع الأنظمة الأساسية الأخرى مثل Xamarin و UWP. يبدو أن العمل على .NET Standard 2.0 يدعم ذلك من خلال محاولة توحيد مساحة سطح واجهة برمجة التطبيقات لأوقات التشغيل المختلفة في هدف مشترك لا يحتاج إلى التفكير فيه.

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

• Microsoft.Extensions. * (التسجيل ، DI ، التكوين ، FIleProviders ، إلخ)
• إطار كيان
• عملاء SignalR (يجب تشغيلهم على .NET Framework و Xamarin و UWP وما إلى ذلك).

.NET Standard هي الطريقة الفعلية لكتابة مكتبات تعمل في كل مكان. يجب أن يهدف مؤلفو المكتبات إلى استهداف شبكة الإنترنت حيثما أمكن ذلك للوصول إلى أوسع نطاق للمنصة. يتعين على مؤلفي المكتبة أن يقرروا ما إذا كانوا يريدون الوصول أم لا. لهذا السبب تدعم مكتبات مثل JSON.NET netstandard1.x و .NET framework 2.0. لقد بذلوا جهدًا إضافيًا لجعل الأشياء "تعمل فقط" كما ذكر JamesNK أعلاه.

يعد تحرك ASP.NET Core بعيدًا عن netstandard في بعض الأماكن بمثابة بيان بأن واجهات برمجة التطبيقات هذه ليست مخصصة لتطبيقات UWP ونحن بالتأكيد لا نختبرها هناك (كمثال). يحاول أيضًا ترسيخ أن NET Core و ASP.NET Core هما منتج واحد يتم إصدارهما معًا (نظرًا لأنه يحتوي على Core في الاسم). مع ASP.NET Core 1.x الذي يدعم كلاً من .NET Core و .NET Framework ، كانت هذه الرسالة ضبابية قليلاً وتسبب ارتباكًا للكثير من الأشخاص (خاصةً المطورين الجدد) وقد فعلنا ذلك لتخفيف مشكلة فجوة المكتبة.

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

أظن أن هؤلاء لا يزالون عاديين. أي منها ليست كذلك؟

لا يسعني إلا أن أتساءل عما إذا كان هذا ، والتطور السريع اللاحق لوقت التشغيل الأساسي ، سيؤدي إلى كسر مجموعة أوقات التشغيل بشكل كبير بمرور الوقت (ومرة أخرى ، لن يتم ترك Windows / Framework فقط - هناك أيضًا Xamarin و Mono و UWP وما إلى ذلك).

أعتقد أن netstandard سيتطور ، لكن .NET Framework سيكون دائمًا آخر من يحصل على واجهات برمجة تطبيقات جديدة (Xamarin و Mono سريعان جدًا في إضافة أشياء).

تضمين التغريدة

هذا ما أفعله حاليًا. إنني أتطلع فقط على أمل ألا أضطر للقلق بشأن .NET Framework إذا لم أكن بحاجة إلى ذلك. حاليًا ، يقيدني على جهاز Windows الخاص بي لأن مساحة الاسم System.DirectoryServices.AccountManagement غير موجودة في Mono. في نفس هذه الأمور ، هل سيكون هناك System.DirectoryServices.AccountManagement خارج قيود Windows؟ تجبرني هذه القطعة الصغيرة على التنقل بين الأجهزة أثناء تصحيح أخطاء مشروع MVC الخاص بي وتطبيق Xamarin.iOS الخاص بي محليًا.

تأكد من تقديم ملف مثل هذه المشكلات على dotnet / corefx. إن افتراض أنه سيتم نقل تبعياتك (ما لم تكن شائعة بشكل كبير) هو الشيء الخطأ الذي يجب فعله.

davidfowl سؤال: أريد ملف -> مشروع جديد مع ASP.NET Core 2.0 والمصادقة ضد AD. هل هذا ممكن؟ لا يمكنني ببساطة أن أتخيل شحن منصة Microsoft بدون القدرة على القيام بذلك.

موافق على كل شيء هناك ولكني لا أرى كيف يؤثر هذا القرار على أي شيء قلته. أريد كل هذه الأشياء نفسها

بإسقاط الدعم لـ .NET v4.x ، سيقتل مسار الترحيل الشائع ويفتت نظام .NET البيئي بشكل أكبر ويمنع العديد من المطورين والمؤسسات من أن يكونوا قادرين على اعتماده مما سيقلل من تجمع المجتمع الأوسع للمعرفة والاستثمار في ASP. NET Core لأن العديد من مطوري .NET سيحتاجون إلى دعم قواعد كود ASP.NET v4.x الحالية إلى أجل غير مسمى (والتي يحصلون عليها مقابل العمل بدوام كامل).

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

أعتقد أن كل شخص هنا يريد أن يزدهر النظام البيئي .NET ولكن يبدو أننا على خلاف مع فريق MS حول أفضل السبل لتحقيق ذلك كما أعتقد اعتقادًا راسخًا بإسقاط .NET v4.x في وقت مبكر قبل كمية معروفة ومتوافقة للغاية ، إصدار LTS المستقر المتاح هو خطأ سيكون له آثار ضارة لسنوات قادمة.

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

NickCraver ما نوع المصادقة التي تستخدمها ضد AD اليوم؟ OpenIdConnect ، WsFed ، NTLM ، أخرى؟

Tratcher AD المصادقة ، عبر DirectoryServices (نحتاج إلى الاستعلام عن عضوية المجموعة ، وما إلى ذلك - البتات القياسية)

mythz أعتقد أن هذا معقول وأعتقد أن تمديد فترة دعم ASP.NET Core 1.x سيكون كافياً لتغطية معظم الحالات.

أرى سبب وجوب اتخاذ هذا القرار في وقت ما ولكني أعتقد أيضًا أنه سابق لأوانه وسيكون أسعد مع:

• ASP.NET Core 2.x هو LTS والأخير لدعم Full Framework (بالتأكيد نظرًا لأننا كنا بالفعل في المعاينة ، فأنت لست بعيدًا جدًا) مع SignalR الذي يتبعه لاحقًا في العام لدعمه بحيث يكون إطار العمل المستهدف لتحقيق القفزة من ASP.NET إلى ASP.NET Core
• 3.x إسقاط الدعم لـ Full Framework وإصداره عند ترحيل أعلى التبعيات

مجرد توسيع نطاق الدعم لـ ASP.NET Core 1.1 من وجهة نظري لن يكون كافيًا لأن هذا النظام الأساسي ليس ناضجًا / معتمدًا بما يكفي ليكون هدفًا للعديد من عمليات ترحيل ASP.NET (في حالتي ، يكون SignalR هو أداة الحظر).

فقط من أجل lulz ، حاولت استخدام EntityFramework 6 - التي رأيتها تستخدم على نطاق واسع في تطبيقات ASP.NET Core 1.0 التي عملت عليها - مع أحدث إصدارات preview2 .NET Core الليلية. خمين ما...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

توقف عن التظاهر بالتجميعات المصممة والمترجمة للإطار الكامل ستعمل بشكل لا تشوبه شائبة على .NET Core: من المحتمل أن تعمل الحالات التافهة (اقرأ hello world apps) ، ولكن في كثير من الحالات ، سوف ينتهي بك الأمر إلى أن يتم حظرك بواسطة واجهات برمجة التطبيقات المفقودة أو واجهات برمجة التطبيقات غير الوظيفية .

الأمر السيئ للغاية هو أنك ستدرك فقط أنه لا يعمل في وقت التشغيل. في بعض الحالات ، لن يكون الأمر واضحًا على الإطلاق. على سبيل المثال ، لا يدعم .NET Core's SqlClient تسجيل المعاملات المحيطة ولا المعاملات الموزعة مع TransactionScope : حتى إذا وجدت طريقة لجعل EF 6 تعمل ، فإن TransactionScope s لن تكون فعالة على الإطلاق ولن تستخدم مكالمات قاعدة البيانات مستوى العزل الذي تحتاجه.

أشعر أنه من الضروري إضافة سنتي هنا فيما يتعلق بمخاوفي بشأن هذه الخطوة. لدينا تطبيق سطح مكتب هو Windows Forms بشكل أساسي مع بعض المناطق الأحدث التي تم تطويرها في WPF. هناك أكثر من 15 عامًا من الجهد في هذا التطبيق وسيستغرق الأمر سنوات للابتعاد تمامًا عن WinForms. أتمنى لو لم يكن الأمر كذلك ، لكن الأمر كذلك. لقد عملنا على بناء المزيد من الوحدات النمطية في قاعدة التعليمات البرمجية حتى نتمكن من استهلاك طبقات الوصول إلى البيانات والأعمال عبر واجهة ويب أحدث وتطبيق WinForms الحالي. كنت أنوي الانتقال إلى ASP.NET Core لتطبيق الويب الأحدث الخاص بنا قريبًا جدًا ، ولكن كما ذكرت للتو ، سأحتاج إلى استهلاك غالبية كبيرة من قاعدة التعليمات البرمجية الحالية التي تستهدف .NET v4.6.x. أعلم على وجه اليقين أننا نستخدم System.Drawing و System.Security.Cryptography. نحن أيضًا نستفيد بشكل مكثف من TransactionScope بالطرق المذكورة أعلاه.

لقد كنت أتطلع بشدة إلى اكتساب بعض مزايا ASP.NET Core مثل القدرة على تغليف مناطق من تطبيق الويب الخاص بنا في تجميعات منفصلة دون الحاجة إلى الاعتماد على MEF لتجميعها معًا. هناك العديد من الأسباب الإضافية ولكن هذا هو الشيء الذي يجعلها لطيفة حقًا. ومع ذلك ، إذا قمت بنقل تطبيقنا إلى ASP.NET Core ، فمن المحتمل أن أكون عالقًا في 1.x في المستقبل المنظور لأنه يتعين علينا الحفاظ على قابلية النقل في التعليمات البرمجية الخلفية الخاصة بنا باستخدام WinForms. لقد ركزت بشكل أساسي على منتج الويب ، لذلك لا يمكنني إخبارك بمكان ربطنا بأشياء مثل WMI ، وما إلى ذلك ، وما إذا كان يؤثر على مسألة قابلية النقل ، لكنني أعلم أننا داخل قاعدة التعليمات البرمجية الخاصة بنا. نحن في مرحلة ممتعة حقًا في الوقت الحالي وآخر شيء أريد القيام به هو تطوير جميع إصدارات الويب لميزاتنا على ASP.NET MVC 5 وتجميع مجموعة من التعليمات البرمجية القديمة الجديدة التي ستحتاج إلى نقلها في بعض مسعى مستقبلي.

أنا متأكد من أنه سيكون لدينا الكثير من الاستخدامات التي ستبعدنا عن استهداف .NET Standard حتى لو / عندما لم نعد نستخدم WinForms. نحن أحد شركاء Microsoft ونعمل مباشرةً مع Microsoft من أجل منتجنا بعدة طرق ، لذلك لا أريد الخوض في الكثير من التفاصيل حول ما نقوم به هنا ، ولكن سأكون سعيدًا بإجراء مناقشة أكثر خصوصية مع @ shanselman أو davidfowl إذا كنت بحاجة إلى مزيد من التفاصيل حول ما نقوم به. سأكون أيضًا في MS Build ويمكن أن ألتقي وأتحدث إلى أي منكم هناك إذا كنتم حاضرون.

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

مواحة. لست متأكدا إذا كان علي الضحك أو البكاء ...

إليك التقرير الذي تم إنشاؤه بواسطة أداة التحليل ApiPort لتطبيق EF 6 التافه المكون من 23 سطرًا والذي لا يعمل:

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

قبل فتح هذا الإصدار ، هل كانت هناك عملية تعليقات؟

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

كنت أفهم أن إطار العمل الأساسي كان عبارة عن لعبة مشتركة بين الأنظمة الأساسية ، وهو إطار عمل جديد يتكون من مجموعة فرعية من إطار العمل الكامل غير المقترن بـ Windows. كان الإصدار 2.0 هو الإصدار الذي كنا ننتظره جميعًا حيث نحصل على معظم واجهة برمجة التطبيقات (API).

كان ASP.NET Core بمثابة طعام الكلاب لهذا الإطار الجديد ، وهو إطار عمل ويب جديد يعتمد على مساحة سطح صغيرة من إطار عمل API بحيث يمكن تشغيله في كل مكان.

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

الآن للعثور على ASP.NET لن يكون حتى معيارًا تجريبيًا وسيذهب إطار عمل محدد eh: /

تضمين التغريدة

مجرد توسيع نطاق الدعم لـ ASP.NET Core 1.1 من وجهة نظري لن يكون كافيًا لأن هذا النظام الأساسي ليس ناضجًا / معتمدًا بما يكفي ليكون هدفًا للعديد من عمليات ترحيل ASP.NET (في حالتي ، يكون SignalR هو أداة الحظر).

ماذا لو عملت SignalR على ASP.NET Core 1.x؟ ما الأشياء الأخرى غير الناضجة في المنصة التي تحتاجها؟

@ millman82 شكرا لتقاسم ذلك. يبدو أنك ستظل عالقًا في الإصدار قبل إسقاط دعم .NET Framework لفترة من الوقت. لذا فإن بعض الاقتراحات هنا حيث نحافظ على توافق 2.x و 3.x قد تسقطها قد لا تعمل من أجلك. لماذا لا تبقى فقط على ASP.NET Core 1.x؟ ما الذي ينقصك في مينائك؟ أم أنه مجرد القلق مثل @ NickCraver (أن 2.x عدم دعمه يجعلك متوتراً بشأن الرهان عليه).

تضمين التغريدة

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

هذا ليس بعيد المنال ، إنه يفتقد عنصر الوقت فقط. ستجعله في النهاية في كل إطار عمل كل سفينة وفقًا لجدولها الزمني الخاص.

الآن للعثور على ASP.NET لن يكون حتى معيارًا تجريبيًا وسيذهب إطار عمل محدد eh: /

لا يزال جزء منه يستهدف المعايير القياسية كما تم ذكره عدة مرات في هذا الموضوع.

لماذا لا تبقى فقط على ASP.NET Core 1.x؟

لا يمكنك - إنه خارج الدعم بعد عام واحد من انخفاض 2.0 (بافتراض أن 2.0 هو LTS التالي).

davidfowl إنه بالتأكيد جزء كبير من ذلك. نستخدم أيضًا OData و SignalR في تطبيق الويب الحالي الخاص بنا والذي يجب أن يكون في ASP.NET Core قبل أن نتمكن من الانتقال. ومع ذلك ، فإن الشيء الوحيد الذي لا أريد أن يحدث هو أن أعلق في طي النسيان عند إسقاط دعم ASP.NET Core 1.x ولا يوجد مسار ترحيل مع أجزاء إطار العمل التي نستخدمها والتي لا يتم دعمها حاليًا. أتوقع أن يحل ASP.NET Core محل ASP.NET بالجملة. قد يكون في مكان ما على الطريق ولكنه قادم. مع العلم أنني أكره إعادة كتابة واجهة المستخدم الخاصة بنا الآن في ASP.NET MVC 5 (لدينا بعض الأشياء هناك الآن ولكن من السهل نقلها لأنها صغيرة) فقط بعد سنوات قليلة أعد كتابتها مرة أخرى في ASP.NET Core بمجرد وصول نهاية حياة ASP.NET.

من المحتمل أن نعد أنفسنا للإحراق بشدة إذا كان مسار الترحيل هذا غير موجود عند وصول EOL الخاص بـ ASP.NET Core 1.x إذا تم تمديده مؤقتًا إذا كنا نستهدف Core 1.x الآن. ربما يمكننا التنقل في بعض منها بخدمات صغيرة ، ومع ذلك ، فإن هذا بالطبع له مخاوفه الخاصة.

تضمين التغريدة

لا يمكنك - إنه خارج الدعم بعد عام واحد من انخفاض 2.0 (بافتراض أن 2.0 هو LTS التالي).

افترض لثانية أنه ليس خارج الدعم عندما يسقط 2.0. أليس هذا كافيا؟

ومع ذلك ، فإن الشيء الوحيد الذي لا أريد أن يحدث هو أن أعلق في طي النسيان عند إسقاط دعم ASP.NET Core 1.x ولا يوجد مسار ترحيل مع أجزاء إطار العمل التي نستخدمها والتي لا يتم دعمها حاليًا

استبدل 1.x بـ 2.x في تلك الجملة. هل تعتقد أنه في غضون عام سيتم نقل جميع تبعياتك؟

استبدل 1.x بـ 2.x في تلك الجملة. هل تعتقد أنه في غضون عام سيتم نقل جميع تبعياتك؟

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

لا أعتقد أنه يمكنك توقع أن تتبنى الشركات شيئًا لا يدعمه مع عدم وجود وسيلة للانتقال إلى إصدار أحدث لأن التبعيات المفقودة لم يتم نقلها.

لماذا يخرج من الدعم؟ في العالم الافتراضي الخاص بي ، سنقوم بدعم ASP.NET Core 1.x على .NET Framework لفترة أطول.

لماذا يخرج من الدعم؟ في العالم الافتراضي الخاص بي ، سنقوم بدعم ASP.NET Core 1.x على .NET Framework لفترة أطول.

سؤالي هو إلى متى؟ أيضًا ، هل الفريق كبير بما يكفي لجلب تلك التبعيات الضرورية مثل SignalR و OData إلى ASP.NET Core 1.x والحفاظ على الدعم حتى يتم نقل كل تلك التبعيات المفقودة ، في الواقع؟ يبدو أنه يتعارض مع الحجج التي تم تقديمها مسبقًا حول سبب رغبتك في إسقاط دعم .NET الكامل الآن. سؤال صادق ...

سؤالي هو إلى متى؟ أيضًا ، هل الفريق كبير بما يكفي لجلب تلك التبعيات الضرورية مثل SignalR و OData إلى ASP.NET Core 1.x والحفاظ على الدعم حتى يتم نقل كل تلك التبعيات المفقودة ، في الواقع؟ يبدو أنه يقاوم الحجج التي تم تقديمها مبكرًا حول سبب رغبتك في إسقاط دعم .NET الكامل الآن. سؤال صادق ...

سأطرح رقمًا عشوائيًا ، 3 سنوات. لا يمتلك فريق ASP.NET تكامل Odata ، فإن فريق odata يمتلكه لذلك لا يمكنني الإجابة عنهم. بالنسبة لـ SignalR ، أعتقد أنه سيكون من الممكن استهداف ASP.NET Core 1.x.

المشكلة التي أراها هي أن كل شخص لديه مجموعة مختلفة من "التبعيات المفقودة" مما يجعل من المستحيل التفكير عندما يكون "مناسبًا" لإسقاط دعم .NET Framework للجميع. من المحتمل أيضًا أن بعض هذه التبعيات قد لا يتم نقلها مطلقًا (مثل CSOM).
بالطبع ، عندما تكون في قطار 1.x ، ستحصل على إصلاحات للأخطاء وميزات ثانوية ، لكن الجزء الأكبر من العمل سيظل يحدث في أحدث تخصص لـ ASP.NET Core.

أيضًا لا يمنعك أي من هذا من استخدام .NET Core 2.0 أو .NET Standard 2.0 مع ASP.NET Core 1.x. أريد فقط التأكد من أن الجميع على دراية بذلك لأن هذه الخيوط المستمرة تخلط بين ASP.NET Core و .NET Core (وهو أحد الأسباب التي تجعلنا نرغب في استهداف NET Core فقط).

المشكلة التي أراها هي أن كل شخص لديه مجموعة مختلفة من "التبعيات المفقودة" مما يجعل من المستحيل التفكير عندما يكون "مناسبًا" لإسقاط دعم .NET Framework للجميع.

استخدم النظام البيئي لمعرفة ما هي القائمة (لا ، هذه المشكلة ليست المكان المناسب للقيام بذلك). إذا كانت تبعية مملوكة لشركة Microsoft ، فقم بنقلها. إذا لم يكن الأمر كذلك ، فتواصل مع المالك لإبلاغه بالخطط والمساعدة في دليل الترحيل (إذا لم يفعل أي شيء ، فهذا ليس خطأ Microsoft). في الوقت الذي تستغرقه هذه العملية ، قم بدعم ASP.net core 1.x. لا أرى أي طريقة أخرى لتحقيق أهدافك دون إزعاج الكثير من الناس. هذا شيء كبير يتم اقتراحه ويحتاج إلى مستوى عالٍ من الرعاية والاهتمام للقيام به بشكل صحيح.

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

أفضّل العمل على تحقيق تكافؤ API ضمن .NET Core و .NET Standard و .NET Framework. أيضًا ، اكتشف الشخص الذي يجب على الأشخاص السعي لاستهدافه. كما أعتقد قيل سابقًا ، ربما بطريقة مختلفة قليلاً ، فإن .NET Standard يبدو وكأنه عصابة. في النهاية ، أتوقع أن يكون .NET Core هو خيار "إطار العمل" الوحيد وعندما يحدث ذلك ، انتقل .NET Framework و .NET Standard إلى جانب الطريق. أنا نفسي ، وأعتقد مع معظم الذين تحدثوا منذ الإعلان ، أود أن أكون قادرًا على الاستمرار في الاستفادة من العمل الذي تقوم به في جانب ASP.NET Core دون التمتع بحرية ما يقومون بتنفيذ التعليمات البرمجية الخاصة بهم في الأعلى من إزالتها.

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

خلاصة القول ، نحن متحمسون لهذا لأننا نريد استخدامه.

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

لدينا الكثير من العملاء ولدينا مطورون جدد لم يسبق لهم رؤية .NET في حياتهم. نحن بحاجة لتلبية احتياجات الجميع لأن هذا ما نحاول القيام به كشركة Microsoft. يعرف الأشخاص الذين يعملون على .NET Framework أنه يعمل ويحبونه ويفهمونه ، لذا تأكد من فهمك أن ASP.NET Core يعمل على .NET Framework ولكن بصفتي مطورًا جديدًا يقترب من النظام الأساسي ، آمل ألا أذكر ذلك أبدًا لأنه يفسد القصة مقارنة بـ شيء من هذا القبيل go أو node (والتي لها ما يقرب من 0 إرث في هذه المرحلة).

أفضّل العمل على تحقيق تكافؤ API ضمن .NET Core و .NET Standard و .NET Framework. أيضًا ، اكتشف الشخص الذي يجب على الأشخاص السعي لاستهدافه. كما أعتقد قيل سابقًا ، ربما بطريقة مختلفة قليلاً ، فإن .NET Standard يبدو وكأنه عصابة. في النهاية ، أتوقع أن يكون .NET Core هو خيار "إطار العمل" الوحيد وعندما يحدث ذلك ، انتقل .NET Framework و .NET Standard إلى جانب الطريق. أنا نفسي ، وأعتقد مع معظم الذين تحدثوا منذ الإعلان ، أود أن أكون قادرًا على الاستمرار في الاستفادة من العمل الذي تقوم به في جانب ASP.NET Core دون التمتع بحرية ما يقومون بتنفيذ التعليمات البرمجية الخاصة بهم في الأعلى من إزالتها.

كل هذه الأشياء تحدث بالتوازي. لا يتوقف ASP.NET Core عن العمل على الميزات حتى يتم نقل "كل شيء" إلى .NET Core من .NET Framework. سوف تستمر ASP.NET في الابتكار والاستفادة من واجهات برمجة التطبيقات المتوفرة على .NET Core نظرًا لأننا نشحن كجزء من نفس الصندوق.

أرى بعض الأفكار الشائعة في هذا الموضوع من:

• أريدك أن تدعم .NET Framework إلى الأبد.
• أريدك أن تدعم .NET Framework حتى يتم نقل التبعيات التي أحتاجها لتطبيقي.
• أنا فقط بحاجة إلى سنة أخرى ، وهذا سيكون وقتًا كافيًا بالنسبة لي لإسقاط دعم .NET Framework (ASP.NET Core 3.x).

هناك أيضًا حقيقة أننا لم نكتب إعلانًا (وهو خطأنا) ولكن هناك إعلان قادم (أعدك ، ألوم عطلة نهاية الأسبوع).

لا أعرف أيضًا كيف يبدو تكافؤ API بالنسبة لمعظم الأشخاص هنا ، أعتقد أنه يختلف باختلاف الأشخاص. NET Framework هو عبارة عن تقنية مؤسسية صلبة وموثوقة عمرها أكثر من 15 عامًا مرتبطة بنظام Windows.
تم تصميم .NET Core لكتابة خدمات صغيرة حديثة خفيفة الوزن عبر الأنظمة الأساسية ، وقد تطورت ببطء لتصبح أكثر توافقًا بحيث أصبح نقل المكتبات أسهل. ومع ذلك ، لا أعرف ما يعنيه التعامل مع .NET Framework من حيث التوافق أو ما إذا كان هذا هدفًا (لم يكن في الأصل). في مرحلة ما ، لن تكون قادرًا على استخدام ASP.NET Core أعلى .NET Framework وسيكون هناك بعض التبعية التي لا يمكن إعادة كتابتها غير متوافقة مع .NET Core. ستحتاج التطبيقات إلى مراعاة ذلك عند تصميمها مع وضع ASP.NET Core في الاعتبار (في المستقبل القريب).

فيما يتعلق بالمشاريع التي أعمل عليها ، فإن فترة الدعم الأطول بكثير لـ 1.1 ستكون بمثابة تخفيف مناسب. من غير المحتمل أن نتمكن من إسقاط تبعيات netfx في عام واحد ، ولكن من المرجح أكثر بكثير مع الثلاث سنوات التي اقترحتها كرجل أعمال. سيكون من الرائع حقًا أن يكون لديك إصدار حيث يأتي كل شيء معًا عند المستوى 2.0 أولاً - هذه هي النقطة التي كان من المفترض أن يصبح فيها كل شيء أسهل في النقل! أنا أتحدث باسم منظمة واحدة فقط ولكن "2.0 سيكون إصدار LTS ؛ 3.0 سوف يسقط netfx" سيكون في الأساس عملًا كالمعتاد بالنسبة لنا بدلاً من سبب FUD.

أود أيضًا أن أردد ما قالتهPureKrome حول تقدير هذه المشاركة ، لقد كانت مناقشة مفيدة للغاية.

فيما يتعلق بموضوع التكافؤ - لقد افترضت سابقًا أن نواة .net لن تقترب أبدًا من مستويات توافق إطار عمل .net ، ولكن هذا كان جيدًا لأن asp . net الأساسية ستستمر في دعم كليهما.

أعتقد أننا كمجتمع نستخدم أساسًا .net core من أجل استخدام asp.net الأساسية ، وليس لمزاياها الخاصة. كما قلت ، هم منتج واحد ، وقد فكرت في CLR الأساسي كجزء اختياري من هذا المنتج مع الفوائد والعيوب إذا تم اختياره.

بعد النوم فوقها ليلة -

أنا شخصياً أعتقد أنه من الجيد ترك إطار عمل .net القديم خلفك وكتابة أفضل إطار عمل ويب ممكن لوقت التشغيل الحديث.

لكنك تعلم أنه محفوف بالمخاطر بالتأكيد وقد تفقد بعضًا من عملائك هنا على طول الطريق (آمل ألا - لكنني أقوم بالكثير من الاستشارات - و NET Core بالنسبة للعديد من الشركات بعيد المنال الآن - فلنأمل 2.0 يغير ذلك).

.. ونعم - كان التواصل حول هذا (كالعادة) شيئًا يمكنك تحسينه (النسخة الأكثر تهذيبًا من هذه الجملة للألمانية) ؛)

+1

أنا شخصياً أعتقد أنه من الجيد ترك إطار عمل .net القديم خلفك وكتابة أفضل إطار عمل ويب ممكن لوقت التشغيل الحديث.

أوافق بشدة. كنت آمل أن يكون هذا العالم تغييرًا تدريجيًا ، على سبيل المثال ، أسقط Kestrel الدعم أولاً للكمال (الاستضافة القائمة على http.sys المتبقية) ، ثم mvc / * متابعة تحسينات API والوظائف أثناء جهود اختبار النقل / التوافق لـ netstandard2.0.

ممتاز. في هذه الحالة ، طالما تضمن Microsoft أن 1.x مدعوم (جميع أنواع إصلاحات الأخطاء و> الدعم التشغيلي) إلى أن توفر للعملاء مسار ترحيل 2.x مناسب (مثل SignalR) ، فأنا مرتاح لأتحمل وقتي حتى نحتاج إلى asp.net الأساسية 2.

+1

قادر على النقل إلى .NET Core فقط (ربما أثناء تطوير ASP.NET Core في إطار عمل كامل ، أخذت بعض التبعيات الجديدة التي لن يتم نقلها كمثال أبدًا).

موافق تماما.
الآن أعتقد أن هذا قرار جيد. أعتقد أنه في السيناريوهات المثالية ، نحتاج إلى دعم أكثر من عام واحد ، ولا أعرف ربما 2-3 سنوات ، ومعلومات حول ما سيتم نقله ، من أجل ثقة المجتمع.
لا. دعم صافي 461.

تضمين التغريدة

أوافق بشدة. كنت آمل أن يكون هذا العالم تغييرًا تدريجيًا ، على سبيل المثال ، أسقط Kestrel الدعم أولاً للكمال (الاستضافة القائمة على http.sys المتبقية) ، ثم mvc / * متابعة تحسينات API والوظائف أثناء جهود اختبار النقل / التوافق لـ netstandard2.0.

نحن لا نجري حتى اختبارات الأداء على .NET Framework ... سيحدث اختبار النقل والتحسينات على .NET Core و .NET Standard على أي حال ، وليس لـ IMO أي تأثير على ما إذا كان دعم .NET Framework قد تم إسقاطه أم لا. إذا كان هناك أي شيء ، فإنه يجعلنا نركز الليزر على تلك السيناريوهات لأنها الهدف الوحيد.

تضمين التغريدة

سيكون من الرائع حقًا أن يكون لديك إصدار حيث يأتي كل شيء معًا عند المستوى 2.0 أولاً - هذه هي النقطة التي كان من المفترض أن يصبح فيها كل شيء أسهل في النقل! أنا أتحدث باسم منظمة واحدة فقط ولكن "2.0 سيكون إصدار LTS ؛ 3.0 سوف يسقط netfx" سيكون في الأساس عملًا كالمعتاد بالنسبة لنا بدلاً من سبب FUD.

لماذا تحتاج إلى ASP.NET Core 2.0 (لا تنسى .NET Standard و .NET Core 2.0)؟

لا نحتاج بشكل خاص إلى الميزات الموجودة في asp.net core 2.0. أرغب كثيرًا في الحصول على أبسط عمليات البناء والتشغيل المتداخل الذي يأتي مع الموجة 2.0 .. هل سيكون asp.net core 1.1 ، إذا كان يعمل على netcoreapp2.0 ، قادرًا على استخدام مكتبات netstandard2.0؟ هل يعتبر ذلك سيناريو "قياسي" ومدعوم وليس شيئًا لا يختبره أحد أو ينتبه إليه؟

بشكل أساسي ، إذا أصبح 1.1 LTS ، فأنا قلق بشأن إغلاق المشكلات بعد ثمانية عشر شهرًا من الآن بـ "حسنًا ، يمكنك القيام بذلك باستخدام 2.0 apis" ..

لا نحتاج بشكل خاص إلى الميزات الموجودة في asp.net core 2.0. أرغب كثيرًا في الحصول على أبسط عمليات البناء والتشغيل المتداخل الذي يأتي مع الموجة 2.0 .. هل سيكون asp.net core 1.1 ، إذا كان يعمل على netcoreapp2.0 ، قادرًا على استخدام مكتبات netstandard2.0؟ هل يعتبر ذلك سيناريو "قياسي" ومدعوم وليس شيئًا لا يختبره أحد أو ينتبه إليه؟

بالطبع سيعمل ذلك. كما كنت أقول طوال الوقت ، تم فصل الأشياء الثلاثة تمامًا اليوم. فيما يلي نموذج لمشروع يستخدم ASP.NET Core 1.1 على .NET Core 2.0 باستخدام إصدار System.Configuration APIs التي تم نقلها إلى حزمة .NET Standard 2.0:

https://github.com/davidfowl/AspNetCore1OnNetCore2

سأكون أكثر سعادة لقبول هذا إذا كانت هناك طبقة توافق تلقائي بين .NET Core و .NET Framework (ليست الطبقة الحالية التي يمكنها طرح استثناءات في وقت التشغيل ، وليس مكالمات WebAPI الداخلية ذاتية الصنع) - نوع من الغلاف ("WowNET"؟) التي من شأنها أن تجبرنا على الاحتفاظ بالشفرة المعتمدة على 4.6 في ملفات dll. منفصلة ولكنها تسمح بتشغيل الإرث على حساب الأداء (وهو الأمر الذي لا يمثل مصدر القلق الرئيسي في حالة تطبيقات LOB). هل تعتقد أن هذا سيكون ممكنًا من الناحية الفنية؟

أتساءل أيضًا عما إذا كان هذا التغيير يعني أن الإطار الكامل نفسه يقترب من نهاية العمر الافتراضي ولن يؤدي أي دور مهم آخر غير كونه مكونًا قديمًا بمجرد نقل معظم واجهات برمجة التطبيقات إلى .NET Standard.

بشكل أساسي ، إذا أصبح 1.1 LTS ، فأنا قلق بشأن إغلاق المشكلات بعد ثمانية عشر شهرًا من الآن بـ "حسنًا ، يمكنك القيام بذلك باستخدام 2.0 apis" ..

هذا دائما مصدر قلق. الجواب دائما "هذا يعتمد". يتم تقييم إصلاحات الأخطاء وفقًا لذلك ومن المرجح أن تقع الميزات الكبيرة في هذا الدلو في كثير من الأحيان.

تضمين التغريدة

سأكون أكثر سعادة لقبول هذا إذا كانت هناك طبقة توافق تلقائي بين .NET Core و .NET Framework (ليست الطبقة الحالية التي يمكنها طرح استثناءات في وقت التشغيل ، وليس مكالمات WebAPI الداخلية ذاتية الصنع) - نوع من الغلاف ("WowNET"؟) التي من شأنها أن تجبرنا على الاحتفاظ بالشفرة المعتمدة على 4.6 في ملفات dll. منفصلة ولكنها تسمح بتشغيل الإصدارات القديمة على حساب الأداء (وهو الأمر الذي لا يمثل مصدر القلق الرئيسي في حالة تطبيقات LOB). هل تعتقد أن هذا سيكون ممكنًا من الناحية الفنية؟

Kinda مثل هذا https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root ولكن مع .NET Core و .NET Framework. لقد فعلنا شيئًا مشابهًا جدًا عندما قمنا بدعم ASP.NET لـ Helios ، وهو برنامج .NET Framework الذي تم استخدامه لتعزيز coreclr في IIS. كانت الاختراقات لجعلها تعمل قبيحة جدًا على الرغم من أنها كانت مزيجًا من COM وتمرير الهياكل إلى الطريقة الرئيسية عبر سلسلة [] args. كل ذلك ممكن تقنيًا بالرغم من ذلك. لست متأكدًا من نوع الدقة التي تتوقعها ، لأنهما ليسا نفس وقت التشغيل ولا يمكنك تمرير الكائنات ذهابًا وإيابًا. ستعمل أيضًا على تشغيل 2 GCs و 2 Jits طنًا من dlls في نفس العملية ولست متأكدًا مما تكسبه من القيام بشيء ما خارج proc.

أتساءل أيضًا عما إذا كان هذا التغيير يعني أن الإطار الكامل نفسه يقترب من نهاية العمر الافتراضي ولن يؤدي أي دور مهم آخر غير كونه مكونًا قديمًا بمجرد نقل معظم واجهات برمجة التطبيقات إلى .NET Standard.

بعيد عن. يتطور .NET Framework ويتم شحنه بوتيرة Windows لأنه أحد مكونات Windows. لقد أصدرنا للتو .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) بالإضافة إلى مجموعة من الميزات الجديدة. الحقيقة هي أن NET Core يمكنه الشحن بشكل أسرع وسيشحن بشكل أسرع لأنه غير مرتبط بأي شيء آخر ، لذا ستظهر واجهات برمجة التطبيقات وميزات وقت التشغيل وما إلى ذلك هناك أولاً. هذا لا يعني أن الأشياء لن تشق طريقها في النهاية إلى .NET Standard و .NET Framework. سيستغرق الأمر وقتًا أطول للوصول إلى هناك. حقيقة أن يتم تحديث .NET Framework في مكانه هو سبب توخي الحذر الشديد عند نقل التغييرات. يمكن لأي تغيير كسر أي تطبيق عند دفع التحديث تلقائيًا إلى مليار جهاز 😉. باستخدام .NET Core ، يكون إطار العمل جنبًا إلى جنب ، لذا تحتاج التطبيقات إلى الاشتراك في الإصدار الأحدث للحصول على ميزات أو إصلاحات أحدث. هناك الكثير من الحرية هناك.

فقط للتوازن مع مكتبات net4x التي نستخدمها حاليًا في ASP.NET Core 1.x ، لن يعمل ذلك في 2.0: EntityFramework 6. يحتوي EFCore فقط على العديد من الميزات المفقودة التي نستخدمها (على سبيل المثال خطافات الاعتراض / دورة الحياة). لذلك نحن عالقون في EF6 لبعض الوقت.

ووفقًا لما نشرتهPinpointTownes ، فإن EF6 لا تعمل مع الإصدار الحالي (قيد التطوير) من ASP.NET Core 2.x.

nphmuller ثم ستستمر في استخدام ASP.NET Core 1.x حتى يتم نقل المزيد من التبعيات (لا أعرف عدد الأشياء التي تحتاجها من EF Core وما هي الحالة).

davidfowl بالتأكيد ، إذا لم تمر نافذة الدعم من ASP.NET Core 1.x خلال ذلك الوقت.
السمة الرئيسية هي الاعتراض (خطافات دورة الحياة). يمكن حل الميزات المفقودة الأخرى بسهولة أكبر بالنسبة لنا. الاعتراض متراكم ، لكنه غير مرتبط بالإفراج. وأخبرني حدسي أنه لن يتم تنفيذه لفترة من الوقت.

gulbanana : أعتقد أننا كمجتمع نستخدم نواة .net من أجل استخدام asp.net الأساسية ، وليس لمزاياها الخاصة.

تتحدث عن نفسك. هناك عدد منا ممن تتمثل الفائدة الأساسية لـ .NET Core بالنسبة لهم في التخلص من Windows على الخادم.

وأفترض ، كل الهيبيين القذرين الذين يمتلكون أجهزة Mac. 😝

bradwilson ، وأفترض ، كل الهيبيين القذرين الذين يمتلكون أجهزة Mac.

تحدث عن نفسك ، البعض منا ليس من الهيبيين ؛ P

لكن نعم ، الهروب من Windows (أو IIS و http.sys حقًا) هو ما أريده. NET Core لنشر xcopy جنبًا إلى جنب ، perf ، إلخ.

إن عزل التعليمات البرمجية القديمة في خدمات منفصلة أو النقل إلى ASP.NET Core يؤتي ثماره لأسباب أخرى غير الجديدة والبراقة.

PinpointTownes هو خطأ مرجعي ، ماذا يحدث إذا أشرت إلى System.Configuration وفقًا لـ https://github.com/aspnet/Home/issues/2022#issuecomment -299810945؟ يقول EF6 أنه لا يحتوي على تبعيات نظرًا لوجود كل شيء في حزمة GAC / Full Framework

benaadams و PinpointTownes سبب فشلها هو أن System.Configuration.ConfigurationManager ليس اسم DLL الذي يتوقعه .NET Framework. لست متأكدًا مما إذا كان منفذ System.Configuration صالحًا أم لا.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

نعم ، أن تكون قادرًا على تشغيل خوادم بخلاف Windows يعد أمرًا رائعًا وسحبًا كبيرًا .. ولكن بدون asp.net core ، ما الذي يمكنك تشغيله عليها ؟ حتى نانسي لـ. net core تعتمد على asp.net core عبر kestrel ، UseOwin () ، إلخ.

لقد قمت بإنشاء العديد من الخدمات المصغرة التي لا تستخدم ASP.NET Core. إنها أشياء مثل عمليات العمال التي تستقصي طابورًا للقيام بعملها.

هذا ليس عدلاً ، نحن نتبع خرائط الطريق ولم تقل شيئاً عن ذلك من قبل !!
إذا قلت ذلك من قبل ، فلن نستخدم ASP.NET Core في مشروعنا لأننا نحتاج إلى .NET 4.x Libs.
يتضمن التخطيط لدينا تحديث مشاريعنا إلى ASP.NET Core 2 بسبب الوظائف الجديدة المطلوبة.
نحتاج إلى ASP.NET Core 2 لاستهداف .NET 4.x أيضًا. إذا لم يكن ذلك ممكنًا ، فماذا عن دعم ASP.NET Core 1.x ، هل تخطط لإضافة جميع الوظائف الجديدة إليه أيضًا أو مجرد إصلاح الأخطاء.

يتضمن التخطيط لدينا تحديث مشاريعنا إلى ASP.NET Core 2 بسبب الوظائف الجديدة المطلوبة.

اي واحدة؟

PinpointTownes خطأ مرجعي ، ماذا يحدث إذا أشرت إلى System.Configuration حسب # 2022 (تعليق)؟

إضافة <Reference Include="System.Configuration" /> ليس له أي تأثير (أي تم طرح نفس الاستثناء) ، حيث يبدو أنه لا يمكن حله من GAC (لست متأكدًا من أنه مفاجئ حقًا ، مع ذلك):

لست متأكدًا مما إذا كان منفذ System.Configuration صالحًا أم لا.

لذا فإن الاستنتاج الرسمي هو ... لا يمكنك استخدام مكتبة مكتوبة لـ .NET Framework 4.x على .NET Core إذا كانت تستخدم System.Configuration ؟

PinpointTownes لست متأكدًا حتى من أن إصدار System.Configuration يتم شحنه (النسخة الموجودة في العبوة). ربما يكون الأمر كذلك ، ربما ليس كذلك (هذه مناقشة تبدأ على corefx). أنا فقط أخبرك لماذا كسرت عينتك بهذه الطريقة.

مضيفا ليس له أي تأثير (على سبيل المثال ، تم طرح نفس الاستثناء) ، حيث يبدو أنه لا يمكن حله من GAC (لست متأكدًا من أنه مفاجئ حقًا ، مع ذلك):

AFAIK ، لا يوجد دعم افتراضي لمراجع GAC في مشاريع SDK. راجع https://github.com/dotnet/sdk/issues/987#issuecomment -286307697 لمعرفة كيفية تمكينه.

لذا فإن الاستنتاج الرسمي هو ... لا يمكنك استخدام مكتبة مكتوبة لـ .NET Framework 4.x على .NET Core إذا كانت تستخدم System.Configuration؟

استنتاجي هو أنه يجب عليك فتح مشكلة في CoreFX مع النموذج الذي قدمته أعلاه.

davidfowl شكرا لك على الرد
تم التخطيط لبعض الميزات والمساعدين المطلوبين في EF Core في الإصدار 2.0 خاصةً لتعيين البيانات (تعيينات الأنواع القائمة بذاتها) ...
على أي حال ، أنا بحاجة فقط للحصول على فكرة واضحة حول خارطة طريق ASP.NET Core 1.x ، فريقنا مرتبك وقلق.

الشيء الوحيد الذي أعاني منه شخصيًا هو "النظام الأساسي الثابت" مقابل "الميزات الجديدة". من ناحية ، نريد أن تكون المنصة مستقرة وموثوقة ومتوافقة ، ومن ناحية أخرى لا أحد يريد البقاء على 1.x لأنه لا يحتوي على ميزات 2.x. هل هناك ميزات رائعة في ASP.NET Core 2.x تجذب الأشخاص في هذا الاتجاه أم أنها مجرد حقيقة أن لدينا ميزات أكثر مما كانت لدينا في 1.x (لأنها جديدة ولامعة)؟

davidfowl أعتقد أن SignlarR هي إحدى هذه الميزات ، كان من الممكن أن تكون في مشروعي السابق على الأقل. ومع ذلك ، أعتقد أيضًا أن الكثير من القلق يرجع إلى نوافذ الدعم القصيرة نسبيًا لـ 1.1 (2018؟) إذا تم التأكيد على أنه بإمكان الأشخاص تشغيل ASP.net 1.1 حتى يصبحوا مستعدين للتبديل إلى الأساسي ، مما يعني أنه من المحتمل ، سنوات ، و يتم أيضًا تغطيتها للبقع التي من شأنها تهدئة الناس قليلاً.

أعتقد أيضًا أن دعم asp.net core 1.1 على .net core 2.0 يستحق إبراز المزيد ، فهو يمنح الناس (ما أعتقده) مسارًا جيدًا للترحيل: asp.net 5 على 46> asp.net core 1.x على 46> asp.net core 1.x على .net core 2.0> asp.net core 2 على .net core 2. سيكون هذا مساراً من شأنه أن يقلل من المخاطر التي يقلق الكثير من الناس بشأنها.

لقد كنت أتابع هذا منذ اليوم الأول وحتى بعد كل هذه المناقشات والتوضيحات (شكرًا davidfowl ) أشعر بأن الكثير منا يتم إلقاءه تحت الحافلة.

أنا أفهم سبب الاستغناء عن إطار عمل .NET الكامل / المكتبي. الجحيم ، حتى أنني أوافق على أن هذه هي الطريقة لتمكين ASP.NET ، لكنني فشلت في رؤية كيف يتم تحديد ذلك الآن بدلاً من البداية.

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

لا أرى كيف يتم تحديد ذلك الآن وليس من البداية.

بتخمين:

في .NET Core 1.x ، لا يمكنك تشغيل مكتبات إطار العمل الكامل ، لذلك كان من الممكن أن تكون فترة انقطاع كاملة.

في .NET Core 2.x ، يمكنك في الغالب تشغيل إطار عمل كامل ويمكنك تشغيل مكتبات .NET Standard 1.x - 2.0 ، لذا فهي ليست فاصلًا كبيرًا.

يجب تقديم أي مشكلات تتعلق بتشغيل مكتبات إطار العمل الكامل على .NET Core 2.0 في dotnet / corefx

من الواضح أن السيناريو الرئيسي هو "تطبيقات الويب الحديثة على السحابة" ، والتي غالبًا لا تحتوي على العديد من التبعيات لأطراف ثالثة (أو هي "مجرد تعليمات برمجية").

ركزت معظم المناقشة حتى الآن على توفر BCL ، لكن الكثير منا يعتمد على مكونات الطرف الثالث (تكامل منخفض المستوى مع أنظمة الفيديو والصوت الفرعية المعقدة على سبيل المثال ...) والتي غالبًا ما تكون متخلفة عن .NET Landscape ودائمًا تقريبًا الاعتماد على تقنيات المستوى الأدنى التي ربما لا يتم دعمها في نهاية المطاف.

مع ASP.NET Core 1 ، نعمل على تطوير خدماتنا الحديثة ، واستهداف معيار .NET لـ Libs واختيار النشر على Full .NET أو .NET Core لكل تبعيات الخدمات.

يمكنني الرهان على ذلك لأنه في حالة العثور على ميزات / مكونات غير مدعومة ، يمكننا بسهولة استهداف Full .NET. وكان الرهان على النظام الأساسي طويل المدى ، حيث يبدو أن البقاء على Full .NET يبدو وكأنه قرار يجب تجنبه في غضون بضع سنوات.

_ في .NET Core 2.x ، يمكنك في الغالب تشغيل إطار عمل كامل ويمكنك تشغيل مكتبات .NET Standard 1.x - 2.0 ، لذا فهي ليست فاصلًا كبيرًا.

benaadams هناك فرق كبير بين القدرة على استخدام معظم BCL والقدرة على استخدام المكتبات التي تم إنشاؤها لـ Full .NET (ويمكن داخليًا استخدام ميزات غير مدعومة في .NET Standard 2.0 / type unification).

أعتقد أن هذا القرار ليس له أي تأثير على تسهيل الترحيل إلى ASP.NET Core 2.0 من ASP.NET 4؟
يمكن لعدد قليل جدًا من التطبيقات التي أديرها أن تستفيد حقًا من تحديث ASP.NET Core 2.0 ، ولكن نظرًا لعدم وجود دعم OWIN / Katana لـ ASP.NET Core ، أعتقد أنني بحاجة إلى الترحيل يدويًا وهذا يتطلب الكثير من العمل. اقترح damianh مشابهًا في https://github.com/aspnet/AspNetKatana/issues/27

نحن نعمل على إطار العمل الكامل لأننا نحتاج إلى EF6 (للمكان) وخدمات الدليل وننتظر تطبيق SignalR المناسب (حاليًا يستخدم إصدارًا غير مدعوم ولكنه يعمل). لم أفحص أي حاصرات أخرى منذ فترة ولكن ربما كان هناك المزيد.

كما أفهمها ، سيتم منعنا الآن من الانتقال إلى asp.net core 2.0 والحصول على إشارة عند ظهورها.

لقد كنا على طول الرحلة منذ dnx و RC1 إلى RC2 ومشروع json إلى csproj وأخيراً شعرنا أننا خرجنا من الغابة ... الآن ليس كثيرًا.

يمكنني أن أفهم أن هذا التغيير سيأتي في النهاية ولكن هل هذا هو الوقت المناسب للقيام بذلك عندما تحاول asp.net الأساسية اكتساب قوة دفع؟ أيضًا ، يخبرني حدسي أن EF Core ليست ناضجة بدرجة كافية حتى الآن (وبالتأكيد ليست مكانية) وأي شخص يراهن على الدعم الأساسي يتحمل المزيد من المخاطر فيما يتعلق بتحويل libs .... يبدو أن انتظار إصدار آخر لهذا الانتقال يبدو وكأنه سيعطي بعض الاستقرار وفرصة لـ EF Core والمنافذ الأخرى للحاق بالركب ناهيك عن الإشارة r في الإطار الكامل.

أراهن أن معظم المؤسسات تقوم بتشغيل asp.net core (وهو أمر رائع بالمناسبة) على الإطار الكامل ويمكن أن تكون في وضع مماثل لنا.

بالنظر إلى هذا الانتقال إلى القطار السريع لـ ASP.NET Core ، هل يعني ذلك أنك ستقدم LTS والإصدار الحالي ، وما طول الدعم في هذه الحالات؟

أعتقد أنني في حالة الحظ حيث أعمل على حل جديد لا يحتوي على متطلبات للتشغيل على netfx ، لكن كان من الجيد دائمًا أن يكون ذلك ممكنًا. الشيء الوحيد الذي قد يكون مانعًا بالنسبة لي هو خدمات Windows التي أستهدفها netfx ، ولكن هناك خطة لذلك.

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

يوضح هذا التغيير أنني لست متأكدًا من إعجابي: لا بأس من استهداف تطبيق netcoreapp فقط.

أنا أيضا أردت أن أكتب رأيي.

أعتقد أنه من السابق لأوانه إسقاط إطار عمل .net. لا أعرف ما هي مشكلة دعم .net framework + .net core معًا ، لكنني أعتقد أن هذا القرار سيجعل الانتقال إلى AspNet Core أكثر صعوبة. لأن بعض الشركات تعتقد أن: "لنبدأ AspNet Core مع .net core .. إذا كانت لدينا مشاكل خطيرة (مثل مكتبة ضرورية لا تدعمها في المستقبل) يمكننا دائمًا الرجوع إلى إطار .net". ولكن الآن لن يكون ذلك ممكنًا بعد الآن وستتردد الشركات في البدء باستخدام AspNet Core. أيضًا ، قد يؤدي هذا القرار إلى خفض قيمة .netstandard.

تضمين التغريدة

لأن بعض الشركات تعتقد أن: "لنبدأ AspNet Core مع .net core .. إذا كانت لدينا مشاكل خطيرة (مثل مكتبة ضرورية لا تدعمها في المستقبل) يمكننا دائمًا الرجوع إلى إطار .net".

يمكنك دائمًا استخدام ASP.NET Core 1.1 على الرغم من أنه صحيح؟

أيضًا ، قد يؤدي هذا القرار إلى خفض قيمة .netstandard.

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

بالتأكيد ، يمكنهم استخدام asp.net core 1.1. ولكن ليس من الجيد أن نقول: "أحدث إصدار من ASP.NET Core هو 2.x ولكن يجب عليك استخدام ASP.NET Core 1.x إذا كنت تريد استهداف إطار عمل .net". هذا لا يختلف كثيرًا عن قول "استخدم MVC 5.x" :)

أعتقد أن .net core هو المستقبل (وليس المستقبل ، حتى الآن!) ، ولكن من المبكر التخلي عن إطار .net (سيتم فهم هذا القرار من قبل المجتمع مثل إطار .net أصبح قديمًا).

يمكنك دائمًا استخدام ASP.NET Core 1.1 على الرغم من أنه صحيح؟

لا توجد فائدة واضحة. أولاً ، لم تنضج بعد ، لذا فهي رهان.
ثانيًا ، لن يرغب المطورون في ASP.Net Core في الكتابة بالأدوات القديمة والبقاء في الخلف.
أنا مهتم ببعض الأشياء.

1. نحن نعمل بالفعل في مشروع Greenfield بالكامل في ASP.Net Core و Dapper وما إلى ذلك.
   ولكن في مشاريع أخرى ، يكون منطق العمل لدينا في 4.6 تجميع. كما قرأت أعلاه ، لا ينبغي أن يكون لدينا مشكلة في الرجوع إليها. آمل ، لقد فهمت جيدًا.
2. SignalR. DirectoryServices، MS Orleans، Azure.
3. ربما غير ذي صلة بالمحادثة أعلاه ، لكنني أريد بجنون استضافة ASP.Net Core محليًا مع Kestrel أو HttpListener الأخرى كتطبيق سطح مكتب UWP أو كجسر سطح مكتب في UWP.

يجب أن أقول إنني محبط للغاية من التواصل بشأن هذا. أعتقد أنه يمكننا التعايش مع القرار لكنه جاء من اللامكان.

في يوليو ، بدأ فريقي العمل في مشروع جديد لمدة 12-18 شهرًا والذي سيتم تشغيله على ASP.NET Core 2.0 مع جميع الأشياء الرائعة التي قرأنا عنها لسنوات في .NET Core.

ومع ذلك ، في هذه الأثناء ، لدينا تطبيق ASP.NET MVC Core 1.0 وهو مركز منتجنا القديم الذي يعمل بشكل أساسي كغلاف لاستدعاء مكتبات .NET Framework.

لقد أكدت مع الفريق أن خطتهم كانت ترقية التطبيق إلى ASP.NET MVC Core 2.0 وجعله جزءًا من التطبيق الجديد بينما نتبادل مكونات .NET Framework. نحن الآن عالقون مع ASP.NET MVC Core 1.0 والذي سيتم الانتهاء منه قبل أن ننتهي من المشروع.

قبل أن أنشر رأيي ، أود فقط توضيح جزء واحد.
هل سأكون محقًا في افتراض أنه إذا أردنا متابعة استخدام ASP.NET Core ،
لن نكون قادرين على الإشارة إلى dll هذا الهدف. net 4.5 أو أكبر وجعلهم يعملون كما يفعلون حاليًا؟

@ louislewis2 لا ، هذا ليس صحيحًا. ستتمكن من استخدام مكتبات net45 - net461 ، طالما أنها تبقى ضمن مساحة واجهة برمجة التطبيقات المدعومة مقابل netstandard2.0 . لن تحتاج إلى إعادة تجميع تلك المكتبات.

bradwilson شكرا للتوضيح. هذا بالتأكيد سيجعلني أنام بشكل أفضل الليلة.
العديد من المكتبات ليست تحت سيطرتنا ، لذلك كان من الممكن أن تكون هذه مشكلة كبيرة.

مرتاح جدا الآن :)

shanselmanDamianEdwardsdavidfowl للحصول على قائمة العناصر التي نستخدمها والتي لم يتم نقلها بعد ، ستكون عناصر في system.management dll. نحن نستخدم معرّفات الأجهزة على وجه التحديد ، ويستخدم هذا لإنشاء ارتباط تلقائي لـ Azure Service Bus وخادم الترخيص وحزمة العميل بالكامل. أتخيل أنه مع عدم كونهم واجهة برمجة التطبيقات حاليًا ، فهل يسبب لنا بعض المشكلات الخطيرة؟

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

هذا هو أكبر تعطل لدينا يجعلنا نشغل عددًا قليلاً من تطبيقاتنا في إطار العمل الكامل.

هذا يضعنا في موقف حرج.

أنا في منتصف عملية نقل خدماتنا المصغرة من ASP.Net 4.5 قيد الاستضافة الذاتية إلى جانب Kestrel (أسباب التوافق القديمة) ، إلى ASP.Net Core 1.x. ومع ذلك ، نحن بحاجة إلى تشغيل هذه الأشياء في إطار كامل ، في الوقت الحالي. وهناك أسباب وجيهة لذلك.

لدينا عدد من تبعيات Windows الصعبة والتي تعد بالفعل جزءًا من بنيتنا التحتية ولا تخضع للتغيير. يتضمن ذلك مصادقة NTLM ، وتسجيل سجل الأحداث ، وما إلى ذلك. إذا كان ASP.Net Core 2.x يخرج من الدعم القياسي ، فقد لا أقوم بذلك على الإطلاق. المشكلة هي أنه لا يوجد أي إطار عمل كامل بديل مطور بشكل نشط. كاتانا ميتة وبطيئة (بالمقارنة).

إذا تمكن شخص ما من توجيهي إلى خادم HTTP بنفس سرعة Kestrel لـ .Net Framework ، فحينئذٍ بالتأكيد. لكن هذا غير موجود. لذلك علي فقط أن أقبل أن ASP.Net تترك عملاء الإنتاج الفعلي مثلي وراء هذا التغيير.

إذا كان المكدس يحتاج إلى كل الأشياء الجيدة الجديدة ، مثل خطوط الأنابيب و Span ، فيجب توفيرها على أنها libs القياسية. ما هي واجهات برمجة التطبيقات (API) التي يستخدمها ASP.Net Core 2.x والموجودة في netcoreapp2.0 غير الموجودة في netstandard2.0 ، ولماذا لا يمكن إنشاء واجهات برمجة التطبيقات (API) هذه في netstandard2.0 امتداد libs في هذه الأثناء؟

هل نقول بجدية أن MS أمضت عامين في العمل على معيار (صافي) عبر جميع أطر عملهم فقط للالتفاف وإصدار منتج رئيسي لا يستخدم هذا المعيار؟

أعتقد أن فريق GitHub سيضيف ميزة ترقيم الصفحات لقسم المشكلات بسبب هذه المشكلة.

تضمين التغريدة

أنا في منتصف عملية نقل خدماتنا المصغرة من ASP.Net 4.5 قيد الاستضافة الذاتية إلى جانب Kestrel (أسباب التوافق القديمة) ، إلى ASP.Net Core 1.x. ومع ذلك ، نحن بحاجة إلى تشغيل هذه الأشياء في إطار كامل ، في الوقت الحالي. وهناك أسباب وجيهة لذلك.

يمكنك الاستمرار في استخدام ASP.NET Core 1.x ، أليس كذلك؟

إذا كان المكدس يحتاج إلى كل الأشياء الجيدة الجديدة ، مثل خطوط الأنابيب و Span ، فيجب توفيرها على أنها libs القياسية. ما هي واجهات برمجة التطبيقات (API) التي يستخدمها ASP.Net Core 2.x والموجودة في netcoreapp2.0 غير الموجودة في netstandard2.0 ، ولماذا لا يمكن إنشاء واجهات برمجة التطبيقات (API) هذه في netstandard2.0 امتداد libs في هذه الأثناء؟

عندما تظهر واجهات برمجة التطبيقات في .NET Standard غير الموجودة في .NET Framework ، كيف ستستخدمها؟

يارب احفظها

يمكنك استخدام ASP.NET Core 1.x لهذا الحق؟ ما هي ميزات ASP.NET Core 2.0 التي تحتاجها؟ هل هو مجرد SignalR؟

احتفظ بالتطبيق كما هو خلال العامين المقبلين ولكن استبدل مكتبات .NET Framework بمكافئ NET Core الخاص بها عند الانتهاء. هذا من شأنه أن يبقي منطقنا التجاري وما إلى ذلك مشتركًا بين التطبيقين.
لا يمكننا القيام بذلك لأن يوليو 2018 هو الموعد النهائي لدعم ASP.NET MVC Core 1.0.

مرة أخرى ، في عالمي الافتراضي ، نطيل عمر 1.x

قم بترقية التطبيق إلى ASP.NET MVC Core 2.0 واجعله جزءًا من التطبيق الجديد أثناء تبديل مكونات .NET Framework.
لا يمكننا القيام بذلك أيضًا ، نظرًا لأن Core 2.0 لا يدعم .NET Framework ، لذا فهو كل شيء أو لا شيء.

هل تحتاج بالفعل إلى ASP.NET Core 2.0؟ أو NET Core 2.0 فقط؟

عندما تظهر واجهات برمجة التطبيقات في .NET Standard غير الموجودة في .NET Framework ، كيف ستستخدمها؟

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

تضمين التغريدة
سوف أتحرك في ASP.Net core 2.0. ليس لدي حل آخر. لا أستطيع أن أقول للفريق للبقاء وراء التطور ، لقد انتظرنا لوقت طويل ASP.Net Core.
بقدر ما ليس لدينا مشاكل مع منطق عملنا 4.6 تجميعات المراجع.
أحتاج إلى SignalR و DirectoryServices وليس مشاكل مكتبات Azure / Amazon و MS Orleans.
قد لا يكون ذلك أيضًا ذا صلة بالمحادثة أعلاه ، لكني أريد أن يستضيف تطبيق سطح المكتب ASP.Net Core محليًا مع Kestrel / HttpListener كتطبيق سطح مكتب UWP أو كجسر سطح مكتب في UWP.
لا يمكننا إعادة كتابة رمز XAML ولا أرغب في استخدام Electron.

يمكنك الاستمرار في استخدام ASP.NET Core 1.x ، أليس كذلك؟

لأي إطار زمني؟ لا يمكنني رؤية شيء مثل Event Log جعله على شبكة الإنترنت.

عندما تظهر واجهات برمجة التطبيقات في .NET Standard غير الموجودة في .NET Framework ، كيف ستستخدمها؟

هل هذا شيء؟ يبدو أن netstandard20 لا يزال يعمل على net461 وفقًا للمستندات. هل تقول أن واجهة برمجة التطبيقات وفقًا لـ netstandard20 ليست كاملة بما يكفي لتنفيذ الأشياء الجيدة الجديدة؟ أو ، هل هناك خطة ما لتجاوز المعايير القياسية التي لم يتم الكشف عنها بعد؟

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

يمكن كتابة المكتبات فوق المعيار. عندما تحتاج الأشياء في المعيار نفسه إلى التغيير ، فسوف يستغرق الأمر وقتًا أطول ليتم اعتماده في جميع تطبيقات .NET والتي تتضمن .NET Framework. يمكن أن تعني أمرين:

• سوف يتم تطوير .NET Standard بمعدل أبطأ تطبيق
• سوف يتطور .NET Standard بوتيرة أخرى وسيكون .NET Framework هو آخر من يلحق بالركب.

بالطبع هذا لا يعني أن المكتبات لا يمكن أن تكتب ضدها ، فهذا يعني فقط أن تلك التحذيرات يجب أن تؤخذ في الاعتبار عند اختيار إصدار .NET Standard الذي تريد دعمه.

قد لا يكون ذلك أيضًا ذا صلة بالمحادثة أعلاه ، لكني أريد أن يستضيف تطبيق سطح المكتب ASP.Net Core محليًا مع Kestrel / HttpListener كتطبيق سطح مكتب UWP أو كجسر سطح مكتب في UWP.

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

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

لدينا خطة تستند إلى التعليقات التي تلقيناها هنا والتي أريد مشاركتها معك قبل نشرها كإعلان في وقت لاحق من هذا الأسبوع مع إصدار 2.0.0-preview1. عندما يحدث ذلك ، سنفتح مشكلة جديدة لتسهيل المناقشة حول تلك الخطة ، ولكن الآن استمر في مشاركة أفكارك وملاحظاتك هنا:

• سيتم تمديد دعم ASP.NET Core 1.x على .NET Framework لمدة عام آخر على الأقل (حتى يوليو 2019). سنعيد تقييم ذلك سنويًا ونلتزم بتقديم إشعار لمدة 12 شهرًا قبل إنهاء دعم ASP.NET Core 1.x (لذلك بحلول يوليو 2018 ، سنعلن ما إذا كنا سنمدّد لمدة 12 شهرًا أخرى حتى يوليو 2020) ( ملاحظة جانبية: is هل شعر أي شخص آخر بالفزع من حقيقة أننا نتحدث عن 2020 بالفعل؟ لا؟ حسنًا ، أنا فقط. )
• سيستهدف SignalR الجديد ويدعم بالكامل على ASP.NET Core 1.x (سيأتي لاحقًا هذا العام)
• سنستمر في تحديث ASP.NET Core 1.x لدعم إصدارات اللغات الجديدة ، وما إلى ذلك كما نفعل مقابل System.Web
• سيتم دعم ASP.NET Core 1.x الذي يعمل على .NET Core 1.x حتى يوليو 2018 (بدون تغيير)
• سيتم دعم ASP.NET Core 1.x الذي يعمل على .NET Core 2+ طالما أن ASP.NET Core 1.x على .NET Framework مدعوم
  
  
  
  • هذا لضمان وجود تداخل دائمًا في ASP.NET Core مدعوم على NET Core مدعوم بينما ندعم التشغيل على .NET Framework ، مما يسمح للعملاء بالتنقل بمرور الوقت مع البقاء على وحدات البت المدعومة
  
  
• دعم NET Core 1.x (كوقت تشغيل) لا يتغير. ينتهي في يوليو 2018. يحتاج العملاء الذين يستخدمون ASP.NET Core 1.x إلى الانتقال إلى .NET Core 2.0 أو استخدام .NET Framework في تلك المرحلة (أو الانتقال إلى ASP.NET Core 2.0 على .NET Core 2.0)
• سنقوم بنقل System.DirectoryServices و System.Drawing إلى .NET Core هذا العام (مدعوم بالكامل ، عبر الأنظمة الأساسية ، معاينة لنظام Windows على الأقل في الصيف)
• تتضمن قائمة الأشياء المراد نقلها إلى .NET Core بعد ذلك حاليًا ServiceBase (لدعم .NET Core Windows Services). لا يوجد جدول زمني حتى الآن بخلاف التالي (من الواضح أن الجداول الزمنية تصبح أكثر واقعية أثناء عملنا في القائمة). سنقوم بالبناء على هذه القائمة مع تقدمنا ​​بناءً على ملاحظات العملاء.
• ليس لدينا خطة حاليًا لنقل System.ServiceModel (WCF من جانب الخادم) إلى .NET Core. قد يستمر تحسين WCF لـ .NET Core وإضافته ميزات بناءً على الملاحظات ، مثل تشفير رسائل HTTP.

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

حتى هذه النقطة ، كانت MS تسوّق NET Core بقوة باعتبارها مستقبل ASP.NET حيث ليس من الواضح ما إذا كان تطوير ASP.NET 4.x قد توقف وما إذا كانت جميع جهود التطوير المستقبلية سيتم استثمارها في ASP.NET Core لذلك سيكون هناك الكثير من عمليات الترحيل الجارية للحفاظ على أنظمتهم محدثة. سيشعر الكثير من الأشخاص وكأنهم قد تم إلقاؤهم تحت حافلة إذا كان ذلك في نهاية المطاف نتيجة لجميع جهودهم التي قاموا بترحيلها بشكل فعال إلى منصة EOL'ed. سيؤدي ذلك إلى الإضرار بكلتا المؤسستين بالإضافة إلى المطورين / الاستشاريين الذين كانوا أكبر المناصرين لبدء الانتقال إلى .NET Core. قد لا يحتاجون إلى أي شيء من ASP.NET Core 2.0 الآن ، لكنهم بالتأكيد يريدون أن يكون لديهم بعض الفسحة لأنظمتهم وأن يكونوا قادرين على الوصول إلى بعض الميزات الجديدة لجميع جهودهم.

لا أفهم أيضًا سبب اعتبار الكود "القديم" الحالي مسؤولية عندما يجب اعتباره IMO أحد أعظم أصول .NET ، ولن يكون NET Core قريبًا من كونه جذابًا إذا لم يكن قادرًا على تشغيل مكتبات .NET الحالية . لا تزال Java قوية جدًا بسبب النظام البيئي الضخم والمستقر لـ JVM والذي يعد أكثر أهمية من الضعف المتأصل في اللغة نفسها.

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

هل سيكون هناك الكثير من الجهد للتركيز على إصدار مستقر / متوافق من ASP.NET Core 2.0 ، ثم الإعلان عن مستقبل NET Core فقط للإصدارات اللاحقة؟ يبدو أن هذا هو الشيء العادل الذي يجب القيام به في هذا الموقف نظرًا لأنه لم يكن متوقعًا تمامًا.

DamianEdwards شكرا للتحديث وخطة واضحة. أنا لا أتفق مع ذلك ، لكنني ما زلت أقدر لك طرحه.

لا تزال هناك فجوة أساسية ضخمة هنا. المنفذ إلى 1.x هو منفذ جانبي بالكامل تقريبًا ، وهناك ميزات قليلة فيه بالنسبة لنا. 2.x هو المكان الذي توجد فيه بعض الترقيات الجديرة بالاهتمام وما زلنا لا نضمن إمكانية قيامنا بهذه الخطوة. هناك فرصة كبيرة لأن ننفق قدرًا كبيرًا من الوقت والمال والجهد في النقل إلى 1.x فقط لكي تقطعت بهم السبل هناك بسبب تبعيات إطار العمل الكامل. لن أقوم بهذه المقامرة مع شركتنا. قد ينتهي بنا الأمر بدعم أقل مما لدينا في ASP.NET 4.x الآن.

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

أتمنى مخلصًا أن تعيد النظر في هذا القرار. آمل أن نتمكن يومًا ما من جعل Stack Overflow تستفيد من آلاف الساعات الشخصية التي خصصناها للمساعدة في تطوير منصة .NET Core.

تضمين التغريدة

هناك فرصة كبيرة لأن ننفق قدرًا كبيرًا من الوقت والمال والجهد في النقل إلى 1.x فقط لكي تقطعت بهم السبل هناك بسبب تبعيات إطار العمل الكامل.

خلال هذا الموضوع ، قمت باستدعاء System.DirectoryServices كأحد الأشياء الأساسية. أفترض أن لديك بعض التبعيات التي تعتقد أنها ستستغرق وقتًا طويلاً لتتحرك أو تلك التي لن يتم نقلها أبدًا. إذا كان الإصدار 2.0 من .NET Framework مدعومًا ، فهل ستنتقل هذه التبعيات في غضون عام؟

2.x هو المكان الذي توجد فيه بعض الترقيات الجديرة بالاهتمام وما زلنا لا نضمن إمكانية قيامنا بهذه الخطوة.

اي واحدة؟ سيكون من الجيد معرفة ذلك لأننا كنا نناقش إعادة نقل بعض الأشياء المهمة إلى ASP.NET Core 1.1 لتسهيل الانتقال.

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

لا أعرف أي شيء عن stackoverflow.com ولكن هل من الممكن فصل القطع (لا أريد أن أقول "الخدمات الصغيرة") بحيث يمكن استخدام ASP.NET Core لبعض الأجزاء؟

تضمين التغريدة

سيؤدي ذلك إلى الإضرار بكلتا المؤسستين بالإضافة إلى المطورين / الاستشاريين الذين كانوا أكبر المناصرين لبدء الانتقال إلى .NET Core

هل تقصد ASP.NET Core؟ أو NET Core؟

davidfowl كنت أعني ASP.NET Core ، ولكنه يؤثر أيضًا على المطورين الذين كانوا يخططون لترحيل مرحلي من ASP.NET Core / .NET 4.x أولاً ثم .NET Core لاحقًا.

بالحديث عن ذلك ، لاحظت أنه لا توجد مكتبات على ASP.NET Core / .NET Core للتعامل مع SAML. لدي مطلب للتعامل مع الدخول الموحّد (SSO) عبر موفِّر هوية تابع لجهة خارجية ، لكنني لا أعرف ما إذا كان ذلك ممكنًا أم لا.

davidfowl لقد قصدت ASP.NET Core ، ولكنه يؤثر أيضًا على المطورين الذين يخططون للترحيل المرحلي من ASP.NET Core .NET 4.x أولاً ثم .NET Core لاحقًا.

لا أفهم لماذا سيكون هذا هو الحال.

أعتقد أن هذه الخطة قد تكون كافية على الأرجح لمؤسستي لتجنب الخروج من النظام الأساسي. الشيء الرئيسي هو وجود فترة أطول مع الدعم (= تصحيحات الأمان) يمكن خلالها إعادة كتابة أجزاء netfx المتبقية أو إزالتها بأي طريقة أخرى. لا يزال كل شيء مشبوهًا وغريبًا من الناحية المفاهيمية. ماذا يحدث إذا أردنا بعد ثلاث سنوات من الآن إنشاء موقع ويب يمكنه استيعاب مستندات Excel أو تضمين خادم ويب في أحد التطبيقات؟ ماذا يحدث لأطر عمل أخرى مثل بناء أورليانز فوق المعيار بدلاً من netcoreapp؟

لا أفهم بجدية سبب إنجاز الكثير من العمل على netstandard2.0 إذا لم تكن جيدة بما يكفي لـ ASP.NET Core لاستخدامها بالفعل.

ماذا يحدث إذا أردنا بعد ثلاث سنوات من الآن إنشاء موقع ويب يمكنه استيعاب مستندات Excel

من الصعب القول. لا يمكنني التحدث باسم الفرق التي تمتلك ذلك ولكن ربما يتم نقله إلى .NET Core وسيعمل عبر النظام الأساسي.

أو لتضمين خادم ويب في التطبيق؟

HttpListener هو جزء من netstandard 2.0.

ماذا يحدث لأطر عمل أخرى مثل بناء أورليانز فوق المعيار بدلاً من netcoreapp؟

الأمر متروك لأطر العمل لتقرر ما إذا كانت تريد العمل على .NET Framework و UWP و .NET Core و mono وما إلى ذلك. إنه اختيار. لا يتم شحن Orleans مع .NET Core. ASP.NET Core يفعل. هذه المنتجات واحدة ونفس الشيء.

ما سيكون قرارًا صعبًا بالنسبة لنا (وعملائنا) لا يتعلق بالمكتبات التي أمتلكها اليوم ، لكن المكتبات التي لا أعرف ما إذا كنت سأحتاج إلى 6 أشهر من الآن. هناك ذيل طويل من المكتبات والأطر التي لا تدعم netstandard حتى الآن. على سبيل المثال ، بعد شهر من مشروع أدركنا أننا بحاجة إلى بعض الميزات في NHibernate التي لم تكن قريبة من ذلك في EF6 ، ناهيك عن EF Core. إذن ما هو خياري هناك - استهداف ASP.NET Core 1.x على .NET بالكامل؟

يبدو أن لدي بعض ApiPort في المستقبل.

إذن ما هو خياري هناك - استهداف ASP.NET Core 1.x على .NET بالكامل؟

نعم.

من الصعب القول. لا يمكنني التحدث باسم الفرق التي تمتلك ذلك ولكن ربما يتم نقله إلى .NET Core وسيعمل عبر النظام الأساسي.

صحيح ، ولكن من المؤكد أنه من اختصاص فريق asp.net أن يقرر ما إذا كان من المفيد توفير الوصول إلى هذا النظام البيئي للمكتبات التي ربما لم يتم نقلها.

صحيح ، ولكن من المؤكد أنه من اختصاص فريق asp.net أن يقرر ما إذا كان من المفيد توفير الوصول إلى هذا النظام البيئي للمكتبات التي ربما لم يتم نقلها.

إن .NET كبير وقديم ، ولا توجد طريقة لا يمكنك أن تتوقع من فريق ASP.NET التحدث فيها إلى أنفاس المكتبات الموجودة في نظام .NET البيئي. إنه غير واقعي. لقد تعلمت للتو ما كان CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) جزءًا من هذا الموضوع وأشك في أنه سيتم نقله ولكن لا يمكنني قول ذلك من أجل بالتأكيد.

يساعد توسيع نطاق الدعم لـ ASP.NET 1.1 على .NET Framework في التخفيف من هذا الأمر قليلاً ، لكنني أعتقد أنه يساعد أيضًا لأن بعض التبعيات ستحتاج إلى عزلها للانتقال بشكل صحيح إلى ASP.NET Core على .NET Core (وهو المستقبل المقصود).

سأترك المكتبات جانبًا حيث تمت مناقشة هذه النقطة بإسهاب بالفعل. في حالتنا (amilia.com ، e-commerce SaaS) ، تعد أدوات الطرف الثالث أداة عرض بالفعل ، ولا يمكننا حتى تشغيل ASP.NET Core على إطار العمل الكامل في الوقت الحالي. أقر بأن هذا لا يبدو كسبب مشروع ، لكنه قيد علينا التعامل معه.

يمكننا ، من الناحية النظرية ، استبدال هذه الأدوات (على سبيل المثال ، أدوات التعريف ، والمراقبة ، وبناء الخوادم ، وما إلى ذلك) ببدائل تدعم NET Core ، ولكن هذا يستغرق شهرين من العمل الذي أفضل إنفاقه على حل المشكلات الأكثر إلحاحًا. سنقوم بالترحيل في النهاية إلى ASP.NET Core / .NET Core ، لكنه الآن هدف متحرك تمامًا.

حتى هذه النقطة ، تم إنشاء توقع بأن ASP.NET Core سيكون قادرًا على الاستمرار في العمل على إطار عمل سطح المكتب ، وبالتالي التحدث إلى نطاق واسع وما إلى ذلك. لا أعرف نوع أوراق الشاي التي من المفترض أن نقرأها لنعرفها أن ذلك كان غير واقعي: /

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

إن .NET كبير وقديم ، ولا توجد طريقة يمكنك أن تتوقع من فريق ASP.NET التحدث فيها إلى أنفاس المكتبات الموجودة في نظام .NET البيئي. إنه غير واقعي

أليس هذا سببًا جيدًا للاستمرار في دعم .NET 4.x؟ يمكن احتواء عبء التوافق / إمكانية التشغيل البيني على منصة .NET 4.x والتي يمكن أن تكون حلاً عمليًا يمكن أن يخفف NET Core من الحاجة إلى التعامل مع libs القديمة وتخفيف الضغط لنقل مكتبات .NET الشائعة الحالية إلى .NET Core ( لمرض التصلب العصبي المتعدد والمؤلفين الخارجيين).

تضمين التغريدة

أليس هذا سببًا جيدًا للاستمرار في دعم .NET 4.x؟ يمكن احتواء عبء التوافق / إمكانية التشغيل البيني على منصة .NET 4.x والتي يمكن أن تكون حلاً عمليًا يمكن أن يخفف NET Core من الحاجة إلى التعامل مع libs القديمة وتخفيف الضغط لنقل مكتبات .NET الشائعة الحالية إلى .NET Core ( لمرض التصلب العصبي المتعدد والمؤلفين الخارجيين).

لهذا السبب تم تمديد عمر ASP.NET Core على 1.1 (وإن لم يكن بشكل دائم). سنقوم بالتأكد من أن SignalR يعمل لأنه تم ذكر ذلك كأحد الأسباب الرئيسية لاستخدام ASP.NET Core 2.0. في الوقت نفسه ، ليس المكان الذي يريد ASP.NET Core أن يكون على المدى الطويل. كان القصد دائمًا هو الشحن كجزء من منصة .NET Core الموحدة.

تضمين التغريدة

حتى هذه النقطة ، تم إنشاء توقع بأن ASP.NET Core سيكون قادرًا على الاستمرار في العمل على إطار عمل سطح المكتب ، وبالتالي التحدث إلى نطاق واسع وما إلى ذلك. لا أعرف نوع أوراق الشاي التي من المفترض أن نقرأها لنعرفها أن ذلك كان غير واقعي: /

لسوء الحظ ، لم يتم التواصل مع ASP.NET Core على .NET Framework كحل لسد الفجوة لتسهيل النقل (وهذا شيء أرسلناه بشكل سيء للغاية). لم يكن القصد منه أبدًا أن يكون نظامًا أساسيًا مدعومًا إلى الأبد وهذا هو الاستنتاج المنطقي إذا كنت ستفترض أن بعض التبعيات لن يتم نقلها أبدًا.

لهذا السبب تم تمديد عمر ASP.NET Core على 1.1 (وإن لم يكن بشكل دائم).

تكمن المشكلة في ما إذا كان هذا كافيًا أم لا ، فالنسخة الحالية قد تمت بشكل أساسي بموسوعة الحياة قبل أن يتم تسليم إصدار متوافق / مستقر.

لا أعتقد أنه يتم النظر في قيمة الاستثمارات الحالية ، فمن سيرغب في بذل كل الجهود للانتقال إلى منصة EOL؟ سيعمل المطورون على أنظمة البنية التحتية الحالية الخاصة بهم إلى أجل غير مسمى ، ويتم إخبارهم أساسًا بأن مهارات ASP.NET v4.x الحالية ستصبح قديمة ولن يتمكنوا من الانتقال إلى نموذج تطوير ASP.NET Core الجديد بسبب. يتم إسقاط دعم NET 4.x وسيكون من غير المسؤول بالنسبة لهم التفكير أو التوصية بالترحيل إلى نظام أساسي مسدود.

تضمين التغريدة

لسوء الحظ ، لم يتم التواصل مع ASP.NET Core على .NET Framework كحل لسد الفجوة لتسهيل النقل (وهذا شيء أرسلناه بشكل سيء للغاية). لم يكن القصد منه أبدًا أن يكون نظامًا أساسيًا مدعومًا إلى الأبد وهذا هو الاستنتاج المنطقي إذا كنت ستفترض أن بعض التبعيات لن يتم نقلها أبدًا.

الأخطاء تحدث ، فلا بأس. تكمن المشكلة الآن في أن العديد من الأشخاص قاموا بهذا الافتراض ولذا فهم يستخدمون ASP.NET Core فقط بسبب استنتاجهم المنطقي ولكن الخاطئ. سنرى فقط كم ، أعتقد: /

أنتظر asp.net core 2 / .net core 2 لفترة طويلة ، لكن النتيجة محبطة للغاية.

تضمين التغريدة

لا أعتقد أنه يتم النظر في قيمة الاستثمارات الحالية ، فمن سيرغب في بذل كل الجهود للانتقال إلى منصة EOL؟

ألا يمكن إجراء نفس الحجة حول كون ASP.NET Core 2.0 هو EOL على .NET Framework العام المقبل عند إصدار 3.0؟ إذا كنت تقول إن العام ليس كافيًا على ASP.NET Core 1.1 ، فلماذا تقترح أن يكون العام على ما يرام في ASP.NET Core 2.0؟

سيعمل المطورون على أنظمة البنية التحتية الحالية الخاصة بهم إلى أجل غير مسمى ، ويتم إخبارهم أساسًا بأن مهارات ASP.NET v4.x الحالية ستصبح قديمة ولن يتمكنوا من الانتقال إلى نموذج تطوير ASP.NET Core الجديد بسبب. يتم إسقاط دعم NET 4.x وسيكون من غير المسؤول بالنسبة لهم التفكير أو التوصية بالترحيل إلى نظام أساسي مسدود.

من تم إخباره بأن مهارات ASP.NET 4.x ستصبح قديمة؟ إذا كان هناك أي شيء نأمل ألا يكون كذلك. يناقش MVC على وجه الخصوص توافق المفهوم مع بعض الميزات الجديدة. يبدو ASP.NET Core كثيرًا مثل Katana (وهذا ليس عن طريق الخطأ). إذا كنت تتحدث عن نماذج الويب ، فماذا عن MVC؟

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

xyting هل يمكنك توضيح؟

تضمين التغريدة

ألا يمكن إجراء نفس الحجة حول كون ASP.NET Core 2.0 هو EOL على .NET Framework العام المقبل عند إصدار 3.0؟ إذا كنت تقول إن العام ليس كافيًا على ASP.NET Core 1.1 ، فلماذا تقترح أن يكون العام على ما يرام في ASP.NET Core 2.0؟

كنت أفترض منذ وقت طويل أن ASP.NET Core 1.1 كان مجرد حل مؤقت لكل من ASP.NET Core 2.0 و .NET Standard 2.0 والذي سيكون إصدار LTS المستقر والمركّز على التوافق والذي سيعمل على سد الفجوة مع معظم الوظائف الأساسية مفقودة من .NET 4.x - حتى هذا الخيط دمر هذا الافتراض بشكل أساسي. الحفاظ على توافق .NET 4.x مع ASP.NET Core 2.0 ليس أمرًا مثاليًا ، لكنه أفضل بكثير من إنهائه في الإصدار الحالي الذي لم يتوقعه أحد.

من تم إخباره بأن مهارات ASP.NET 4.x ستصبح قديمة؟ إذا كان هناك أي شيء نأمل ألا يكون كذلك.

تقوم MS بكل تسويقها القوي على .NET Core مع جميع الإعلانات والميزات الجديدة التي يبدو أنها تركز على ASP.NET Core. هل يتم تطوير ASP.NET WebForms / MVC القديم في العراء؟ ما هي نسبة جهود التطوير التي يتم استثمارها في ASP.NET WebForms / MVC القديم مقابل .NET Core؟ ليس لدي أي فكرة ، كل شيء رأيته مؤخرًا ، يبدو أن جميع عمليات الوقوف الأسبوعية ، ودروس الفيديو تركز فقط على ASP.NET Core. أعلم أنني بالتأكيد لن أشعر بالراحة عند بدء مشاريع جديدة جديدة باستخدام ASP.NET WebForms القديمة أو تقنية MVC.

إذا كنت تأمل ألا يكونوا مصابين بمرض التصلب العصبي المتعدد ، فعليك بالتأكيد توصيل ذلك بشكل أفضل من خلال خرائط طريق واضحة. بالنظر إلى مدى تقلب ASP.NET في السنوات القليلة الماضية (هذه المشكلة هي مثال مثالي) ، من المستحيل معرفة ما هو المستقبل بدون التزام وإعلان رسمي.

هل يشعر أي شخص آخر أنه كان من الأفضل عدم تشغيل الإصدار 1 في إطار عمل كامل؟ لم أكن أتوقع ذلك بسبب التسمية. الآن بعد أن فعلت ذلك وتذوقت ، أشعر بخيبة أمل لأنني أفقدها.

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

بعد أن أنام عليها يمكنني القول أن استخدامنا سيكون جيدًا ، يجب أن تعمل التبعيات التي نحتاجها جميعًا على الإصدار 2.0.

في الوقت نفسه ، ليس المكان الذي يريد ASP.NET Core أن يكون على المدى الطويل. كان القصد دائمًا هو الشحن كجزء من منصة .NET Core الموحدة.

على الرغم من أنه لا يتطلب الأمر روحانيًا لمعرفة أن NET Core هو النظام الأساسي لمستقبل .NET ... إذا كان القصد من البداية (أو كما تقول "دائمًا") هو الجمع بين ASP.NET Core. NET core ، هذا بالتأكيد لم يتم توصيله بأي وسيلة رأيتها على الإطلاق.

لقد رأيت حرفيًا كل دقيقة من كل موقف ASP.NET واحد (بما في ذلك Hanselman و Glenn لاستكشاف الأخطاء وإصلاحها Docker لمدة 3 ساعات ... لأنني لا أملك حياة) ، قرأت المدونات ، أنا دائمًا على Twitter ، أذهب إلى أكثر من مؤتمرين سنويًا ، وحضور مجموعات المستخدمين ، وما إلى ذلك ، ولم أسمع أبدًا عن هذا التواصل باعتباره هدف ASP.NET Core. بدلاً من ذلك ، سمعت مرارًا وتكرارًا "إنه يعمل على كلا النظامين" ، وبحق ، يشعر الناس وكأن شخصًا ما سحب الكرسي من تحته. لقد أعطيت حتى محادثات حول ASP.NET Core وقلت "إنه يعمل على كلا النظامين الأساسيين" بنفسي ، والآن أشعر بالذنب لأي شخص قمت بقيادته إلى هذا المسار. أود أن أقول إن الأشخاص الذين من المحتمل أن يكونوا ITT على حافة النزيف وسيكونون الأكثر قبولًا لهذا النوع من الأخبار ، وهناك الكثير من ردود الفعل العكسية هنا. يبدو أن هذا سيزداد سوءًا مع وصول هذه الأخبار إلى المطورين ومديريهم الذين ليسوا متصلين ، ومن المحتمل أن يكونوا أكثر تحفظًا من هؤلاء.

إلى جانب الافتقار إلى التواصل وقلة الدعم لبعض السيناريوهات ، أعتقد أن الكثير من ردود الفعل العكسية ترجع فقط إلى توقيت هذا الإعلان. NET Core 2 ليس حتى الآن RTM وقد تم اعتباره بالفعل المسار الطويل الوحيد للمضي قدمًا ، وهناك بشكل أساسي قنبلة موقوتة تم وضعها على Full Framework لـ ASP.NET Core. أعتقد أن الكثير من مخاوفنا يمكن إزالتها بمجرد أن يكون لدينا شيء ملموس نلعب به إلى جانب النوادي الليلية.

أعتقد حقًا أن هناك حاجة إلى تجربة أدوات أفضل من "تشغيلها ومعرفة ما إذا كانت تعمل" عند الرجوع إلى net461 + libs من .NET Core 2+ في VS ، لأنني أستطيع بالفعل رؤية هذه الرسالة "يمكننا على الأرجح تشغيل معظم لديك 461+ تجميعًا أيضًا! " سيتم تسويقها حتى الموت. شيء يمكن أن يحلل واجهات برمجة التطبيقات المفقودة لما أشرنا إليه ، ويقدم أخطاء وقت الترجمة ، ويقترح حتى بشكل مثالي nupkgs المتوافقة إذا كانت موجودة (مثل System.Configuration في مثال EF6 أعلاه ... وجعلها تعمل: ابتسامة :). من الواضح أنه لا يمكن تحليل كل شيء في وقت التجميع (يتبادر إلى الذهن سيناريو المعاملة الموزعة المذكور أعلاه كشيء يصعب تحليله مسبقًا) ، ولكن كلما كان ذلك أفضل. شيء يشبه ما فعله Immo هنا مقابل PlatformNotSupportedException وستكون واجهات برمجة تطبيقات net461 المفقودة لـ netstandard2 أمرًا رائعًا .

فقط سنتان. آمل أنني أبالغ في رد الفعل. في النهاية ، يشعر الكثير منا بخيبة أمل ، لأننا نحب ASP.NET Core ، ولا نريد أي شيء يقف في طريقنا لاستخدامه. ❤️

ضم صوتي إلى المخاوف المدرجة بالفعل ، نبدأ مشروع ASP.NET MVC جديد الشهر المقبل وسيكون .NET Framework عاديًا مع ASP.NET MVC ، لأن العميل لا يثق في قيام Microsoft بالشيء الصحيح فيما يتعلق التخطيط على المدى الطويل.

لا تزال مؤسسة العميل تستخدم عمليات نشر Windows 7 وهذا المشروع هو استثناء ، لأن غالبية مشاريع الويب الخاصة بهم تتم بالفعل على UNIX مع Java ، مع استخدام .NET في الغالب على تطبيقات سطح المكتب.

هذا النوع من عدم اليقين يتراكم فقط إلى التاريخ المكسور الذي كان Windows 8 .NET stack و UWP فيه ، مما يزيد من اهتمام CTO بالمنظمة للبحث عن بدائل أكثر استقرارًا لمستقبل .NET.

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

davidfowl من المحتمل أن هذا التغيير سيعمل بشكل جيد مع 99٪ من المشاريع. ولكن تم بيعه على أنه "يعمل على كلا النظامين الأساسيين" و "يمكنك استخدامه مع إطار عمل كامل إذا كان عليك ذلك". كان الجميع يعلم أن إصدار إطار العمل الكامل لـ asp.net core كان مخصصًا للمشاريع التي لا يمكن ترحيلها ، وكان ذلك جيدًا. والناس خططوا مع وضع ذلك في الاعتبار.

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

DamianEdwardsdavidfowl شكرا لتقاسم الخطة.

يعد SignalR على 1.x مصدر ارتياح كبير لاستبدال الإصدار غير المدعوم وأيضًا الأخبار التي تفيد بأن ServiceBase هو التالي في القائمة التالية لأننا نستخدم ذلك أيضًا حاليًا!

نحن نعتمد بشدة على EF6 والمكانية على الرغم من أننا سنبقى عالقين في 1.x حتى نحصل على مجموعة الميزات التي نحتاجها ...

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

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

كما يجب أن أقول إنني أشعر بقليل من البيع عندما كان هذا الشعور منذ البداية يعمل على الإطار الكامل وكان يعظ الزملاء بنفس الشيء. يشرح اختيار التسمية المربك لنواة asp.net.

shanselmandavidfowl أكبر نقطة ألم لدي هي NHibernate. حتى بعد إصدار EF Core ، لا يزال مصمم الخرائط O / R الأكثر تقدمًا وكامل الميزات.

shanselmanDamianEdwards أنا بصدد البدء في التفكير في ترقية موقع من ASP.NET MVC 4 إلى أي إصدار آخر (أنا في حيرة من أمري سواء كان 5 أو واحد). ما زلت بحاجة إلى تشغيل إطار عمل .net الكامل لأنني أشير إلى مكتبات SyncFusion و Telerik. SyncFusion لعرض ملفات PDF و Telerik لإنشاء ملفات word .docx. كما أشار آخرون إلى أنه ببساطة ليس من المعقول أن تكون إستراتيجية Microsoft للتعامل مع هذا "جربها ومعرفة ما إذا كانت تعمل". لا يمكنني ضمان ذلك وسيعمل كل شيء في الإنتاج لأنه يمثل قاعدة رمز كبيرة من تعليمات برمجية تابعة لجهة خارجية.

في حين أن دعم SyncFusion هو دعم جيد جدًا بشكل عام ، فإن دعم Telerik ليس كذلك وسأكون مندهشًا إذا تمكنوا من جعله يعمل مع .net core. ليس لدي أي فكرة عن Apis التي قد يستخدمونها والتي لا يتم دعمها في .net core - وبصفتي مستخدمًا نهائيًا ، فهذه هي النقطة الكاملة لمنتج الطرف الثالث ، فأنا فقط أقوم بتوصيله ويقوم بما يحتاج إلى القيام به.

بصراحة بالنسبة للعميل الذي لا يتعامل مع الأشياء بشكل متكرر (أنا في الغالب أقوم بـ WPF) فإن هذا كله محير للغاية. هناك العديد من الإصدارات المختلفة ، مع العديد من حالات عدم التوافق. كما أشار أحدهم إلى أنه يشبه إلى حد ما UWP XAML - متماثل ولكنه غير متوافق تمامًا مع WPF XAML.

ليس جيدًا للمطورين وهو شيء آخر يتسبب في فقدان المطورين للثقة في Microsoft (واحدة من بين العديد من الأشياء على مدار السنوات القليلة الماضية). يبدو لي أن ASP.NET يجب أن يعمل بالتأكيد على إطار عمل .net كامل ، لأن هناك مكتبة كبيرة من الأدوات التي قد يحتاج الناس إلى استخدامها على الخادم الخاص بهم. في حالتي ، يمكنني بسهولة التحديث إلى إصدار أحدث من إطار عمل. net إذا كنت بحاجة إلى استخدام أحدث عناصر ASP.net إذا كان التحديث مطلوبًا لوظيفة ASP.net الجديدة.

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

... ستيفان

لسوء الحظ ، لم يتم التواصل مع ASP.NET Core على .NET Framework كحل لسد الفجوة لتسهيل النقل (وهذا شيء أرسلناه بشكل سيء للغاية). لم يكن القصد منه أبدًا أن يكون نظامًا أساسيًا مدعومًا إلى الأبد وهذا هو الاستنتاج المنطقي إذا كنت ستفترض أن بعض التبعيات لن يتم نقلها أبدًا.

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

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

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

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

تعتبر فترة السماح .net مصدرًا آخر للمعلومات ، ولكن من المثير للضوضاء أن تظل على اطلاع دائم بما يحدث بالفعل. إنه أمر رائع بالنسبة لمشاركة المطورين وطرح الأسئلة ، ولكنه ليس مصدرًا للأخبار.

يعد Twitter ووسائل التواصل الاجتماعي مصدرًا آخر للمعلومات ، ولكن مرة أخرى تشبه مشكلة github هذه إلى حد ما بحلول الوقت الذي تظهر فيه هناك ، فعادةً ما يكون ذلك بسبب أن شخصًا ما أثار مخاوف بشأن قرار تم اتخاذه بالفعل وفاجأ الناس.

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

لست متأكدًا تمامًا مما أحاول اقتراحه هنا ، ولكن هناك بالتأكيد شيء "مفقود" من التطوير المفتوح لـ .net. تقوم Microsoft بعمل رائع في توفير الموارد والوثائق للمطورين ، ولكن فقط للمنتجات النهائية والأشياء التي تم شحنها. يبدو أن خارطة الطريق ، واجتماعات التخطيط ، وكل شيء يقرر تصميم واتجاه الأطر يتم وراء الأبواب المغلقة ، مع ذكر "شركاء مختارين" من حين لآخر وما شابه. أنا لا أقول أنه يجب بث كل اجتماع وبثه في جميع أنحاء العالم ، ولكن يمكن بالتأكيد أن يكون هناك حل وسط أفضل يتم بموجبه اتخاذ القرارات والأسباب المنطقية وراءها في أقرب وقت ممكن إلى المجتمع ، بطريقة سهلة لأولئك منا الذين يريدون حقًا أن نتابعهم ليهضموا ويبقوا على اطلاع. ربما تكون مدونة مخصصة على MSDN (أو في أي مكان آخر) يتم تحديثها بانتظام عند اتخاذ هذه القرارات.

واحدة من أكبر مشكلاتي مع هذا هو أنه في كل مؤتمر تقريبًا في العام الماضي تم تقديم ASP.NET Core ، قمت بتقديمه مع شريحة توضح أن asp.net الأساسية تعمل على كل من إطار عمل .net و .net core ، فقط ألق نظرة على هذا: اكتشف تطوير الويب باستخدام Microsoft ASP.NET Core 1.0 من Ignite العام الماضي. في حوالي الساعة 7.50 ، سترى الشريحة.

أكبر أدوات العرض بالنسبة لي هي System.DirectoryServices و ServiceBase و EF6 (EF Core ليست جاهزة) و ClosedXML (لإنشاء أوراق Excel).

سيتم تمديد دعم ASP.NET Core 1.x على .NET Framework لمدة عام آخر على الأقل (حتى يوليو 2019). سنعيد تقييم ذلك سنويًا ونلتزم بتقديم إشعار لمدة 12 شهرًا قبل إنهاء دعم ASP.NET Core 1.x (لذلك بحلول يوليو 2018 ، سنعلن ما إذا كنا سنمدّد لمدة 12 شهرًا أخرى حتى يوليو 2020) (ملاحظة جانبية: is هل شعر أي شخص آخر بالفزع من حقيقة أننا نتحدث عن 2020 بالفعل؟ لا؟ حسنًا ، أنا فقط.)

DamianEdwards شكرا لك على هذا الإعلان.

تقوم شركتنا حاليًا بتطوير تطبيقات المؤسسات للعديد من العملاء باستخدام ASP.NET Core 1.1 على .NET Framework 4.6.2. إن سماع أن دعم مجموعة إطار العمل هذا مدعوم حتى عام 2019 على الأقل ، وربما تمديده لعام 2020 يعد مصدر ارتياح كبير .

سننقل System.DirectoryServices و System.Drawing إلى .NET Core هذا العام (مدعوم بالكامل ، عبر الأنظمة الأساسية ، معاينة لنظام Windows على الأقل في الصيف)

هذان هما السببان الوحيدان وراء استهدافنا لـ .NET Framework في الوقت الحالي. إذا تم نقلها بالكامل إلى .NET Core 2 ، فأنا متأكد من أنه يمكننا نقل تطبيقاتنا إلى ASP.NET Core 2 بأمان العام المقبل.

يبدو أن الكثير من ppl قد كسر القاعدة الأساسية لكونك مطور MS - لا تلتزم بأي منتج / مفترق حتى الإصدار الثاني على الأقل.

لكن نعم ، تحدث عن تنفير عملاء مؤسستك! السبب الكامل لاستخدام MS هو التوافق مع الإصدارات السابقة.

غالبية الأشخاص الذين يستخدمون ASP.NET لا يهتمون إذا كان يعمل على نظام Linux. وإذا رأوا منشور مدونة ، بمقارنة سريعة مع ASPNET Core ، فلن يقرؤوا حتى عبر الأنظمة الأساسية السابقة إذا رأوا أنها لا تدعم تراث .NET.

لولكاتس.

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

ومع ذلك ، هذا لا يعني أنه لا يمكن أن يكون هناك ASP.NET Core 3.0 بعد فترة وجيزة والتي ستستهدف netcoreapp2.0 فقط لجميع الأشخاص الذين يعملون على جميع العناصر الجديدة اللامعة الجديدة ويريدون أن يكونوا على المسار السريع.

قد يكون وجود نسختين من ASP.NET Core (2.0 و 3.0) جنبًا إلى جنب أمرًا جيدًا حقًا (لفترة من الوقت على الأقل). قد يسمح ذلك لـ MSFT بالتخلص التدريجي من مكدس MVC 5 الحالي بشكل أسرع ، لأن الإصدار الجديد من MVC سيكون في الأساس ASP.NET Core MVC 2.0 ، والذي سيعمل على .NET بالكامل أيضًا.

أعتقد أن هناك قيمة في تشغيل ASP.NET Core 2.0 بالكامل على net46x من أجل منح الكثير من الأشخاص مسار ترحيل سلس إلى العالم الجديد

ما الذي يجعله أكثر سلاسة من النقل من ASP.NET Core 1.x؟

أعتقد أن العديد من الأشخاص كانوا ينتظرون ASP.NET Core 2.0 و .NET Core 2.0 على أمل أنه سيغلق العديد من الفجوات الحالية ويسمح بالترحيل.

تم تنفيذ الجزء الأكبر من العمل لجعل الأشياء متوافقة في .NET Core 2.0 و .NET Standard 2.0. لا يحتوي ASP.NET Core 2.0 على العديد من الميزات الجديدة. قلنا أننا ذاهبون إلى Backport SignalR إلى ASP.NET Core 1.x (وهو ما بعد 2.0 على أي حال). هل هو مجرد شيء تصور؟

قد يكون وجود نسختين من ASP.NET Core (2.0 و 3.0) جنبًا إلى جنب أمرًا جيدًا حقًا.

هذا ما نفعله مع 1.1 و 2.0 (فقط اقلب الأرقام).

قد يسمح ذلك لـ MSFT بالتخلص التدريجي من مكدس MVC 5 الحالي بشكل أسرع ، لأن الإصدار الجديد من MVC سيكون في الأساس ASP.NET Core MVC 2.0 ، والذي سيعمل على .NET بالكامل أيضًا.

MVC 5 لن يختفي أبدًا ، نحن لا نستنكر أي شيء. سيتم دعمه طالما أن .NET Framework موجود. لا يزال يتعذر عليك تشغيل مشاريع ASP.NET Core داخل خط أنابيب IIS المتكامل (على System.Web) ولا يقوم بنفس الأشياء مثل MVC 5 على System.Web لذا فهو في الحقيقة ليس بديلاً لسيناريوهات معينة .

davidfowl هل سأكون قادرًا على إنشاء تطبيق ASP.NET Core 1.x ، والذي يستهدف .NET بالكامل و netcoreapp2.0 حتى أتمكن من ترحيل تطبيق قديم حالي إلى ASP.NET Core أولاً مع جميع التبعيات net46x والترحيل ببطء تبعية واحدة تلو الأخرى لاستهداف netstandard2.0 حتى يصبح كل شيء على netstandard2.0 والذي سيسمح لي بعد ذلك بترقية تطبيق ASP.NET Core 1.x إلى 2.x (وإسقاط الهدف لـ net46x كجزء من ذلك)؟

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

dustinmoris نعم يمكنك فعل ذلك. الشاغل الرئيسي الذي يواجهه الأشخاص هو ما يحدث إذا لم يتم ترحيلهم إلى ASP.NET Core 2.x قبل انتهاء الدعم في ASP.NET Core 1.x ، إذا كان من الممكن لهم الترحيل على الإطلاق.

alexwiese آه حسنًا ، هذا رائع ، إذن ما الذي نناقشه هنا الآن حقًا؟ بدلاً من مناقشة إطار العمل الذي يجب استهدافه ، يجب أن نناقش فترة دعم ASP.NET Core 1.x ، وهو شيء يمكن لـ MSFT تغييره بسهولة إذا أرادوا :)

تعديل:
DamianEdwards كتب هذا قليلاً في الموضوع:

سيتم تمديد دعم ASP.NET Core 1.x على .NET Framework لمدة عام آخر على الأقل (حتى يوليو 2019). سنعيد تقييم ذلك سنويًا ونلتزم بتقديم إشعار لمدة 12 شهرًا قبل إنهاء دعم ASP.NET Core 1.x (لذلك بحلول يوليو 2018 ، سنعلن ما إذا كنا سنمدّد لمدة 12 شهرًا أخرى حتى يوليو 2020) (ملاحظة جانبية: is هل شعر أي شخص آخر بالفزع من حقيقة أننا نتحدث عن 2020 بالفعل؟ لا؟ حسنًا ، أنا فقط.)

يبدو أمرا جيدا لي. التزم بسنة أخرى من الدعم ثم إعادة التقييم بشكل دوري. من المنطقي تماما بالنسبة لي.

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

إذن ما هي المشكلة الفنية التي منعت ASP.NET core 2.0 على netstandard2.0؟ لا يوجد شيء مستحيل في أرض البرامج ، لذلك لا يمكنك التوصل إلى حل غير قابل للتنفيذ على .NET full (وبالتالي لا يمكن تضمينه في netstandard20). نعم ، هذا يستغرق وقتًا وجهدًا ، ولكن لدي شعور بأنكم جميعًا لم تدركوا حقًا الآثار الجانبية لهذا القرار للمستخدمين ، ما مقدار الوقت / الجهد الذي يتعين عليهم استثماره بسبب هذا.

هذا القرار له جانب سلبي آخر: ASP.NET Core ليس مستهلكًا لشبكة الإنترنت وبالتالي فهو ليس محركًا له. إنه يجعل معيار الشبكة تابعًا ولأن نواة ASP.NET لا تعتمد عليها ، فإن المتابع ذو المعنى القليل: واجهة برمجة تطبيقات .net core 2.0 + هي السطح الذي يجب استهدافه ، حيث أن ASP.NET الأساسية تستهدف هذا السطح ، وليس netstandard2.0.

و ، آسف davidfowl ، أعلم أنك تقصد جيدًا ، ولكن اقتراح ASP.NET core 1.x للأشخاص مرارًا وتكرارًا يظهر أنه ليس لديك حقًا أي فكرة عن الوضع بالنسبة للأشخاص الذين تقترحهم على: لا يمكن للأشخاص الهجرة إلى ASP.NET core 1.x لأنهم لا يعرفون ما إذا كان هناك مسار سلس للخروج منه بدون موعد نهائي ثابت: قد يحتاجون إلى البقاء على هذا النظام الأساسي لفترة أطول مما يعتقدون حاليًا (يجب نقل التبعيات إلخ.). هذا وحده يجعل قرار الانتقال إلى ASP.NET core 1.xa قرارًا يستند إلى أي شيء آخر غير "الوعد" من Microsoft. إنها واجهة برمجة تطبيقات مخصصة للشفرة التي تواجه الإنترنت. إنهم بحاجة إلى معرفة ما إذا كان بإمكانهم تشغيل تطبيق تم إنشاؤه اليوم أيضًا في غضون 3 سنوات لأن Microsoft ستصلح العيوب الأمنية فيه (لإعطاء مثال).

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

لقد أظهرت Microsoft مع هذا الموضوع ، ومع الأسف ، علاقاتها العامة الرهيبة حول هذه المشكلة ، لا يمكنها تقديم هذا التأكيد. وبغض النظر عن مقدار الدوران الذي تحاول تقديمه في الأيام القادمة في \ build ، فقد تعلمنا على الجانب الآخر من السياج أن Microsoft Marketing! = ضمان الأمور ستعمل غدًا.

FransBouma لا أعتقد أنه كان هناك مشكلة فنية ، يبدو أن الدافع لاستهداف netcoreapp2.0 فقط لأن هذا هو المسار الوحيد الذي يمكن لـ MSFT التحرك بأسرع ما يحلو لهم ، وهو أمر جيد لنا بعد الكل ، لأنه يعني أن ASP.NET Core 2.x يمكن أن يتحرك بشكل أسرع بكثير من أي حزم ويب أخرى في عالم .NET من قبل. إذا لم تتمكن من الالتزام بهذا القطار السريع ، فيمكنك البقاء على ASP.NET Core 1.x لفترة أطول (مدعوم حاليًا حتى عام 2019)

FransBouma كما ذكر davidfowl و shanselman أن هناك واجهات برمجة تطبيقات جديدة تمت إضافتها بمعدل سريع في .NET Core ، وسيستخدم ASP.NET Core 2.x بعضها ، وبالتالي الرغبة في استهداف netcoreapp20. إذا كانوا سيضيفون واجهات برمجة التطبيقات هذه إلى netstandard2x ، فسيتعين على .NET Framework والأنظمة الأساسية الأخرى أن تلعب دورًا في اللحاق بالركب ، ومن المعروف أنها بطيئة الحركة.

سأضيف صوتي إلى " هذا جانب جيد من المناقشة". هذا هو السبب:

• الفريق لا يفعل هذا فقط من أجل الجحيم. هناك عدد كبير من الميزات والتحسينات الجديدة جاهزة (أو جاهزة تقريبًا) للتشغيل في .NET Core وهي مفيدة بشكل لا يصدق للأشخاص الذين يبنون تطبيقات الويب الحديثة وواجهات برمجة التطبيقات والخدمات المصغرة ، وينتظرون وصول هذه الميزات إلى Windows .NET Framework الكامل من شأنه أن يؤخر إطلاق سراحه لعدة أشهر.
• العديد من الشكاوى التي أراها في هذا الموضوع هي بعض الاختلاف في "لا يمكنني فعل X في .NET Core 2.0" عندما يكون ما يعنيه الكاتب في الواقع هو _ "لا بد لي من تغيير الطريقة التي أفعل بها X في .NET Core 2.0" _. نعم ، عليك أن تتغير. لا ، هذا ليس بالأمر السيئ. إذا كان لديك جزء صغير من الوظائف المنفصلة في تطبيق ASP.NET MVC الخاص بك والذي يقوم بشيء ما باستخدام ملفات PDF أو ملفات DOCX ، ولا يمكنك العثور على طريقة أفضل للقيام بأي شيء (هل جربت؟) ، فكسر ذلك يتم تشغيل الوظائف في خدمة صغيرة تعمل على .NET بالكامل على Windows Server واسمها واجهة برمجة تطبيقات HTTP من تطبيق .NET Core الخاص بك. لا يعد تحليل التطبيقات ونقل وظائف معينة إلى خدمات صغيرة قائمة بذاتها حلاً بديلاً ، بل إنها أفضل ممارسة للأغراض العامة.
  
  
  
  • ملاحظة: بقدر ما أستطيع أن أقول ، فإن حزم OpenXML تدعم الآن .NET Standard ، لذا فإن العمل مع Word / Excel / أي شيء لا ينبغي أن يكون مستحيلاً.
  
  
• NET Core 2.0 ليس حتى في المعاينة العامة المناسبة حتى الآن ، لذا فإن الشكوى من عدم حصوله على دعم LDAP أو أي شيء يبدو سابقًا لأوانه. إذا ظهرت RTM في Q3 وما زالت هناك طريقة للتفاعل مع AD أو Kerberos أو أي شيء آخر يشتكي بعيدًا (على الرغم من التفكير أيضًا في الترحيل إلى أنظمة المصادقة الحديثة القائمة على الرمز المميز لأنه لم يعد عام 2008 بعد الآن).
• هناك _is_ ترحيل سلس من ASP.NET MVC 4.5 إلى ASP.NET Core 2.0. إنه يسمى ASP.NET Core 1.0 (وأنا أوافق على أنه يجب أن يكون هناك بعض الوعود بالدعم طويل المدى لـ 1.0 في ظل هذه الظروف). يمكنك إنشاء تطبيقات باستخدام 1.0 وتشغيلها على Full .NET في خط أنابيب متكامل ضمن IIS 8.5 على Windows Server 2012 R2 حتى
  
  
  
  • .NET الكامل يلحق بالركب ويمكنك تشغيل ASP.NET Core 2.x عليه ، أو
  
  
  • مهما كانت تقنية الطرف الثالث التي تعتمد عليها ، فهي تدعم .NET Core (أو يمكن استبدالها بتقنية مكافئة تدعم .NET Core).
  
  
• تذكر أنه - في حين أن فريقك قد يكون مُعيقًا بسبب التبعيات الخارجية أو سياسات الشركة الداخلية أو السياسة أو مجرد خمول بسيط - فهناك مئات الآلاف ، إن لم يكن الملايين ، من المطورين في العالم الذين يتطلعون إلى إنشاء تطبيقات وخدمات وواجهات برمجة تطبيقات باستخدام أحدث الأنماط المعمارية والأنظمة الأساسية للتكنولوجيا الجديدة (السحابة / الحافة / إنترنت الأشياء / إلخ) ، والتي يعد ASP.NET Core 2.0 مناسبًا لها. يريدون أن تكون سريعة وقابلة للتطوير ومتعددة المنصات ؛ هذه الأشياء مهمة لكثير من الناس. إن مطالبة Microsoft بتجاهل هذا السوق الآخذ في التوسع بسرعة ، لمجرد أن مورد التحكم التابع لجهة خارجية أو مشروع مفتوح المصدر لم ينقل التعليمات البرمجية الخاصة به حتى الآن ، يعد أمرًا سخيفًا.

dustinmoris الذي يشير إلى أن netstandard يفتقر إلى واجهات برمجة التطبيقات لإنشاء حزمة ويب سريعة. إذا كان الأمر كذلك ، فجميعنا لدينا مشاكل أكبر.

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

لا يعني ذلك أن فريق asp.net الأساسي لا يجب أن يتحرك بسرعة ، بل إنهم يفعلون ذلك بطريقة تتعارض مع افتراضات العديد من الأشخاص عندما انتقلوا إلى asp.net core 1.x.

FransBouma لماذا تعتقد أن لديك فكرة أفضل عما يفعله مستخدمو Microsoft بأشياء Microsoft أكثر من Microsoft؟

تضمين التغريدة

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

لذا ، أخبرني ، لماذا لا تنشئ واجهات برمجة التطبيقات فائقة المخادع هذه كحزم .net القياسية 2.0 ونشرها على nuget؟

لماذا تعتقد أن لديك فكرة أفضل عما يفعله مستخدمو Microsoft بأشياء Microsoft أكثر من Microsoft؟

أوه لا أعلم ، من خلال قراءة المشاركات في هذا الموضوع؟

تضمين التغريدة

يشير إلى أن netstandard يفتقر إلى واجهات برمجة التطبيقات لإنشاء حزمة ويب سريعة. إذا كان الأمر كذلك ، فجميعنا لدينا مشاكل أكبر.

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

لذا فإن السؤال هو ، هل يريد ASP.NET Core 2.x الالتزام بـ netstandard2.0 (الأعلى حاليًا) ومن ثم معرفة أنه عالق مع كل ما تم تحديده هناك ، أو أنه يعمل ASP.NET Core 2.x فقط الالتزام بـ netcoreapp2.x ، والذي يمكن أن يكون أكثر من مجرد netstandard2.0. بعد فترة من الوقت ، أنا متأكد من أنه سيكون هناك شبكة قياسية جديدة مرة أخرى (3.x؟) والتي ستلحق بأشياء لامعة جديدة من netcoreapp ، ولكن هذا سيستغرق وقتًا أطول بكثير ولماذا يجب تعطيل جميع أطر asp.net لإبطاء التقدم . من الجيد أن يكون لديك مكدس ASP.NET Core سريع الحركة حقًا طالما أن هناك أيضًا ثانيًا يمنح الأشخاص دعمًا طويل المدى يلتزم بمعيار الشبكة.

FransBouma أوه ، آسف ، لم أكن أدرك أن حجم عينتك كان كبيرًا جدًا. 257 تعليقًا بانحياز قوي للأشخاص الذين لا يحبون القرار؟ من الصعب أن يجادل في ذلك.

إخلاء المسؤولية: أنا لست خبيرًا في البيانات الضخمة.

davidfowl :

خلال هذا الموضوع ، قمت باستدعاء System.DirectoryServices كأحد الأشياء الأساسية. أفترض أن لديك بعض التبعيات التي تعتقد أنها ستستغرق وقتًا طويلاً لتتحرك أو تلك التي لن يتم نقلها أبدًا. إذا كان الإصدار 2.0 من .NET Framework مدعومًا ، فهل ستنتقل هذه التبعيات في غضون عام؟

نعم ، لدينا أشياء أخرى. خدمات System.Directory هي ما أشرت إليه لأنه حتى مساحة الاسم المطلوبة الأعلى غير جاهزة. كل الآخرين أسوأ حالا. لم يتم تحديث محلل قابلية نقل واجهة برمجة التطبيقات (API) حتى لـ VS 2017 حيث يمكننا تشغيله. المحلل لمعرفة ما إذا كان يمكنك حتى أن يتم الاستثمار فيه ونحن نسقط الدعم بالفعل.

اي واحدة؟

صفحات الحلاقة ضخمة ، لقد ذكرتها عدة مرات.

لا أعرف أي شيء عن stackoverflow.com ولكن هل من الممكن فصل القطع (لا أريد أن أقول "الخدمات الصغيرة") بحيث يمكن استخدام ASP.NET Core لبعض الأجزاء؟

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

اعتقدت أنني شرحت هذا سابقًا ولكن ها هو مرة أخرى:

أي API يشكل جزءًا من معيار الشبكة الذي يحتاج إلى التطور سوف يتطور ببطء. يمكن بناء الأشياء فوق معيار الشبكة ويمكن تشغيلها في أي مكان ، وهذا جيد. في اللحظة التي تحتاج فيها إلى واجهة برمجة تطبيقات جديدة على سبيل المثال ، http client ، أو SSL Stream ، أو Int ، أو String ، أو Array ، أو LINQ أو أي من العناصر الأولية الموجودة في NET Standard ، يجب إنشاء إصدار .NET Standard جديد وتحتاج عمليات التنفيذ للموافقة على أنها ستنفذها. الآن هذه ليست نهاية العالم لأننا نمتلك معظمها الآن ، mono و .NET Core و .NET Framework و UWP ولكن هناك آخرين مثل Unity (وربما آخرين). كل عمود من .NET له إطاره الزمني ودورة الشحن الخاصة به ، وكل منهما منتجات منفصلة خاصة به ولا يمكن تجاهلها.

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

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

DamianEdwards و shanselman ماذا عن نسيج الخدمة واختبارات الوحدة؟

في حالتنا لدينا مشروع خدمة صغير كبير به الكثير من تطبيقات SF التي تعتبر مشاريع أساسية ولكنها تستخدم NET Framework 4.5 حتى 4.6. (شيء ما). لا يدعم SF حاليًا netcoreapp ، لذلك كان علينا استخدام .Net Framework ولكن نظرًا لأننا لم نرغب في التخلف عن الركب ، فقد استخدمنا مشروع .Net Core.

(هناك مشكلة أخرى) نظرًا لأن خدماتنا هي .Net Framework و MS Fakes غير متوفرة لتطبيق netcoreapp ، فإن جميع اختبارات الوحدة لدينا طبيعية (أو يجب أن أقول قديمة). جميع مكتباتنا تقريبًا موجودة على مستوى الشبكة 1.0 إلى 1.6.

مرة أخرى ، تستخدم تطبيقات عملائنا نماذج Xamarin + UWP وتمكنا من استخدام netstandard حتى تتوافق libs الخاصة بنا.

هل هذا يعني أننا عالقون ولن نكون قادرين على الترقية إلى .Net Core 2.0 و netcoreapp2.0 و netstandard 2.0؟

تضمين التغريدة

صفحات الحلاقة ضخمة ، لقد ذكرتها عدة مرات.

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

نعم ، لدينا أشياء أخرى. خدمات System.Directory هي ما أشرت إليه لأنه حتى مساحة الاسم المطلوبة الأعلى غير جاهزة. كل الآخرين أسوأ حالا. لم يتم تحديث محلل قابلية نقل واجهة برمجة التطبيقات (API) حتى لـ VS 2017 حيث يمكننا تشغيله. المحلل لمعرفة ما إذا كان يمكنك حتى أن يتم الاستثمار فيه ونحن نسقط الدعم بالفعل.

فقط تأكد من تصعيد قائمة التبعيات هذه حتى نعرف ما هو مهم.

تضمين التغريدة

هل هذا يعني أننا عالقون ولن نكون قادرين على الترقية إلى .Net Core 2.0 و netcoreapp2.0 و netstandard 2.0؟

كنت تقصد ASP.NET Core 2.0 و؟ NET Core 2.0 و .NET Standard 2.0 لا ينطبقان هنا حقًا.

نعم ، سيتعين عليك البقاء على ASP.NET Core 1.x.

تم تنفيذ الجزء الأكبر من العمل لجعل الأشياء متوافقة في .NET Core 2.0 و .NET Standard 2.0. لا يحتوي ASP.NET Core 2.0 على العديد من الميزات الجديدة. قلنا أننا ذاهبون إلى Backport SignalR إلى ASP.NET Core 1.x (وهو ما بعد 2.0 على أي حال). هل هو مجرد شيء تصور؟

davidfowl أعتقد أنك تقلل بشكل كبير من شأن الخوف الذي يصيب قلب مطور Windows عندما يتم إخبارك أنك ستضطر إلى ترحيل الأشياء. _خاصة_ عندما لا يصل المكدس الجديد إلى تكافؤ الميزات مع المكدس القديم ، ومن غير المعروف ما إذا كان ذلك سيحدث ومتى. هذا هو الإعلان بشكل أساسي عن EOL-ing لـ ASP.NET Core على .NET Framework الكامل. وعلى الرغم من أن هذه ربما لم تكن الخطة طويلة المدى ، فقد تم الإعلان عنها كميزة ، واعتقد الناس أنها قد تستمر لفترة من الوقت. خرائط الطريق تتغير ونحن نتحدث. سوف تكون الاجتماعات.

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

إنني قلق أكثر بشأن هذه الخطوة التي تشير إلى احتمال تهميش .NET Standard أكثر مما أشعر به حيال بقية هذه الخطوة. بدا .NET Standard في البداية وكأنه شيء من شأنه أن يجعل التطبيقات المختلفة أقرب وأقرب إلى تكافؤ الميزات مع السماح للمستهلكين بالانتقال إلى النظام الأساسي المتطور والمتزايد. الآن يبدو الأمر وكأنه لا شيء أكثر من علامة بارزة في ميزات .NET Core. لن تكون قادرًا (أو ترغب في) استهداف الملفات التنفيذية نحو .NET Standard - المكتبات فقط. ويبدو أنه سيكون هناك تخطيط أقل بشكل ملحوظ في .NET Standard ، وبدلاً من ذلك ستحصل على ختم مطاطي بكل ما تم استخدامه في ASP.NET لأنه فات الأوان لتغييره بالفعل. سيكون بالفعل قيد الإنتاج ، بعد كل شيء.

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

أيضا ، هل سيكون هناك ASP.NET جديد لسطح المكتب؟ كل الجعجعة جعلت الأمر يبدو وكأن ASP.NET Core كان ASP.NET الوحيد. يبدو الآن أنك لن تحصل على أي شيء جديد على ASP.NET إلا إذا كنت تستخدم .NET Core. وهذا سيغير الكثير من استراتيجيات العمل. هناك قدر كبير من الالتباس يحدث مع خرائط الطريق.

MVC 5 لن يختفي أبدًا ، نحن لا نستنكر أي شيء. سيتم دعمه طالما أن .NET Framework موجود.

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

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

تضمين التغريدة ماذا تسمي المشروع الأساسي (جديد) مع NET Framework؟ أيا كان ذلك ، فإن ما أفهمه من هذا المنشور هو أن netstandard vNext لن يدعم ذلك.

markrendle نحن عملاء حقيقيون. نحن نقول للناس أن الأشياء لن تعمل. أنا أعرف هندسيتي أفضل منك ، لذا فإن التعليقات المتغطرسة لا تساعد. إلى نقاطك:

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

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

العديد من الشكاوى التي أراها في هذا الموضوع هي بعض الاختلاف في "لا أستطيع فعل X في .NET Core 2.0" عندما يكون ما يعنيه الكاتب في الواقع هو "لا بد لي من تغيير الطريقة التي أفعل بها X في .NET Core 2.0". نعم ، عليك أن تتغير. لا ، هذا ليس بالأمر السيئ. إذا كان لديك جزء صغير من الوظائف المنفصلة في تطبيق ASP.NET MVC الخاص بك والذي يقوم بشيء ما باستخدام ملفات PDF أو ملفات DOCX ، ولا يمكنك حقًا العثور على طريقة أفضل للقيام بأي شيء (هل جربت ذلك؟) ، فكسر ذلك يتم تشغيل الوظائف في خدمة صغيرة تعمل على .NET بالكامل على Windows Server واسمها واجهة برمجة تطبيقات HTTP من تطبيق .NET Core الخاص بك. لا يعد تحليل التطبيقات ونقل وظائف معينة إلى خدمات صغيرة قائمة بذاتها حلاً بديلاً ، بل هو أفضل ممارسة للأغراض العامة.

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

NET Core 2.0 ليس حتى في المعاينة العامة المناسبة حتى الآن ، لذا فإن الشكوى من عدم حصوله على دعم LDAP أو أي شيء يبدو سابقًا لأوانه. إذا ظهرت RTM في Q3 وما زالت هناك طريقة للتفاعل مع AD أو Kerberos أو أي شيء آخر يشتكي بعيدًا (على الرغم من التفكير أيضًا في الترحيل إلى أنظمة المصادقة الحديثة القائمة على الرمز المميز لأنه لم يعد عام 2008 بعد الآن).

قيل لنا إنهم لن يكونوا هناك. مشاهدة الوقوف. أو انظر إلى GitHub حيث يُسمى "المستقبل". نحن نشكو الآن لأن هذا القرار السيئ سيتم شحنه في الربع الثالث.

هناك ترحيل سلس من ASP.NET MVC 4.5 إلى ASP.NET Core 2.0. إنه يسمى ASP.NET Core 1.0 (وأنا أوافق على أنه يجب أن يكون هناك بعض الوعود بالدعم طويل المدى لـ 1.0 في ظل هذه الظروف).

الدعم طويل المدى لا يعني أنه ليس طريق مسدود. لا يزال من الممكن أن نبقى عالقين في 1.x عندما ينتهي العمر. في هذه الحالة ، سيكون لدينا دعم أطول في إطار العمل الكامل.

.NET الكامل يلحق بالركب ويمكنك تشغيل ASP.NET Core 2.x عليه

انها تستهدف netcoreapp ، وهذا لن يحدث.

... أو أيًا كانت تقنية الجهة الخارجية التي تعتمد عليها تدعم .NET Core (أو يمكن استبدالها بتقنية مكافئة تدعم .NET Core).

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

تذكر أنه - في حين أن فريقك قد يكون مُعيقًا بسبب التبعيات الخارجية أو سياسات الشركة الداخلية أو السياسة أو مجرد خمول بسيط - فهناك مئات الآلاف ، إن لم يكن الملايين ، من المطورين في العالم الذين يتطلعون إلى إنشاء تطبيقات وخدمات وواجهات برمجة تطبيقات باستخدام أحدث الأنماط المعمارية والأنظمة الأساسية للتكنولوجيا الجديدة (السحابة / الحافة / إنترنت الأشياء / إلخ) ، والتي يعد ASP.NET Core 2.0 مناسبًا لها. يريدون أن تكون سريعة وقابلة للتطوير ومتعددة المنصات ؛ هذه الأشياء مهمة لكثير من الناس. إن مطالبة Microsoft بتجاهل هذا السوق الآخذ في التوسع بسرعة ، لمجرد أن مورد التحكم التابع لجهة خارجية أو مشروع مفتوح المصدر لم ينقل التعليمات البرمجية الخاصة به حتى الآن ، يعد أمرًا سخيفًا.

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

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

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

لقد كنت أشاهد NET Core ، حيث أشارك وأحول المشاريع الصغيرة من .NET Framework إلى .NET Standard / .NET Core من أجل الحصول على بعض الخبرة مع SDK الجديد ووقت التشغيل ، ولتشغيل هذه المشاريع على macOS و Linux .

هدفي الكبير هو خدمة ويب مؤسسة كبيرة تستخدم كومة من المكونات غير المتوفرة [حتى الآن] في .NET Core 1.0 أو 1.1. وهذا يشمل ، من أعلى رأسي:

• Active Directory ( System.DirectoryServices ) ، يستخدم للمصادقة وإدارة المستخدم
• Entity Framework 6 ( EntityFramework ) ، نظرًا لأن EF Core لا يدعم الكثير من الوظائف التي نستخدمها حتى الآن.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3 ، مكتبة Javascript للعميل التي نستخدمها لا تدعم الإصدار 4 (حتى الآن) و WebAPI OData أكثر تعقيدًا في الإعداد.
• إدارة IIS ( System.Web.Management ) و .NET عن بُعد ( System.Runtime.Remoting ) لقدرة خدمة الويب على ترقية نفسها - على الرغم من أنه يمكن استخراجها إلى تطبيق مستقل.
• SignalR
• مخصص IHttpHandler s و IHttpModule s ، والتي يجب أن تتكيف مع أي ما يعادل ASP.NET Core ، ربما نوع من البرامج الوسيطة
• مجموعة كاملة من العناصر المخصصة باستخدام قابلية توسيع ASP.NET WebAPI.
• أعتقد أننا قد نستخدم Microsoft.TeamFoundationServer.ExtendedClient على الخادم ، والذي يدعم net46 فقط ، ولديه بعض التجميعات الأصلية ، ولديه فرصة بنسبة 0٪ للعمل على .NET Core 2.0.
• إلخ.

نظرًا لحجم هذه الخدمة وتعقيدها ، فإن أي ترحيل إلى NET Core يجب أن يكون تدريجيًا ، وفي جميع الاحتمالات قد نضطر إلى استخدام بعض واجهات برمجة التطبيقات الجديدة في ASP.NET-Core-2.0 ، لا أعرف حتى الآن ، لم نصل إلى هذا الحد.

تعني إزالة القدرة على تشغيل ASP.NET Core على .NET Framework أن عمليات الترحيل يجب أن تتم بأسلوب كبير إذا لم يكن ASP.NET Core 1.x نقطة انطلاق قابلة للتطبيق. نفقد فورًا مرحلة "تشغيل إطار عمل جديد في وقت التشغيل القديم" قبل "تشغيل إطار عمل جديد في وقت تشغيل جديد". هذه استراتيجية إدارة تغيير مروعة لأي نظام كبير.

لا أمانع كثيرًا إذا تم إسقاط دعم .NET Framework بمجرد أن يكون NET Core متساويًا أو قريبًا من التكافؤ ، لكنه لا يزال بعيدًا جدًا عن أي تطبيق متقدم بما فيه الكفاية ، ولا أعتقد أن الإصدار 2.0 هو المكان المناسب للقيام بذلك تغيير جذري.

تضمين التغريدة

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

يتم تشغيل العديد من المكتبات وما إلى ذلك التي يتم مشاركتها عبر التطبيقات هنا. Stack Overflow عبارة عن العديد من التطبيقات (الموقع الرئيسي هو تطبيق واحد بالكامل تقريبًا ، ولكن كشركة: لدينا العديد من الأشياء ذات الصلة والتواصل.

فقط تأكد من تصعيد قائمة التبعيات هذه حتى نعرف ما هو مهم.

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

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

للتسجيل فقط: OData هي مكتبة أخرى لا تدعم netcoreapp حتى الآن.

في الواقع لا يزال يعتمد على System.Web (يجب عليك استخدامه عبر البرامج الوسيطة OWIN في ASP.NET Core) ووعدوا بالدعم (انظر https://github.com/OData/WebApi/issues/939).

لا يزال يستحق الذكر. خاصة أنه من Microsoft.

تحرير: @ yaakov-h كان أسرع بدقيقتين ، لذا +1 لذكره لـ OData

ما زلت هنا أرد لعدة أسباب

• يهمني
• النوم للضعيف 😆
• أحتاج إلى استدعاء FUD لأن شخصًا ما على الإنترنت مخطئ

تضمين التغريدة

يتم تشغيل العديد من المكتبات وما إلى ذلك التي يتم مشاركتها عبر التطبيقات هنا. Stack Overflow عبارة عن العديد من التطبيقات (الموقع الرئيسي هو تطبيق واحد بالكامل تقريبًا ، ولكن كشركة: لدينا العديد من الأشياء ذات الصلة والتواصل.

هذا يعني فقط أنه لا يمكنك استخدام صفحات Razor tbh ، يحتوي ASP.NET Core 2.0 على الكثير من الأشياء الصغيرة ولكن لا توجد ميزات أو إصلاحات كبيرة لا يتم تحويلها أيضًا إلى 1.x. إن موضوع موسوعة الحياة حقيقي للغاية وأنا شخصياً لا أعتقد أن دعم ASP.NET Core 2.0 لـ .NET Framework لمدة عام آخر سيساعد. نحن نناقش حقًا تغيير الاتجاه هنا ، إما أننا ندعم .NET Framework إلى الأبد ، أو لا ، فلا يوجد حقًا في المنتصف.

dustinmoris ليس هذا فقط. هي أيضًا مشكلة توقعات. قد لا تكون حالة الاستخدام الخاصة بك هي نفسها لكل شخص آخر.

أقوم بتطوير تطبيقات aspnetcore 1. * واستخدام .NET لسطح المكتب كوقت تشغيل (LOB للمؤسسات).

وأنا أفهم الفرق بين وقت التشغيل.

كان الترحيل الخاص بي هو aspnet core أولاً (استهداف سطح المكتب .net) لأن التدفق / الرؤية / إلخ ، ودمجها ، وبعد نقلها إلى .net core (إذا كان ذلك ممكنًا) ، كان السيناريو الحاسم في اختيار aspnetcore.

هذه المشكلة غير متوقعة بعض الشيء ، لأنه تم تسويق aspnetcore 1. * دائمًا على أنها "تعمل على كلا الإطارين" ، مع عدم وجود أي تحذيرات بشأن إسقاطها بعد ذلك (الإصدار أو العام).
كنت أتوقع دورة قديمة -> تم إهمالها على الأقل ، أو مجرد ميزات غير مدعومة (لا بأس بذلك).

الجزء الجيد حول .net (و aspnet كخيار لمكدس الويب) هو أنه يمكنني الاستفادة من قاعدة الرموز والمكتبات الموجودة.
بعضها داخلي ، وليس هناك عائد استثمار حقيقي لترحيل هذه ، عندما يكون الهدف (.net core / netstandard) مائعًا للغاية.
بعضها خارجي ، ويصعب تغييره ، إذا لم تعمل هذه في إغلاق netcoreapp2 ، فلا يمكنني استخدامها.

بالإضافة إلى أن فكرتي كانت مواساة لـ netstandard2 وليس netcoreapp2 .
كيف يمكنني البدء في تقييم ترحيل libs إلى netstandard2 ، إذا لم يكن موجودًا بعد؟ من الصعب تقييم الترحيل بناءً على معاينة الأجزاء والوعود (وقد قللت السنوات الأخيرة من ثقتي في استقرار الوعود)

أفهم أنه سيناريو مختلف عن التأسيس بالكامل ، ولكن أيضًا إذا كنت أرغب في إعادة استخدام بعض libs ، لأنني بحاجة إلى التفاعل مع النظام الحالي (excel / pdf / إلخ) ، وليس إعادة كتابة كل شيء من scracth.
أو أضف الخدمات المصغرة كـ rpc فقط لأن هذا هو الاتجاه الأحدث ، لأن الأمر يجعل الأمور أكثر تعقيدًا (هذا اختيار واضح أريد تقييمه وفعله ، ولا أجبر على التفاف libs الموجودة). أحتاج إلى تقديم قيمة (تدفق مطور aspnetcore لطيف ومنتج) ، وليس فقط تغيير البنية.

في تقييمي الشخصي للنظام البيئي ، بالنسبة لحالة الاستخدام الخاصة بي ، فإن توافر .net core و / أو netstandard lib منخفض جدًا (لا يستخدم الجميع فقط nuget.org oss pkgs). لذلك إذا كنت بحاجة إلى الترحيل الصعب إلى مكدس جديد ، فأنا بحاجة إلى تقييم مكدسات أخرى أيضًا (التكلفة / الفائدة / المستقبل / الثقة / إلخ)

أنا لا أكتب فقط تطبيق ويب TODO ، بل أستخدم .NET لأنني أعددت سنوات من العمل ، لذا يمكنني تغيير شيء واحد (في هذه الحالة aspnetcore ، وترك الباقي كما هو لهذا التكرار).
مجرد تغيير كل شيء هو وصفة لكارثة في السيناريو الخاص بي ، وعندما أحتاج إلى القيام بذلك ، أحتاج حقًا إلى البدء في تقييم ما إذا كان من المنطقي الترحيل إلى مكدس آخر (مثل java / node) حيث يوجد lib.

تستغرق عملية الترحيل السلس بعض الوقت ، وأنا أحب الرؤية الخاصة بنواة aspnet المستقبلية. ولكن إذا لم يكن لدي مسار واضح (أو أشك في ذلك) ، فمن الصعب البيع داخليًا.

ومع ذلك ، فإن ترك سطح المكتب .net ، يمكن أن يكون مقامرة جيدة لفريق aspnet للتحرك بشكل أسرع واختيار المزيد من المستخدمين الجدد (أو لا تفقد التيارات إلى العقدة / جافا).
ولكن بالتأكيد ، ستجعل حياة dev على حلقة أبطأ أكثر صعوبة ، وهذا هو استدعاء فريق aspnet (منتجهم).
ملاحظاتي هي عدم القيام بذلك ، والعمل الجاد لدعم مهاجم ، لأنني كمطور ، أحتاج إلى الثقة والاستقرار ، والسنوات الماضية حيث كان هناك القليل من السيولة في النظام البيئي .net (ليس فقط netcore / project.json ، ولكن قبل ذلك كما أن التسويق / المبشر لم يساعد في تقليل الثقة)

@ yaakov- ح

إذا قررت النقل إلى ASP.NET Core (إما 1.x أو 2.x) ، فستحتاج إلى عملية أخرى. لا يعمل ASP.NET Core على System.Web لذا لا يمكنك القيام بمنفذ تدريجي في نفس المشروع.

لا أمانع كثيرًا إذا تم إسقاط دعم .NET Framework بمجرد أن يكون NET Core متساويًا أو قريبًا من التكافؤ ، لكنه لا يزال بعيدًا جدًا عن أي تطبيق متقدم بما فيه الكفاية ، ولا أعتقد أن الإصدار 2.0 هو المكان المناسب للقيام بذلك تغيير جذري.

ليس هناك وقت مناسب لإسقاطها. لم يكن من المفترض أبدًا الوصول إلى التكافؤ مع .NET Framework ومن المحتمل تمامًا وجود تبعيات لديك لن يتم نقلها أبدًا. بالنظر إلى ذلك ، سيكون سؤالي هو ، هل تعيد تصميم التطبيق أم أنك تحتاج بشكل واقعي للبقاء على .NET Framework إلى الأبد؟

davidfowl الذي يعتمد كليًا على تبعياتنا الأولية. في هذا الوقت ، سنبقى على .NET Framework إلى الأبد.

ومن المثير للاهتمام أن معظم الجهات الخارجية لديها إصدارات netstandard متوفرة بالفعل. إن تبعيات Microsoft إلى حد كبير هي التي تبقينا على .NET Framework ، ويبدو أن بعضًا منها شبه مهجور (مثل OData)

تضمين التغريدة أقدر أن هذا تغيير في وقت متأخر من اليوم ، وهذا أمر محبط لأي قسم من المجتمع يتأثر به ، وإذا تأثرت به ، فمن المحتمل أن أثير ضجة أيضًا. أنا لست (حيث أعمل ما زلنا على ASP.NET WebAPI 5.2.3) ، لذا فإن وجهة نظري في الموقف أقل عاطفية.

انظر إلى الأمر بهذه الطريقة: إذا كنت ستبدأ من البداية في إنشاء Stack Exchange التالي (مهما كان ذلك) اليوم ، فلن تكون الأشياء الموجودة في netcoreapp20 التي يريد فريق ASP.NET Core استخدامها ( مثل UTF8Strings and Pipelines and low-التخصيص ، غير المتزامن ، _ fast_ primitives (أعتقد قليلاً هناك)) تجعلها أكثر جاذبية لك من .NET الكاملة؟ ألن يكون .NET Core 2.0 أكثر منطقية بشكل عام من .NET 4.7.1 الكامل؟ إذا كنت تختار بين حزم الويب التي يمكن أن تتطور وتتكيف مع التغيير بسرعة ، مقابل حزم الويب التي ترتبط ارتباطًا وثيقًا بتكنولوجيا أساسية بطيئة الحركة مع ما يقرب من عقدين من الكود القديم للقلق بشأن الدعم ، فماذا ستختار؟

تضمين التغريدة

إنني قلق أكثر بشأن هذه الخطوة التي تشير إلى احتمال تهميش .NET Standard أكثر مما أشعر به حيال بقية هذه الخطوة. بدا .NET Standard في البداية وكأنه شيء من شأنه أن يجعل التطبيقات المختلفة أقرب وأقرب إلى تكافؤ الميزات مع السماح للمستهلكين بالانتقال إلى النظام الأساسي المتطور والمتزايد. الآن يبدو الأمر وكأنه لا شيء أكثر من علامة بارزة في ميزات .NET Core. لن تكون قادرًا (أو ترغب في) استهداف الملفات التنفيذية نحو .NET Standard - المكتبات فقط. ويبدو أنه سيكون هناك تخطيط أقل بشكل ملحوظ في .NET Standard ، وبدلاً من ذلك ستحصل على ختم مطاطي بكل ما تم استخدامه في ASP.NET لأنه فات الأوان لتغييره بالفعل. سيكون بالفعل قيد الإنتاج ، بعد كل شيء.

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

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

نحن نفعل الشيء نفسه ، تذكر ، ما زلنا نستهدف معيار الشبكة لمجموعة من مكتباتنا وتلك التي تحتوي على ifdefs. ومع ذلك ، يستهدف البعض الآخر netstandard من أجل إعدادنا للاستفادة من واجهات برمجة التطبيقات الجديدة في الإطار الزمني 2.x.

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

سؤال صادق (هذا أنا لا أطرح Microsoft) ، هل تفضل التوافق على الميزات الجديدة؟ إذا كانت الإجابة بنعم ، فلماذا تختار ASP.NET Core؟

مجرد فكرة سريعة أخرى: لكل خيط مثل هذا ، يوجد مؤشر ترابط مكافئ ولكنه معاكس حيث تنزعج مجموعة مختلفة - ولكن بنفس الحجم - من الناس تمامًا بسبب التنازل عن دعم .NET "القديم".

ومن المثير للاهتمام أن معظم الجهات الخارجية لديها إصدارات قياسية متاحة بالفعل. إن تبعيات Microsoft إلى حد كبير هي التي تبقينا على .NET Framework ، ويبدو أن بعضًا منها شبه مهجور (مثل OData)

😞

تضمين التغريدة

• العديد من الشكاوى التي أراها في هذا الموضوع هي بعض الاختلاف في "لا أستطيع فعل X في .NET Core 2.0" بينما ما يعنيه الكاتب في الواقع هو "لا بد لي من تغيير الطريقة التي أفعل بها X في .NET Core 2.0" . نعم ، عليك أن تتغير. لا ، هذا ليس بالأمر السيئ. إذا كان لديك جزء صغير من الوظائف المنفصلة في تطبيق ASP.NET MVC الخاص بك والذي يقوم بشيء ما باستخدام ملفات PDF أو ملفات DOCX ، ولا يمكنك حقًا العثور على طريقة أفضل للقيام بأي شيء (هل جربت ذلك؟) ، فكسر ذلك يتم تشغيل الوظائف في خدمة صغيرة تعمل على .NET بالكامل على Windows Server واسمها واجهة برمجة تطبيقات HTTP من تطبيق .NET Core الخاص بك. لا يعد تحليل التطبيقات ونقل وظائف معينة إلى خدمات صغيرة قائمة بذاتها حلاً بديلاً ، بل هو أفضل ممارسة للأغراض العامة.
ملاحظة: بقدر ما أستطيع أن أقول ، فإن حزم OpenXML تدعم الآن .NET Standard ، لذا فإن العمل مع Word / Excel / أي شيء لا ينبغي أن يكون مستحيلاً. <<

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

يمكنني أن أؤكد لكم أنني قضيت الكثير من الوقت في البحث عن أفضل الأدوات لنا لاستخدامها في إنشاء ملفات PDF و DocX ، وهي ليست سهلة مثل التعامل مع XML المفتوح. نحن نستخدم مكتبة تابعة لجهة خارجية لأن هناك عشرات الآلاف من سطور التعليمات البرمجية التي طوروها ولا يتعين علينا تطويرها / صيانتها / اختبارها. هذا هو بيت القصيد.

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

لتوضيح ما أفعله هو أن لدي ثلاث مكتبات خاصة بي تتم مشاركتها بين تطبيقات WPF المختلفة وخادمي. ليس لدي أي فكرة على الإطلاق في هذه المرحلة عن أي Apis الذي أستخدمه قد يكون أو لا يكون متاحًا في جوهر.net. ثم في تلك المكتبات ، أستخدم إصدارات سطح المكتب الكاملة من أدوات WPF من Telerik و SyncFusion لإنشاء docx و pdf. بعض أو كل الوظائف التي تستخدمها هذه الأدوات قد تكون متاحة أو لا تكون متاحة في .net core. إن محاولة تطوير التطبيقات بناءً على ما قد أو لا يكون أمرًا صعبًا للغاية. لدى Microsoft إطار عمل أساسي رائع في .net ، وبينما أفهم الأسباب الكامنة وراء .net core. يبدو أن Microsoft قد نسيت أهمية التوافق مع الإصدارات السابقة.

ستيفان

تضمين التغريدة

أوه ، آسف ، لم أكن أدرك أن حجم عينتك كان كبيرًا جدًا. 257 تعليقًا بانحياز قوي للأشخاص الذين لا يحبون القرار؟ من الصعب أن يجادل في ذلك. إخلاء المسؤولية: أنا لست خبيرًا في البيانات الضخمة.

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

تضمين التغريدة

أصبح تعيين إصدارات .net معقدًا للغاية

أعتقد أن هذا أحد الأشياء القليلة التي يمكننا الاتفاق عليها جميعًا .

نحن نتطلع إلى منفذ إلى .Net Core x.
تدور أكبر مشكلاتنا حول:
NewRelic (لا توجد خطة Net Core ، لذلك نحتاج إلى إيجاد بديل)
NH (حيث لا تحتوي EF Core على الميزات).
ServiceBase (يبدو أنه قادم إلى .Net Core 2 في الصيف)

يبدو بالتأكيد أنه سيتعين علينا استهداف Core 1.0 في غضون ذلك وانتظار ترقيات NH و EF أو الإبداع.

هذا يعني فقط أنه لا يمكنك استخدام صفحات Razor tbh ، يحتوي ASP.NET Core 2.0 على الكثير من الأشياء الصغيرة ولكن لا توجد ميزات أو إصلاحات كبيرة لا يتم تحويلها أيضًا إلى 1.x. إن موضوع موسوعة الحياة حقيقي للغاية وأنا شخصياً لا أعتقد أن دعم ASP.NET Core 2.0 لـ .NET Framework لمدة عام آخر سيساعد. نحن نناقش حقًا تغيير الاتجاه هنا ، إما أننا ندعم .NET Framework إلى الأبد ، أو لا ، فلا يوجد حقًا في المنتصف.

إنها أكبر قليلاً من صفحات Razor ، وهذا يعني أنه لا يوجد سبب للتحرك . لا يوجد سيناريو (حالي) يتواجد فيه كلاهما :

1. سنكون مدعومين طوال الوقت
2. هناك ترقية فعلية على الجانب الآخر

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

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

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

من فضلك ، لا تقم بإجراء هذا التغيير الآن. NET أفضل من هذا. أظهر اهتمامك بمستخدميك بقدر ما يهتم بك الجميع هنا. لن نكون هنا إذا لم نرغب في المساعدة.

FransBouma (يجب) أن تعلم جيدًا أن لدى Microsoft قواعد بيانات ضخمة للقياس عن بُعد والتعليقات والبيانات الأخرى حول ما يفعله الأشخاص بتقنيتهم ​​والتي تعطي صورة أوضح بكثير من أي عدد من سلاسل مواضيع GitHub ، ولا أعتقد مشيرا إلى أن أي شيء كان أكثر سخافة من

أوه لا أعلم ، من خلال قراءة المشاركات في هذا الموضوع؟

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

قصة مشاركة الكود عبر أوقات تشغيل .NET المختلفة هي .NET Standard. يجب أن تحاول مكتباتك توجيه ذلك إلى رمز مشترك عبر .NET Core و .NET Framework.

يبدو أن Microsoft قد نسيت أهمية التوافق مع الإصدارات السابقة.

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

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

تضمين التغريدة

إنها أكبر قليلاً من صفحات Razor ، وهذا يعني أنه لا يوجد سبب للتحرك. لا يوجد سيناريو (حالي) يتواجد فيه كلاهما:

هل يمكنك التفصيل؟

الحقيقة هي أن ASP.NET Core ليس مفيدًا حقًا بدون النظام البيئي. يعد امتلاك وحدة تحكم تعرض النص مرة أخرى أمرًا رائعًا ، ولكنه ليس مفيدًا للعديد من السيناريوهات.

يمكنه فعل ذلك بسرعة كبيرة جدًا 😉

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

لا أفهم لماذا يكون 2.x (الدعم) و 3.x (الإفلات) أفضل من 1.x (الدعم) و 2.x (الإفلات). هل يمكنك شرح ذلك لي من فضلك؟ كيف يحدث أي فرق؟

زوجان من توصيات جلسة BUILD 2017 للمهتمين بالدعم طويل المدى لتغيرات ASP.NET:

• تحديثات نماذج ويب T6009 ASP.NET
  
  
  
  • أي أنهم ما زالوا يطورون منصات ويب كاملة .NET
  
  
• دعم T6072 لـ ASP.NET Core: ما هو LTS؟
  
  
  
  • الذي أعتقد أنه يتم تحديثه بشكل محموم الآن: التجهم:
  
  

davidfowl :

كيف يحدث أي فرق؟

لأنك وعدت ببعض من أهم واجهات برمجة التطبيقات المفقودة للشحن بعد 2.0؟

@ yaakov- ح

لأنك وعدت ببعض من أهم واجهات برمجة التطبيقات المفقودة للشحن بعد 2.0؟

قل لي أي منها في ASP.NET Core؟

davidfowl System.DirectoryServices ، System.Drawing مذكورة أعلاه.

سؤال صادق (هذا أنا لا أطرحه على Microsoft) ، هل تفضل الاستقرار والتوافق على الميزات الجديدة؟ إذا كانت الإجابة بنعم ، فلماذا تختار ASP.NET Core؟

أعتقد أن هذا سؤال جيد للغاية. إذا كان إطار عمل .NET الكامل يوفر كل ما يحتاجه اليوم ، فلماذا حريص جدًا على الترحيل إلى مكدس مختلف تمامًا؟ إذا تم تسمية .NET Core و ASP.NET Core بشكل مختلف ، بدون .NET int الاسم ، فأعتقد أن عددًا أقل بكثير من الناس قد يجادل حول مشكلات الترحيل. لا أحد يشتكي من عدم تمكنه من الترحيل إلى حزمة ويب Go أو Node.js سريعة الحركة.

إن توافقdavidfowl مع الإصدارات السابقة مع ASP.NET MVC 5.x شيء واحد ، والتوافق مع الإصدارات السابقة لإطار .net هو شيء آخر. يعد إسقاط إطار عمل .net أمرًا مهمًا ...

لا أفهم لماذا يكون 2.x (الدعم) و 3.x (الإفلات) أفضل من 1.x (الدعم) و 2.x (الإفلات).

لأن الإصدار 2.x سيأتي قريبًا جدًا كما نفهمه.

davidfowl System.DirectoryServices ، System.Drawing مذكورة أعلاه.

هؤلاء لا علاقة لهم بـ ASP.NET Core 1.x أو 2.x وسيتم تشغيلهم على كليهما عند الاتصال بالإنترنت.

كما قلت ، أنا هنا فقط لاستدعاء FUD وهذا جزء منه. لقد أصبح هذا الموضوع كبيرًا لدرجة أنه لا يمكن لأحد رؤية الحقائق في بعض الردود.

FransBouma (يجب) أن تعلم جيدًا أن لدى Microsoft قواعد بيانات ضخمة للقياس عن بُعد والتعليقات والبيانات الأخرى حول ما يفعله الأشخاص بتقنيتهم ​​والتي تعطي صورة أوضح بكثير من أي عدد من سلاسل مواضيع GitHub ، ولا أعتقد مشيرا إلى أن أي شيء كان أكثر سخافة من

markrendle القياس عن بعد ليس سحرا. لا يمكنك قياس سبب عدم تبديل ppl / dev ، أو سبب تبديلهم لمكدس آخر ، أو أهمية مشروعهم ومدى إعجابهم بالمكدس (ومساعدة الآخرين ، من خلال الاستشارة أو نظام التشغيل) ، أو ما يفعلونه.

هذا الموضوع هو بالضبط أن ردود الفعل.

لا أفهم لماذا يكون 2.x (الدعم) و 3.x (الإفلات) أفضل من 1.x (الدعم) و 2.x (الإفلات). هل يمكنك شرح ذلك لي من فضلك؟ كيف يحدث أي فرق؟

davidfowl الوقت.
حان الوقت لتسوية قليلا. حان الوقت لتقييم الأشياء. حان الوقت لتغيير شيء واحد في كل مرة. حان الوقت لاستخدام حزم netstandard2 مع شيء RTM. حان الوقت لنقل libs لدينا إلى netstandard2 (أسهل) بدلاً من netstandard1 (أصعب). حان الوقت لتغيير شيء واحد في كل مرة ، بالنسبة لي ، في الغالب.
أنت تفعل aspnet ، ولكن منتجي ليس فقط aspnet ، هو مزيج من الكثير من libs والمقايضات والنظام البيئي.

لأن الإصدار 2.x سيأتي قريبًا جدًا كما نفهمه.

ماذا يعني أن يكون لديك لتفعله حيال ذلك؟ ماذا لو جاء الإصدار 2.0 في نهاية العام أو في يناير؟ هل ستشكل فارق؟ ما الذي يجعل 1.x غير جدير في الإصدار 2.0؟

@ yaakov-h لقد تم ذكرهم هنا حيث قال shanselman (التركيز لي)

AD - تمامًا ، هذه فجوة إذا كنت تريد استدعاء LDAP مباشرة. يمكنك بالتأكيد المصادقة ضد Windows Auth NOW. نخطط لأن يكون لدينا مساحة اسم DirectoryServices لـ Core 2.0 على وجه التحديد في الإطار الزمني الصيفي
الرسم - تمامًا ، هذه فجوة. نحن نخطط للحصول على هذا لـ Core 2.0 حول الإطار الزمني الصيفي . حتى ذلك الحين ، توجد أيضًا خيارات netstandard هذه ImageSharp و ImageResizer وخيارات Mono وما إلى ذلك

davidfowl لا يتعلق الأمر بالإصدار ، إنه يتعلق بتاريخ ونضج .net core والنظام البيئي الخاص به.

تضمين التغريدة

أنا آسف ، أفهم ذلك من مستوى POV عالي جدًا ولكن ليس من مستوى تقني. ربما هذه ليست مناقشة فنية؟

تضمين التغريدة

حان الوقت لتسوية قليلا. حان الوقت لتقييم الأشياء. حان الوقت لتغيير شيء واحد في كل مرة. حان الوقت لاستخدام حزم netstandard2 مع شيء RTM. حان الوقت لنقل libs لدينا إلى netstandard2 (أسهل) بدلاً من netstandard1 (أصعب). حان الوقت لتغيير شيء واحد في كل مرة ، بالنسبة لي ، في الغالب.
أنت تفعل aspnet ، ولكن منتجي ليس فقط aspnet ، هو مزيج من الكثير من libs والمقايضات والنظام البيئي.

ما سبب الاختلاف في ASP.NET Core 2.0 على وجه التحديد؟ ستحصل على هذه الميزة من النظام الأساسي بغض النظر عما يختار ASP.NET Core القيام به.

markrendle أحضر لي شخص ما تقويمًا ، لأن الفصول تمتد على ربع كامل (يمكن أن تكون 3 أشهر من شيء آخر في نفس الربع) وهي مربكة بشكل خاص لنا نحن سكان نصف الكرة الجنوبي.

enricosada يمكنك الحصول على قدر هائل من المعلومات المفيدة من التتبع عن بعد ومصادر البيانات الأخرى (تحليلات الويب ، وبيانات البحث ، وتعليقات العملاء المباشرة). أكثر بكثير مما يمكنك الحصول عليه من الغوغاء الغاضبين على GitHub (مهما كان غضب كل فرد مبررًا).

@ yaakov-h حسنًا ، RTM المتوقع حاليًا لـ .NET Core 2.0 (وبالتالي ASP.NET Core 2.0) هو التقويم Q3 ، وهو يوليو / أغسطس / سبتمبر) ، والصيف في نصف الكرة الشمالي غالبًا يوليو / أغسطس / سبتمبر ، لذلك فهو في الأساس نفس الشيء.

يمكنك الحصول على قدر هائل من المعلومات المفيدة من التتبع عن بعد ومصادر البيانات الأخرى (تحليلات الويب ، وبيانات البحث ، وتعليقات العملاء المباشرة).

أتساءل كيف يمكن الاعتماد على هذا القياس عن بعد - على الأقل الجزء الآلي - لعمليات النشر المؤسسية ، على الرغم من ذلك. (نظرًا لأن غالبية ردود الفعل تأتي من هذا المكان).

لا أفهم لماذا يكون 2.x (الدعم) و 3.x (الإفلات) أفضل من 1.x (الدعم) و 2.x (الإفلات). هل يمكنك شرح ذلك لي من فضلك؟ كيف يحدث أي فرق؟

@ توقيت دافيدفول . وإعلان مناسب. إذا كانت الرسائل أكثر وضوحًا ، فلن يتفاجأ الناس.

@ توقيت دافيدفول . وإعلان مناسب. إذا كانت الرسائل أكثر وضوحًا ، فلن يتفاجأ الناس.

أفهم ولكن لا أعتقد أنه سيحدث فرقًا في قدرتك على نقل أي شيء حقًا. نفس سياسة موسوعة الحياة لا تزال موجودة.

حسنًا ، بعد أن واجهت صعوبة في فهم هذه المشكلة ، أردت تقديم بعض الأفكار لأولئك الذين يكافحون مثلي ولديهم أيضًا بعض الأسئلة.

لذلك إذا فهمنا بشكل صحيح ، فسنحصل في النهاية على معيار صافي يحل محل net framework.

لذلك دعونا asume netcore غير موجود ويعتمد aspnet core على netstandard. هذا يعني أن الميزات ستأتي أبطأ.

مثال:
2017 asp.net تريد الميزة أ.
تطبيق netstandard لعام 2018 الميزة A. نحصل على الميزة A على ns.

ما يقوله الفريق هو أن يكون لديك netcore لا يعتمد على معيار الشبكة لذلك:
2017 asp.net تريد الميزة أ
2017 فريق aspnet يطبق الميزة أ. Asp.Net Core يحصل على الميزة A على netcore.
2018 netstandard يطبق الميزة A. نحصل على الميزة A على ns.

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

إذا كان وجود netcore استنادًا إلى netstandard 2 يعني أنه تم إصدار الميزات لمدة عام واحد (أو أي إطار زمني) لاحقًا ، فسيظل الناس يجادلون بأنهم يريدون ذلك؟ هذا هو السيناريو الذي اعتدنا عليه مع NET Framework .

هذه هي الجنة لفريق aspnet ، وتكون قادرًا على شحن الأشياء دون الاعتماد على شخص آخر ، وهي أيضًا أخبار رائعة للعملاء الذين يمكنهم الحصول على هذه الأشياء السريعة. إذا لم تتمكن من متابعة الأشياء السريعة ، فإن التمسك بالإصدار السابق يعد مقايضة معقولة (وحافز لك / التبعيات للترقية.)

لا يزال يتعين على مؤلفي المكتبة أن يهدفوا إلى استهداف معيار الشبكة ، وإذا لم يكن بإمكانك حينئذٍ فلا تقلق على الإطلاق.
إذا كنت بحاجة إلى شيء ليس على شبكة الإنترنت (ربما صفحات موس (؟)) ، فيجب عليك استهداف netcore ، في السيناريو 1 ، قد لا توجد صفحات موس. لا أرى كيف يمكن أن يكون هذا سيئًا ، أود أن أقول إنه عادل.

لذا فإن السؤال هو ، ما هي التبعية التي لديك الآن والتي تقيد نفسك من الانتقال إلى NET Framework إلى Net Core؟
قد أكون الوحيد هنا ولكني لم أتوقع أن يعمل aspnet core على NET Framework إلى الأبد ، كان من الواضح لي أن هذه كانت خطوة "انتقالية". كل تطويراتي التي تحتاج حاليًا إلى NET Framework هي splited . (ولا ، هذه ليست خدمات مصغرة ، إنها أبسط بكثير من ذلك).

لا يختلف دعم 2.x والإفلات 3.x عن دعم 1.x وانخفاض 2.x. سأخمن هنا وأقول إن الناس لا يفهمون السيناريو بوضوح ، لذلك آمل أن يوضح هذا البعض على الأقل.

NickCraver لقد قلت إنك تريد من Microsoft التراجع عن هذا القرار. ماذا سيكون اقتراحك ، لعدم وجود netcore معزولة وإصدارات الميزات أبطأ؟ (سؤال صادق)

davidfowl أعتقد أنه قد تكون هناك مشكلة خفية في العرض الحالي تقلق المطورين.
إذا كانت لديك الميزة A لـ asp.net (مع netcore) ، فيمكنك التسويق والشحن (ووضع علامة في خانة اختيار الإدارة / مساءً) وتكون "كسولًا" للتنفيذ على netstandard ، إذا لم أكن مخطئًا ، فهذا هو "الرهان" على غير مؤكد يحكم هنا.
لذا في المثال السابق ، قد تكون الميزة "أ" في تطبيق netstandard في 2019 ، أو 2020 ، أو أبدًا بدلاً من 2018. <- يبدو هذا وكأنه مشكلة محتملة (؟) ، هل أنا على صواب؟ هل تستطيع Microsoft الالتزام بشيء ما هنا؟

في حين يمكننا جميعًا الاختلاف حول ما إذا كنا نحب الإعلان حقًا بفضل davidfowlDamianEdwards و shanselman لقضاء الوقت في المناقشة. إنه دليل آخر على زيادة المشاركة والانفتاح.

أنا متأكد من أن البعض سيتجادل بشأن التوقيت وما إلى ذلك ، لكنه تقدم.

مثال:
2017 asp.net تريد الميزة أ.
تطبيق netstandard لعام 2018 الميزة A. نحصل على الميزة A على ns.

ما يقوله الفريق هو أن يكون لديك netcore لا يعتمد على معيار الشبكة لذلك:
2017 asp.net تريد الميزة أ
2017 فريق aspnet يطبق الميزة أ. Asp.Net Core يحصل على الميزة A على netcore.
2018 netstandard يطبق الميزة A. نحصل على الميزة A على ns.

ما كان يجب عليهم فعله هو:
يبني فريق 2017 aspnet الميزة المطلوبة في lib X ، والتي تدعم netstandard2.0. بهذه الطريقة ، يعمل aspnet على كل شيء .netstandard يعمل ، ويمكن للمستخدمين بعد ذلك تشغيله على .net كامل لأن lib X قابل للاستخدام على .NET ممتلئ أيضًا (إنه مجرد تثبيت nuget بعيدًا).

بدلاً من ذلك ، لا يفعلون ذلك ، بل يجبرون lib X على أن يكون .NET core فقط (وإلا ، لماذا هذا الموضوع / القرار في المقام الأول). إذا كان lib X متقدمًا للغاية لدرجة أنه يحتاج إلى ميزات CoreCLR ، فيجب على Microsoft أن يسأل نفسه لماذا لا يتم نقل هذه الميزات المتقدمة إلى .NET full CLR.

بشكل عام ، يبدو الأمر وكأنه سياسة حيث يحتاج MS إلى نواة NET Core / aspnet سريعة الحركة لتزويد عملاء Azure بمكدس يمكن استخدامه في حاويات على Azure حتى يتنافس مع الحاويات المستندة إلى JVM / NodeJS على AWS أو Google cloud. من منظور أعمالهم يمكنني حتى أن أفهم ذلك. ولكن ما يظهره هو أن MS ليس لها أولوية فيما يتعلق بـ .NET full للمضي قدمًا بشكل أسرع ، حيث أنها لا تضع موارد كافية على .NET full لمواكبة .NET core. انظر إلى مقدار واجهات برمجة التطبيقات المضافة إلى .NET بالكامل في العامين الماضيين. هل هذا يخبرك أن فريقًا كبيرًا يعمل على ذلك؟

رقم.

تبيع Microsoft نظام قاعدة بيانات كبير ، SQL Server Enterprise. يأتي مع ميزات تشفير رائعة. غير مدعوم على .NET core. استمتع ببيع .NET core 2.0 للمؤسسات التي تعتبر عملاء محتملين لنظام قاعدة البيانات المكلف هذا.

قد ترغب في التحرك "بسرعة" ، ولكن ما لم تفهم تمامًا الوجهة التي تتجه نحوها ، فمن المفيد أن تستغرق دقيقة أو دقيقتين لتقرر ذلك أولاً.

كلما فكرت في الأمر أكثر كلما اعتقدت أن المشكلة التي يواجهها معظم الناس هي أنهم يشعرون أننا نقطع الحبل بين .net و asp.net.
حاليًا لدينا asp.net و asp.net core (.net) و asp.net core (core). لذلك يمكنك اختيار ما إذا كنت تريد عدم الذهاب ، القليل أو النواة الكاملة.

نظرًا لأن الاتصال ضعيف في الإصدار ، يشعر الناس أنه الجزء الأخير فقط هو الذي يبتكر ويتقدم ، في حين أن asp.net و asp.net الأساسية (.net) عالقون.
نظرًا لأنه ليس لدينا طريقة للتحقق مما إذا كان lib سيعمل في netstandard2.0 دون محاولة ، فمن الخطورة جدًا العمل مع النواة الكاملة في مشروع جديد. لذلك ينتهي بهم الأمر إما بـ asp.net (قديم) أو asp.net (قديم أيضًا).
وبما أن كلاهما قديم ، فمن المنطقي استخدام system.web و asp.net القديم. نظرًا لأنهم يعرفون ذلك ، وبما أن جوهر asp.net هو موسوعة الحياة على أي حال ، فلماذا تهتم.

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

ملاحظة: أنا أصيغ هذا كما هو الحال مع الشعور الحالي. أن asp.net الأساسية 1.x "قديمة وعفا عليها الزمن" مقابل 2.x. ليست هذه حقيقة ، لكن هذا ما يفكر فيه الناس.

تضمين التغريدة

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

لقد حدث هذا بالفعل ، ونحن على ما يرام معه. عادةً ما يتم تعبئة مستند الإصدارات بـ _vNext_. وهذا جيد. بدلاً من الانتظار حتى تصبح جميع الأنظمة الأساسية على قدم المساواة قبل زيادة المعيار ، أفضل أن أرى المعيار المحدد عدة إصدارات للأمام ومشاهدة المنصات تلحق بالركب. يمكن للناس حتى أن يشاركوا في التعريف والتنفيذ. وإذا استهدفت ASP.NET Core المعيار لإصداراتها ، فبمجرد تطبيق النظام الأساسي والهندسة المعمارية لهذا المعيار الجديد ، ستكون الحزمة متاحة. يمكن أن تأتي الإصدارات القياسية الجديدة من خلال تحديثات أو حزم VS.

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

ونحن نفعل الشيء نفسه

جيد. البؤس المشترك هو أفضل بؤس. ملفات Csproj و sln التي تحتوي على عناصر النظام الأساسي / التكوين مزعجة حقًا ، راجع للشغل ، لأن تركيبات الإنشاء لا يتم الإعلان عنها دائمًا - يتم استنتاجها. لذلك قد تعتقد VS أن لدي مجموعات بناء أكثر من الموجودة بالفعل لأنها تفترض أن كل مجموعة ممكنة مهمة. ولا بد لي من وجود أقسام إضافية في الملف لن تكون ضرورية إذا كان بإمكاني فقط إعلان مجموعات النظام الأساسي / التكوين. مثلما يمكنك استخدام وظائف مثل Substring في عناصر csproj PropertyGroup لتبسيط الخصائص المخصصة ، ولكن يتم استخدام هذه الشروط في تحديد تكوينات البناء ، لذلك يجب أن يكون لديك قيم السلسلة الكاملة هناك. لا ينبغي أن يكون هذا النوع من الأشياء مزعجًا بقدر ما هو عليه.

سؤال صادق (هذا أنا لا أطرح Microsoft) ، هل تفضل التوافق على الميزات الجديدة؟ إذا كانت الإجابة بنعم ، فلماذا تختار ASP.NET Core؟

شخصيا لا. طالما أن هناك طريقة لفعل ما أحتاج إلى القيام به ، فأنا لا أمانع في إعادة كتابة الكود طالما أنه ليس مسعى ضخمًا له فائدة قليلة أو اختبار PITA لاختباره. لذلك سأختار كل ما لديه أكبر قدر من الزخم والإمكانات. لكن لا بد لي من العمل مع مشاريع عبر تقنيات متعددة - Win32 و COM و CORBA و ADO.NET والعديد من محركات التقارير وواجهات برمجة تطبيقات الويب المختلفة والمتصفحات المضمنة مثل CEF / Firefox / IE (بدون حافة ، بالطبع ، لأنه غير مدعوم) و أشياء متعددة خاصة بالبائع ، سأتجنب التشهير بها. أقوم بتنفيذ ما يمكنني القيام به كمكوِّن إضافي ، لكنني متزوج من القاسم المشترك الأقل في ملف المضيف القابل للتنفيذ ، في الغالب. التعامل مع العديد من التقنيات أمر مزعج ، لكنها ثابتة. هذا هو مقدار الكثير من عناصر سطح المكتب / الخادم. طالما أُعطيت الأدوات اللازمة للتشغيل المتداخل ، يمكنني القيام بذلك. لكن الأطر الأقل إهمالًا التي أتذكرها ، كان ذلك أفضل.

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

لذلك إذا فهمنا بشكل صحيح ، فسنحصل في النهاية على معيار صافي يحل محل net framework.

ليس هذا ليس صحيحا. لست متأكدا كيف توصلت إلى هذا الاستنتاج. ستكون .NET Standard دائمًا مجموعة فرعية لكل من أوقات التشغيل التي تدعمها.

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

• لقد حددنا السلاسل كأحد الأشياء الرئيسية التي نود أن نحاول معالجتها في .NET Core ، هناك الكثير من الأفكار ولكن إحداها أن يكون لديك سلسلة تكون utf8 افتراضيًا (العديد من مشاكل التوافق ولكن اتبعني هنا).
• الشيء الآخر الذي نرغب في إصلاحه هو القدرة على أخذ شرائح رخيصة من المصفوفات / السلاسل ، أي قطعة من الذاكرة المتجاورة. لقد أضفنا Span<T> ونبحث عن Buffer<T> لتمثيل ذلك. قد يعني ذلك أن String and Array يطبقان واجهات جديدة تجعل من الممكن أخذ شريحة تتطلب تخصيصًا صفرًا.
• يؤدي هذا إلى عمليات جديدة على String تسمح بالتقسيم الذي لا يخصص مصفوفة في كل مرة.
• يؤدي هذا إلى زيادة الحمولة إلى Int و UInt وما إلى ذلك (TryParse) التي تتطلب Span<char> و Span<byte> .
• يؤدي هذا إلى إجراءات ترميز جديدة تتطلب Span<byte> .
• يتيح لك Buffer<T> و Span<T> تمثيل الذاكرة بطريقة موحدة ونريد ترقية مكدس الشبكة للسماح بتمرير المخازن المؤقتة المثبتة مسبقًا التي تتطلب Span<T> أو Buffer<T> .
• سيطبق Kestrel HTTP2 في الإطار الزمني 2.x (يهدف حاليًا إلى 2.1) ويتطلب ذلك واجهات برمجة تطبيقات جديدة على دفق SSL للقيام بـ ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• يدعم Http Client على .NET Core الدفق المزدوج ، مما يجعل من الممكن تنفيذ نقاط نهاية الدفق عبر http في signalr عبر طلب http واحد غير مزود بمقبس ويب.
• قمنا بتقسيم تطبيقات محلل الرأس من HttpClient و System.Net.Http وأعدنا تسميتها (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Http.Http.Http. واجعلهم يدعمون كلاً من .NET Framework و .NET Core. NET Core لديه نسخة من هذه التحسينات لم تتمكن من إعادتها لأنه ليست هناك حاجة لتحسينها (لم نتمكن من استهلاكها).
• هناك مجموعة من الأساسيات الجديدة للترابط والتي تتطلب واجهة برمجة تطبيقات جديدة من شأنها أن تضيء سيناريوهات جديدة إذا كنا قادرين على استهلاكها (https://github.com/dotnet/corefx/issues؟q=is٪3Aopen+is٪3Aissue+ المؤلف٪ 3Adavidfowl + label٪ 3Aarea-System.Threading) ، هذه ليست سوى بعض الأشياء التي قمت بتقديمها شخصيًا.

بدون القدرة على تسريع الأساسيات الأساسية ، نشجعنا على تفرعها وصنع أشياء تبدو مثلها ولكنها ليست كذلك. هذا هو السبب في أن لدينا BCL الصغير الخاص بنا داخل ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

كان ذلك مجرد تفريغ عشوائي لأشياء يمكنني رؤيتنا نقوم بها على المدى القريب والتي تؤثر على أجزاء أساسية جدًا من .NET.

تضمين التغريدة

NET ممتلئًا للمضي قدمًا بشكل أسرع ، لأنه لا يوفر موارد كافية على .NET full لمواكبة .NET core. انظر إلى مقدار واجهات برمجة التطبيقات المضافة إلى .NET بالكامل في العامين الماضيين. هل هذا يخبرك أن فريقًا كبيرًا يعمل على ذلك؟

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

أفهم ولكن لا أعتقد أنه سيحدث فرقًا في قدرتك على نقل أي شيء حقًا. نفس سياسة موسوعة الحياة لا تزال موجودة.

davidfowl صحيح. لكن كيفية تأطيرها تعني شيئًا. ناهيك عن وقت توصيلها ، إن وجدت. لن يمنح الأشخاص بالضرورة مزيدًا من الوقت للقيام بالعمل الفعلي ، ولكنه سيمنحهم مزيدًا من الوقت للتفكير واتخاذ القرار الصحيح (بالنسبة لهم).

حاليًا ، إذا بدأت في النقل إلى / استخدام ASP.NET Core على .NET Framework ، فيبدو أن لديك ثلاثة خيارات:

1. قم بنقل كل التعليمات البرمجية والتبعيات الخاصة بك إلى .NET Core والانتقال إلى ASP.NET Core 2.x.
   
   
   
   • سيكون هذا هو الحل الأمثل ، لكنه قد يتطلب الكثير من العمل ، وبالنسبة للبعض ، قد يكون خارج نطاق سيطرتهم بسبب تحليلات الطرف الثالث.
   
   
2. ابق على ASP.NET Core 1.x و .NET Framework وآمل أن تتمكن من القيام بـ 1. قبل أن يكون غير مدعوم.
   
   
   
   • هذا محفوف بالمخاطر. في غضون عام (أو عامين ، أو ثلاثة؟ من يدري؟) ، يمكنك المخاطرة بالركض على منصة غير مدعومة.
   
   
3. ارجع إلى ASP.NET 4.x.
   
   
   
   • بينما يتركك هذا البديل مدعومًا ، فسوف "تعود" وتتراجع عن العمل الذي بدأته بالفعل. وأيضًا ، دعنا نواجه الأمر ؛ هذه المنصة لن تحظى بالكثير من الحب للمضي قدمًا.
   
   

إذا كنت تعرف مسبقًا ويمكنك التخطيط لذلك ، أعتقد أن كلا من 1. و 2. بديلان لائقان. المشكلة هي أن كلا البديلين بهما عدد غير قليل من الأشياء المجهولة. ماذا عن المكتبة أ؟ ماذا عن المكتبة ب؟ هل سيتم نقل المكتبة "أ" من أي وقت مضى؟

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

khellang (في الحل الافتراضي الخاص بك)

1. انتقل إلى ASP.NET Core 2.0 على .NET Framework
   
   
   
   • هذا محفوف بالمخاطر. في غضون عام ، قد تخاطر بالعمل على منصة غير مدعومة.
   
   

تضمين التغريدة

سؤال صادق (هذا أنا لا أطرحه على Microsoft) ، هل تفضل الاستقرار والتوافق على الميزات الجديدة؟ إذا كانت الإجابة بنعم ، فلماذا تختار ASP.NET Core؟

الجواب الصادق:
صالح: الاستقرار والتوافق أمر بالغ الأهمية. الميزات الجديدة رائعة ، ولكن عندما تهبط ، يجب ألا تكسر النظام البيئي الحالي.
لماذا ASP.NET Core: ببساطة لأنه يعمل على OS X و Linux.

يتم اختيار نظام بيئي مثل .NET (قديم و / أو أساسي) أو Java أيضًا بواسطة الشركات. وعندما يتخذون قرارهم ، فإنهم يبذلون الكثير من الجهد في تطوير رمز لهذا النظام الأساسي / النظام البيئي.

الآن ، أحد عملائنا ، على سبيل المثال ، استثمر بالفعل كثيرًا في ASP.NET Core. استنادًا إلى الإعلانات السابقة والأفكار المباعة لـ .NET Core ، تمت كتابة التعليمات البرمجية. كود NET Core الجديد هذا (ASP.) كتبناه (بشكل مؤلم) مع فريق على مدار التطوير الأولي لـ (ASP) .NET Core ، بدءًا من بدايته ، عبارة عن مجموعة من الخوادم ومكتبات العملاء ، مع مجموعة كبيرة جدًا منطق الأعمال.
وهذا الرمز ، إلى جانب التشغيل على خادم Linux ، الذي يوفر الخدمات ، يتم استخدامه حاليًا أيضًا في مجموعة من التطبيقات القديمة جدًا التي تتحدث إلى هذه الخدمات ، وهي مزيج من مزيج من WPF / Windows Forms / C ++ / CLI والعادية C ++ (بما في ذلك عناصر DirectX).

والآن تقوم ببساطة بقطع استثمارات عملائنا في بضع سنوات من الجهد المبذول في كود .NET Core للتطبيقات الحالية ، حيث سيكون من المستحيل إعادة استخدام كود .NET Core الجديد في التطبيقات الفعلية (تم إنشاء الخوادم الجديدة ومكتبات منطق الأعمال من أجل).

للرجوع إلى السؤال التالي: ستختار الشركة .NET Core كـ ".NET ، الآن أيضًا لـ XPlat" ، بينما تتوقع نفس التوافق والاستقرار الذي قدمته لنا .NET في آخر 17 عامًا. ولكي أكون صريحًا ، هذا هو السبب الوحيد لـ .NET Core. إذا كنت لا تريد ذلك ، فيمكنك استخدام Node.js أو حتى Java. كلاهما أكثر نضجًا و XPlat من .NET Core الآن.

وللتوضيح أكثر قليلاً: كان .NET Core رائعًا وسريع الخطى في المراحل الأولى مع project.json وكل شيء. وبعد ذلك ، من منطلق "التوافق مع .NET" ، تم أخذ project.json منا لصالح Msbuild و .csproj مرة أخرى. والآن تم أخذ فوائد "التوافق مع .NET" بالضبط لصالح .. ماذا بالضبط؟

gingters

بادئ ذي بدء ، رد عظيم!

لماذا ASP.NET Core: ببساطة لأنه يعمل على OS X و Linux.

بناءً على ذلك ، يبدو أن MVC 5 للأحادية هو ما تريده حقًا؟

للرجوع إلى السؤال التالي: ستختار الشركة .NET Core كـ ".NET ، الآن أيضًا لـ XPlat" ، بينما تتوقع نفس التوافق والاستقرار الذي قدمته لنا .NET في آخر 17 عامًا. ولكي أكون صريحًا ، هذا هو السبب الوحيد لـ .NET Core. إذا كنت لا تريد ذلك ، فيمكنك استخدام Node.js أو حتى Java. كلاهما أكثر نضجًا و XPlat من .NET Core الآن.

وللتوضيح أكثر قليلاً: كان .NET Core رائعًا وسريع الخطى في المراحل الأولى مع project.json وكل شيء. وبعد ذلك ، من منطلق "التوافق مع .NET" ، تم أخذ project.json منا لصالح Msbuild و .csproj مرة أخرى. والآن تم أخذ فوائد "التوافق مع .NET" بالضبط لصالح .. ماذا بالضبط؟

هذا هو جوهر القضية في الأساس. بناءً على تقييمك:

كود NET Core الجديد هذا (ASP) كتبناه (بشكل مؤلم) مع فريق على مدار التطوير الأولي لـ NET Core (ASP).

لقد أردت فقط استخدام .NET Framework الموجود على نظام التشغيل Linux مع توافق ASP.NET 4.x القديم الجيد. هل هذا ملخص عادلة؟

صالح: الاستقرار والتوافق أمر بالغ الأهمية. الميزات الجديدة رائعة ، ولكن عندما تهبط ، يجب ألا تكسر النظام البيئي الحالي.

NET Core هو في الواقع نظام أساسي أكثر استقرارًا من سطح المكتب لأنه يسمح بالتنفيذ جنبًا إلى جنب حيث لا يسمح سطح المكتب بذلك.

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

كتب davidfowl :

الأمر متروك لأطر العمل لتقرر ما إذا كانت تريد العمل على .NET Framework و UWP و .NET Core و mono وما إلى ذلك. إنه اختيار. لا يتم شحن Orleans مع .NET Core. ASP.NET Core يفعل. هذه المنتجات واحدة ونفس الشيء.

في حالة أورليانز ، ندعم .NET Standard 1.5 في إصدارات "2.0 Technical Preview" ، لكننا ننتظر .NET Standard 2.0 حتى نتمكن من إصدار إصدار مستقر. في الوقت الحالي ، لا أرى أي عوائق لنا - ما يشغلني هو فقط الاختلاف المستقبلي. يجب أن يحدث هذا الاختلاف في مرحلة ما.

👍 شكرًا جزيلاً لك على الاستمرار في الإجابة على أسئلة الجميع ، davidfowl & co!

NET ممتلئًا للمضي قدمًا بشكل أسرع ، لأنه لا يوفر موارد كافية على .NET full لمواكبة .NET core. انظر إلى مقدار واجهات برمجة التطبيقات المضافة إلى .NET بالكامل في العامين الماضيين. هل هذا يخبرك أن فريقًا كبيرًا يعمل على ذلك؟

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

يتجاهل حقيقة أنه يمكنك تحرير المكتبات _you_ التي تعتمد عليها كحزم netstandard2.0 بحيث يمكن تشغيل aspnet على .net ممتلئًا أيضًا. بالإضافة إلى ذلك ، فإن إجراء التغييرات على .NET full لا يخلو من المخاطر ، ولكن من فضلك لا تجعل الأمر يبدو وكأنه كومة من التعليمات البرمجية المنظمة بشكل رهيب حيث يمكن لتغيير واحد أن يجعل كل شيء ينهار.

ما زلنا نتمكن من القيام بالميزات على الرغم من كل ذلك.

نعم ، يفعل كل مطور .NET آخر ؛) بمجرد إصدار شيء ما ، ستظل عالقًا في واجهة برمجة التطبيقات هذه ، لدينا جميعًا هذا. ومع ذلك ، فأنت تريد أن تأخذ اختصارًا (مثلما فعل فريق ASPNET عدة مرات من قبل!) وتتحرك بدون هذا العبء. لكن هذا لن يطير في النهاية.

ومع ذلك ، لن يتحرك أبدًا بنفس سرعة .NET Core ، إنه أحد مكونات Windows الذي يتم شحنه وفقًا لجدول Windows.

أعتقد أن لدينا هنا جوهر الموضوع ، أليس كذلك؟ يمكن لفريق .NET الأساسي أن يفعل ما يريد دون الاتصال بـ "WinDiv" العملاق. لماذا لا تحل Microsoft هذه السياسة الداخلية داخل الشركة وتتأكد من إصدار / نقل .NET full + .NET core بشكل صحيح بدون سياسات windows؟

راجع للشغل ، ما زلت مهتمًا بكيفية بيع واجهة برمجة تطبيقات تشفير SQL Server Enterprise لمستخدمي .NET core 2.0.

أيضا ، يجب أن أضيف ؛ أنا معجب جدًا بالوقت الذي استغرقه هذا الموضوع ، مع مشاركة الكثير من الأشخاص ، بينما لا يزال متحضرًا ❤️ هذا ليس شيئًا تراه كل يوم على internetz 👏 ربما ينمو نظام .NET OSS بعد كل شيء؟ 😉

يتجاهل حقيقة أنه يمكنك تحرير المكتبات التي تعتمد عليها كحزم netstandard2.0 بحيث يمكن تشغيل aspnet على .net ممتلئ أيضًا.

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

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

نعم ، يفعل كل مطور .NET آخر ؛) بمجرد إصدار شيء ما ، ستظل عالقًا في واجهة برمجة التطبيقات هذه ، لدينا جميعًا هذا. ومع ذلك ، فأنت تريد أن تأخذ اختصارًا (مثلما فعل فريق ASPNET عدة مرات من قبل!) وتتحرك بدون هذا العبء. لكن هذا لن يطير في النهاية.

نحن نحب الاختصارات! المطورون كسالى 😄. نريد أيضًا تحسين NET Core الخاص بنا بشكل حقيقي دون تعطيل ما يمثله .NET Framework. ربما كان علينا إعادة تسميتها إلى شيء آخر ، مثل Sparkle 😄.

أعتقد أن لدينا هنا جوهر الموضوع ، أليس كذلك؟ يمكن لفريق .NET الأساسي أن يفعل ما يريد دون الاتصال بـ "WinDiv" العملاق. لماذا لا تحل Microsoft هذه السياسة الداخلية داخل الشركة وتتأكد من إصدار / نقل .NET full + .NET core بشكل صحيح بدون سياسات windows؟

اقرأ إجابتي الأخرى عن الفيزياء.

راجع للشغل ، ما زلت مهتمًا بكيفية بيع واجهة برمجة تطبيقات تشفير SQL Server Enterprise لمستخدمي .NET core 2.0.

هذا ليس مجال خبرتي ، سأدع شخصًا آخر يجيب على ذلك.

khellang lol ذلك لأن مشكلات GitHub لم تجذب المتصيدون الذين يكرهون MS حتى الآن. يعد Twitter حاليًا وسيلتهم لذلك حيث لا يوجد تصويت سلبي حتى الآن :)

تضمين التغريدة

لقد أردت فقط استخدام .NET Framework الموجود على نظام التشغيل Linux مع توافق ASP.NET 4.x القديم الجيد. هل هذا ملخص عادلة؟

لا ليس بالفعل كذلك. طلب عميلنا خدمات كاملة جديدة / لامعة (صغيرة) ، لتكملة .NET 4.x الموجودة لديهم (كانت 3.5 عندما بدأنا) تطبيقات سطح مكتب Windows.

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

أيضًا ، لا تعمل بعض خوادم ASP.NET Core الجديدة كليًا على Linux فقط ، ولكن أيضًا كخدمات Windows مع Topshelf (أعلى إطار عمل 4.6 كامل).

الأمر هو أنه تم إجراء الكثير من الاستثمار ، والآن يبدو أننا عالقون مع .NET Core 1 ، حيث أن الانتقال إلى 2 (وفقدان معيار الشبكة) يعني أيضًا أنه لا يمكننا إعادة استخدام التجميعات في تطبيق سطح المكتب الحالي (تم إنشاء الخدمات والتحرير المصاحب له) بعد الآن.

لذا فإن أهم شيء بالنسبة لنا هو الاستمرار في استخدام مكتبات .NET Core الجديدة (ASP) التي نكتبها في تطبيقات سطح المكتب .NET 4.6 (لأن هذا هو الغرض منها) ، مع التمكن من الاستمرار في دعم إصدار .NET Core طالما أن إصدار .NET لسطح المكتب مدعوم ، حيث يمكن تشغيل الكود.

لذلك ، طالما أن NET Core 1. مدعومًا مثل .NET 4.6 ، وهناك مسار ترقية خطي إلى .NET Core x عندما يخرج NET 5 ، ويكون رمز .NET Core x قادرًا على العمل. NET 5 ، فنحن بخير.

gingters هل تستخدم ميزات .net ليست موجودة في netstandard2.0 على خدمات asp.net؟

إذا لم يكن الأمر كذلك ، فيجب أن تعمل الليبس فقط. لكني أعتقد أنك تتحدث عن أشياء ليست موجودة في netstandard2.0.

davidfowl هل سيعمل c ++ / cli dlls على netcoreapp 2.0؟ لدينا تجميعات C ++ / CLI قديمة لجهات خارجية لن يتم استبدالها في أي وقت قريب.

كتب davidfowl :

لا يحتوي ASP.NET Core 2.0 على العديد من الميزات الجديدة

في هذه الحالة ، لماذا هذا التغيير المضطرب للغاية الآن؟

qrli C ++ / CLI لا يعمل على CoreCLR. إليك بعض المعلومات الأساسية حول سبب عدم دعمه: https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

امنح دعمًا لمدة 4 سنوات إلى 1x (نقل أكبر قدر ممكن من 2x) وامض قدمًا وبسرعة مع 2x. سيارة المدينة لحركة المرور البطيئة في المدينة وسيارة فيراري للطرق السريعة. لدينا الكثير من المنافسة خارج عالم .net.
إذا نجح ASP.Net Core ، فأنا متأكد من أن MS ستوفر الموارد اللازمة لدعم 1x لمدة 4 سنوات. ستتغير الثقافة في الغالب.

@ idg10 إنه في الحقيقة ليس كذلك. 2.x إلى حد كبير 1.x مع عناصر أداء متوفرة فقط في النواة. أعتقد أن الميزة الرئيسية فقط هي Razor Pages.

لذا فإن استخدامك للإصدار 1.x لا يعني أنك تستخدم إصدارًا قديمًا. لكن هذا لم يتم توصيله جيدًا.

في هذه الحالة ، لماذا هذا التغيير المضطرب للغاية الآن؟

تخمين هذا يلخصه إلى حد كبير https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

تضمين التغريدة
أعلم أنه يعمل ، كما يفعل _now_. يمكننا البقاء على 1 الآن. المشكلة تمضي قدما. عندما نريد (أو ما هو أسوأ: نحتاج) الترقية إلى مكتبات (ASP) .NET Core 2 (على سبيل المثال ، عندما يخرج 1 من الخدمة ، ويتم إصلاح ثغرة أمنية حرجة) ، فإننا نواجه مشكلة لا يمكننا ترقيتها ، لأن هذا سيجعل من المستحيل استخدام libs الخاصة بنا التي تحتاج إلى الحزم التي تمت ترقيتها في تطبيقات .NET لسطح المكتب.

تحرير / إضافة: ما لم يكن هناك إطار عمل .NET جديد كامل قادر على تشغيل .NET Core libs الجديد والمثبت على مسار ترقية خطي لتطبيق سطح المكتب القديم الحالي.

gingters لست متأكدًا من فهمي.

إذا كانت libs سطح المكتب الخاص بك تعمل مع netstandard2.0 ، فيجب أن تعمل أيضًا على core. (إذا قاموا باستدعاء مواد wpf وما إلى ذلك ، فلن يفعلوا ذلك بالطبع)
إذا كانت هذه هي الحالة ، فيجب أن تكون قادرًا على استخدام asp.net core 2.0.

إذا تعطل سطح المكتب الخاص بك في النواة لأنهم يستخدمون أشياء ليست في netstandard2.0. ثم أرى سبب حاجتك للبقاء في 1.x. وأرى لماذا تعتبر موسوعة الحياة القصيرة مشكلة.

سيكون 1.x خيارًا أسهل / أفضل إذا كنت تعلم أن 2.x يحتوي فقط في الغالب على عناصر أداء أساسية (المعنى 1.x ليس قديمًا مقابل 2.x). وأن 1.x سيحصل على تصحيحات وسيتم دعمه لسنوات *؟

hallatore إنه العكس. التطبيق القديم: مزيج من نماذج Windows و WPF و C ++ / CLI و C ++ العادي و DirectX وملايين الأسطر من التعليمات البرمجية وما إلى ذلك ص ، يعمل على 4.6 إطار كامل.

في .NET Core: مكتبات منطقية عمل جديدة (باستخدام libs الأخرى أيضًا ، مثل .NET Core version من Serilog) ، التجريدات libs + services + مكتبات العملاء لهذه الخدمات. تحتاج الخدمات إلى أن تعمل على Linux وكخدمات Windows (حاليًا Topshelf على إطار عمل .NET 4.6 كامل ، بمجرد وصول دعم خدمة Windows إلى Core يمكن تغييره ، على الرغم من ذلك).

الآن يتم أيضًا استهلاك منطق الأعمال الجديد والتجريدات بالإضافة إلى مكتبات عملاء الخدمة من تطبيقات .NET 4.6. هذا يعني أننا غير قادرين على ترقيتهم ، حيث سيحتاجون إلى العمل على إطار .net الكامل طالما أن تطبيق سطح المكتب يعمل (وهو ما يمكننا افتراض أنه سيكون إلى حد كبير طالما أن سطح المكتب يمكن أن يعيش ، ما لم يكن إطار العمل الكامل يذهب بعيدا بشكل عام).

gingters لا يزال بإمكانك الاحتفاظ بمشاريع المكتبة المشتركة في الحل الخاص بك الذي يستهدف netstandard _min (قابل للاستخدام) _ واستهلاك هذه المكتبات من كود ASP.NET Core 2.0 الخاص بك بالإضافة إلى حزمها لاستخدامها من WPF و Xamarin و UWP ، أيًا كان.

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

بناءً على ذلك ، يبدو أن MVC 5 للأحادية هو ما تريده حقًا؟

davidfowl يعني هيا. هذا إجابة رافضة ومهينة بصراحة. هل يمكن لأي شخص في MS تأكيد تعيين مطور واحد لـ Framework ASP بعد الآن؟ أنا لا أحاول أن أكون أحمق هنا ، لكن يبدو أنه في بعض الأحيان يتم التحدث إلى المجتمع باستياء.

لا يوجد سبب يدعوني إلى اعتبار أن NET Core و ASP.Net Core هما نفس المنتج. لم يكن هناك أي رسائل لدعمها على الإطلاق. خاصة عندما تفكر في أن Mono جاءت تحت جناح Microsoft _ بعد_ إعلان .Net Core. لطالما تم إرسال الرسائل على أنها إصدار xplat الأصغر والأكثر رشاقة من .Net. ليس ذلك فحسب ، بل نتذكر جميعًا الأيام التي كان فيها ASP.Net Core في الواقع ASP.Net 5 وكان يعمل في كل مكان. هيك ، هذا التغيير ما يزيد قليلاً عن عام ونصف فقط.

هل قصة HTTP ذاتية الاستضافة في netstandard20 "تستخدم Kestrel 1.x" بشكل فعال؟ لست متأكدًا من أن أفراد نانسي سيهتمون كثيرًا بهذا الأمر ، ولا أنا كذلك أنا ASP.Net 2.x قد يكون ميزة إضافية من حيث الميزات ، ولكن Kestrel 2 لديه فائدة جدية للأداء يمكننا استخدامها بجدية في اليوم يخرج.

تضمين التغريدة

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

أعتقد أن هذا تعليق مثير للاهتمام. أتذكر مشاهدة جلسة مؤتمر NDC قديمة مع davidfowl و DamianEdwards ينتقون كل ما هو قديم في ASP.NET 4 الذي كنت تريد حقًا تركه خلفك - لقد كان من الرائع حقًا الحصول على نظرة خاطفة داخل هذا الصندوق الأسود من التعليمات البرمجية.

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

لا أعرف ما هي الإجابة الصحيحة. لكنني أعلم أنه بالنسبة لتطبيقاتنا الخاصة ، سنستخدم إطار العمل الكامل و ASP.NET4 / MVC5 للمستقبل المنظور (لا يزال لدينا جزء كبير من WebForms لن تتم إعادة كتابته لبعض الوقت!). آمل أن أرى MVC5 يحصل على بعض الحب الآن بعد أن _ أخيرًا_ انتقل إلى GitHub - أنا على استعداد للتبرع بوقتي وجهدي الخاص لتحسينه (على سبيل المثال ، دعم غير متزامن أفضل ، وتحسينات في الأداء ، وما إلى ذلك).

qrli Enterprises لا يزال لديها .NET 4.5 كامل لتشغيلها على مزارع الويب Windows Server 2008 R2 IIS 7.5. لا أحد يأخذ ذلك منهم.

تضمين التغريدة

هل قصة HTTP ذاتية الاستضافة في netstandard20 "تستخدم Kestrel 1.x" بشكل فعال؟ لست متأكدًا من أن أهل نانسي سيهتمون بشدة بذلك ، ولا أنا كذلك.

HttpListener هو جزء من netstandard20 لذلك لا يتم أخذ شيء netcore20 بعيدًا على هذه الجبهة من خلال الانتقال إلى netcore20.

HttpListener هو جزء من netstandard20 وبالتالي أيضًا netcore20.

وأفترض أنه يمكنني توقع نفس الطلبات في الثانية من HttpListener ؟

تضمين التغريدة الى الان.

ولكن ما الذي تقترحه عندما تقوم مكتبات أخرى مستخدمة من قبل المواد المشتركة لدينا (مثل serilog و newtonsoft و autofac وما إلى ذلك) بإسقاط دعم netstandard_min (قابل للاستخدام) ، (ربما فقط لأنهم يشعرون أن هناك الكثير من الجهد لدعم كلا العالمين) و هل توجد مشكلة أمنية خطيرة تم اكتشافها في أحدث إصدار ولا تزال تدعم إطار العمل الكامل؟

تضمين التغريدة

HttpListener هو جزء من netstandard20 وبالتالي أيضًا netcore20.

وأعتقد أنه يمكنني توقع نفس الطلبات في الثانية من HttpListener؟

حسنًا ، نانسي هو .NETStandard 1.6 لذا يمكنك استخدامه على Core 2.0 واستخدام Kestrel 2.0. أفضل؟

gingters أود أن أقترح عبور هذا الجسر عندما تصل إليه.

لا تدع المستقبل يزعجك. ستقابلها ، إذا كان عليك ذلك ، بنفس أسلحة العقل التي تسلحك اليوم ضد الحاضر.
_ ~ ماركوس أوريليوس_

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

إذا كان لا بد من عدم تغييرها إلى حد كبير لسنوات قادمة ، فلماذا يهم ما يحدث للمكتبات التي تعتمد عليها في السنوات القادمة؟

markrendle الآن افترض أنك مطالب ، بموجب القانون (على الأقل في بعض البلدان) ، بتوفير بروتوكولات الطوارئ لهذه الحالات بالضبط ، قبل إصدار نسخة من التطبيق ، حيث يمكن استخدامها في البيئات التي قد تكون فيها حياة الناس على المحك .

إذن أنت تريد خادم ويب سريعًا مثل Kestrel ، ومتطلبك المحدد الوحيد هو أنه ليس Kestrel؟

حسنًا ، نانسي هو .NETStandard 1.6 لذا يمكنك استخدامه على Core 2.0 واستخدام Kestrel 2.0. أفضل؟

markrendlebenaadams لا ، أعتقد أنك تسيء الفهم ، ومرة ​​أخرى ، لا تحاول أن تكون أحمق ، فقط أشير إلى أن هناك عملاء آخرين لقطع ASP.Net Core ليست كل شيء. أود فقط استضافة منصة الإنتاج الخاصة بنا فوق Kestrel 2.0 عند طرحه ، وقد تكون منصة الإنتاج الخاصة بنا على Framework لفترة من الوقت. لا يمكنني استهداف netcoreapp20.

قد تكون نانسي معيارًا قياسيًا 16 لكن هذا لا يهم لأنني لا أستطيع استخدام Kestrel 2.0 باستثناء Core 2.0. أدرك أن هذا محدد ، وربما الإجابة هي حقًا "ثم اكتب خادم الويب الخاص بك الذي يعمل على إطار عمل سريع مثل Kestrel 2. Kestrel مخصص لـ ASP.Net فقط." لكني أكره أن تكون هذه هي الرسالة.

gingtersgulbanana لا أفهم كيف سيتعطل تطبيق مشحون بمجموعة ثابتة من التبعيات لأن مشروع مفتوح المصدر يتوقف عن دعم نسخة عشوائية من إطار العمل الأساسي في تاريخ مستقبلي مفترض.

mattnischan نعم ، اكتشفت ما تعنيه وحذفت هذا التعليق :)

تضمين التغريدة

لأنني بحاجة إلى مشاركة التعليمات البرمجية بين الخادم وتطبيقات سطح المكتب الخاصة بي ، فهل هذا يعني أنه لا يمكنني الحصول على أحدث إصدار من ASP.Net؟

إذا كنت تستهدف NET Standard مع مكتباتك ، فيمكنك استخدامها في كل من Desktop و Core. بالنسبة للمكتبات الهدف .NET Standard ، إذن لديك دعم شامل للنظام الأساسي: Desktop و Core و Mono و Unity و UWP و Tizen وما إلى ذلك

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

NET Core هو نظام أساسي جيد لأنه يحتوي على تغطية واسعة عبر الأنظمة الأساسية ؛ يمكن تثبيته جنبًا إلى جنب مع سطح المكتب ويمكن ترقيته بشكل مستقل عن طريق التطبيق ؛ بدلاً من الجهاز كله وكل تطبيق.

بعض العناصر لها استخدامات في الخارج ؛ لذلك يستخدم Wyam Razor لإنشاء موقع ثابت ؛ يعد Razor حاليًا .NET Standard 1.3 ، لذا فإن استهلاكه خارج Core ليس مشكلة في الوقت الحالي.

هناك بعض حالات الحافة المذكورة أعلاه:

استخدام مكتبات لا تدعم مجموعة ميزات .NET Standard 2.0. ونأمل أن يكون الكثير منها عبارة عن فجوات يمكن سدها - وفي بداية هذه المشكلة ، كان MS يسأل عن ماهية هذه الفجوات حتى يتمكنوا من ترتيب أولوياتها.

تشغيل تطبيق ويب مضمن على سبيل المثال تطبيق UWP ؛ ومع ذلك ، إذا كان سطح المكتب لا يزال مدعومًا ولكن تم تغييره إلى الإصدار 4.7.1 ، فستظل في نفس الموقف حيث لا يدعم UWP حاليًا 4.7.1 وبحلول الوقت الذي كان فيه ASP.NET يتطلب 4.7.2 ، ثم 4.7. 3 إلخ. ستكون مهمة عبثية لأن المنصات الأخرى لن تلتقطها أبدًا ؛ لذلك سيكون مجرد عمل مزدحم دون جدوى؟

نعم ، لقد اكتشفت ما قصدته وحذفت هذا التعليق :)

لا تقلق يا سيدي. 👍

تضمين التغريدة

كيف تؤثر إصدارات ASP.NET Core على ذلك؟ إذا أسقطنا دعم .NET Framework في 3.0 (كما يبدو أن الناس يتهربون من هذا الموضوع) ، ألن تكون في نفس الطريق المسدود بغض النظر؟ سيكون لديك تطبيق ASP.NET Core 2.0 الخاص بك قيد التشغيل على إطار العمل لمدة عام وعندما يتم إصدار 3.0 ، لن تتمكن من الترقية. ستكون قادرًا على القيام بذلك على أي حال باستخدام ASP.NET Core 1.1.x الذي يعمل على .NET Framework ويكون مدعومًا حتى عندما يكون ASP.NET Core 2.0 خارج.

مجرد قول (كما أفهم) أنه "في وقت ما كنا بحاجة إلى الانفصال عن .net بالكامل لماذا لا الآن" يفتقد نقطة مهمة. أنا متأكد من أن الكثير من الناس كانوا ينتظرون إصدار Core 2.0. لأنه وعد علنًا بالكثير من التحسينات في التوافق مع .net الكامل. لذا فإن العديد من مؤلفي المكتبات ينتظرون أيضًا بدء الترحيل إلى المركز. لذلك أعتقد أنه بعد إصدار Core 2.0 ، سنقوم بترحيل المزيد من libs على Core. وبالتالي فإن ربط نواة asp.net بالنواة 3.0 سيكون أقل إحباطًا للنظام البيئي مما هو عليه الآن. لأنه في لحظة 3.0 ، يجب ألا تمنع هذه الأشياء من الانتقال إلى النواة.
الآن هي كارثة.

في السابق كنت أقوم بتقييم بدء ترحيل إطار العمل الخاص بنا (قصة مشابهة جدًا لما وصفته benaadams ) إلى core / asp.net الأساسية في خطوتين: ترحيل جزء الويب (الموجود على mvc / webapi الآن) إلى asp.net core واحتفظ به بالكامل .net ثم يقوم بترحيل جميع العناصر الأخرى الموجودة في core عندما يكون لجميع التبعيات تطبيقات مقابلة لـ core. ما يحظرنا حاليًا هو موفر Oracle ADO وموفر Postgres ADO (قد تكون هناك حالات عدم توافق أخرى في corefx لم نتعمق فيها بعد). الآن هذه الخطة ميتة. لذلك علينا أن نجلس وننتظر هجرة التبعيات وترك كل الأشياء الجديدة في Core world. وكل هذا بسبب حقيقة أن شخصًا ما في MS قرر أننا بحاجة إلى منصة "التحرك بسرعة".

markrendle التطبيق لن ينكسر فقط بسبب ذلك. القضية مختلفة:
نظرًا لأن .NET Core 2 أسقط دعمًا للإطار الكامل (حيث كان يعمل بشكل جيد في الإصدار 1 ، وهو من Microsoft حيث لا تتوقع أن يتم إسقاط مثل هذه الميزة الأساسية الأساسية عند التحديث إلى إصدار جديد) ، قد يُسقط التبعيات الدعم لهذا السيناريو عاجلاً وليس آجلاً.
يجد شخص ما مشكلة أمنية خطيرة في إحدى المكتبات المستخدمة ، ولم يتم إصدار أي تحديث للإصدار الذي لا تزال عالقًا فيه ، لأن الإصدارات الأحدث لا تدعم وقت التشغيل بعد الآن. الآن ، نظرًا لاستخدام تطبيقك في بيئة شديدة التنظيم ، فأنت بحاجة إلى تقديم خطة طوارئ تشرح بالضبط ما ستفعله عند اكتشاف مشكلة أمنية خطيرة وكيفية طرح هذا الإصلاح لمنع الأشخاص من التعرض للأذى أو الأسوأ. ستؤدي عبارة "حسنًا ، لا يمكننا فعل أي شيء" إلى إلغاء السماح الخاص بك لشحن هذا التطبيق.

gingters انظر ، النقطة المهمة هي أنه يتعين عليك تحديد اختياراتك التقنية بناءً على المعلومات المتوفرة حاليًا وطبيعة السوق الذي تعمل فيه شركتك. مع أفضل الإرادة في العالم ، لا يمكنك حساب جميع الاحتمالات ، مهما كان البيروقراطيون والمنظمون في العالم يرغبون في التظاهر بأنك تستطيع ذلك. ماذا لو تم الاستحواذ على Microsoft في عملية استحواذ عدائية من قبل Apple وتوقف .NET تمامًا لصالح Swift؟ ماذا لو أصبح التشفير القوي غير قانوني في أحد البلدان التي تبيع لها ، وتم حظر جميع حزم البرامج التي تتضمن SHA256؟ ماذا لو قرر نيكولاس أو جيمس أو _Inert-name-of-Autofac-صيانة- هنا_ الانتقال إلى المريخ ليصبحا مزارعي الرطوبة؟ ماذا لو انعكست الأقطاب المغناطيسية وتم مسح كل جزء من البيانات المسجلة رقميًا؟

كإجابة فعلية على السؤال عما تقوله ، كشركة ، أنك ستفعله في حالة وجود مشكلة أمنية خطيرة في JSON.NET (على سبيل المثال) ، في حالة عدم توفر تحديث رسمي ، فإن الجواب المحتمل هو "سنقوم بتقسيم JSON.NET" ، والذي أعتقد أنه بالفعل إجابة لسؤال ما الذي ستفعله إذا أصبح جيمس نيوتن-كينج مهزوزًا لأي سبب من الأسباب. في تجربتي السابقة في العمل في هذه الأنواع من الأسواق ، كانت هناك ترتيبات ضمان لكود المصدر لحزم الملكية لهذا النوع من الاحتمالات ؛ ما يجب فعله حيال حزم البرامج مفتوحة المصدر أمر تافه بالمقارنة مع ذلك.

وكل هذا بسبب حقيقة أن شخصًا ما في MS قرر أننا بحاجة إلى منصة "التحرك بسرعة".

"التحرك بسرعة" قد يكون مبالغا فيه ؛ وفقًا لجدول الإصدار السابق لـ Full Framework ، قد يكون من الأفضل ذكره على أنه "بدون إضافة تأخير إضافي لمدة عام إلى عامين" في الشحن. هذا هو مقدار الوقت المجنون في عالم الويب.

تتغير الأمور بسرعة ويجب أن تظل المنصة ملائمة.

davidfowl و DamianEdwards أعتقد أن هذا الالتباس برمته جاء من حقيقة أن ASP.NET Core 1.x يمكن تشغيله على .NET Framework. أدى ذلك إلى افتراض أن ASP.NET Core هو تطور ASP.NET 4 / MVC5 ؛ جعل الناس يهاجرون إليها معتقدين أنهم سيحصلون على جميع الفوائد (السرعة والميزات الجديدة) مع الحفاظ على التوافق مع الإصدارات السابقة.

لذلك ربما تكون الإجابة طويلة المدى / الدائمة لهذه المشكلة هي إعادة الترويج لـ ASP.NET 4 / MVC5 كإجابة للأشخاص الذين يسعون إلى التوافق مع الإصدارات السابقة مع الدعم طويل المدى (وربما يعرضون إجراء تحسينات صغيرة أيضًا).

بعد ذلك ، يمكن أن يركز ASP.NET Core على كونه نظامًا أساسيًا جديدًا يبتعد عن الماضي لتقديم فوائد ضخمة ، لأولئك الذين يمكنهم القفز.

في ضوء ذلك ، سيكون (ASP) .NET (Framework) و (ASP) .NET Core طريقين متوازيين وصالحين بنفس القدر يمكن للعملاء اختيارهما. وأعتقد أن هذه هي الطريقة التي كان ينبغي أن تكون عليها الأمور منذ البداية.

markrendle نعم ، هذا تفكير ، لكن البيروقراطية للأسف شيء حقيقي. ونعم ، لا يمكنك (ولا تحتاج إلى) حساب جميع الاحتمالات. فقط لمن يمكنك توقعه.

والآن لدينا الموقف المتمثل في (أ) إسقاط نظام أساسي كامل (.NET full framework) ، والذي كان مدعومًا في .NET Core 1 بشكل جيد ، لم يكن شيئًا يمكن توقعه. ومع ذلك ، نظرًا لأنه حدث الآن ، يمكنك ب) توقع انخفاض الدعم لـ v1 في تبعياتك الأخرى مع التأكد تمامًا من "نعم ، يمكنني أن أرى ذلك يحدث تمامًا عاجلاً وليس آجلاً".

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

gingters اعتقدت أننا كنا في المرحلة التي كنت سعيدًا فيها بتشغيل بتات الويب ASP.NET Core على .NET Core 2.x أو ما بعده ، واستخدام .NET Standard 2.x لمشاركة المكتبات بين Core و Full / UWP / أيًا كان . لأنه إذا قامت هذه المكتبات بإسقاط الدعم لـ .NET Standard 2.x لصالح .NET Core 2.x فقط ، فسوف تقوم بإسقاط الدعم لـ .NET الكامل أيضًا ، وأنت في كلتا الحالتين.

markrendle حتى النقطة التي لدينا فيها مشكلة حرجة في إحدى وحدات بت ASP.NET الأساسية التي نحتاج إلى استخدامها في العناصر المشتركة بعد عدم دعم 1x بعد الآن.

gingters لحسن الحظ أنه مفتوح المصدر ويمكنك دعم نفسك (أو الدفع لطرف ثالث) إذا لزم الأمر!

تضمين التغريدة مشاريع الإرث الخالص ماتت. عادة ما تكون مشاريع المؤسسات عبارة عن مزيج كبير من التعليمات البرمجية التي تحتوي على كود / ليبس يعود تاريخه إلى عقود ماضية إلى جديدة. كونك netcoreapp يعني فقط أنك أزلت القدرة على الاختلاط. لذلك لم يعد بإمكاننا الانتقال إلى نسختك الجديدة الرائعة ولكننا مقفلين على الإصدار القديم. وسيقول لي زملاء العمل المناهضون لمرض التصلب العصبي المتعدد بسعادة "أخبرتك ..." ثم يدفعوننا إلى الانتقال إلى حلول Google.

أنا لا أطالب بدعم netfx للأبد. لكني أشعر بشدة أن netfx يجب أن تكون مدعومة من قبل asp.net الأساسية لمدة عامين على الأقل من الآن. ليس فقط 1.x ولكن أيضًا 2.x.

qrli تلك "مشاريع المؤسسة ... قاعدة بيانات المزيج الكبيرة التي تحتوي على كود / ليبس يعود تاريخه إلى عقود ماضية إلى جديدة." هي كل ما هو خاطئ في مشاريع المؤسسة ويحتاج إلى التوقف. إن الشكوى من أن التكنولوجيا الجديدة تمنعك من إلقاء المزيد من كتل الوحل في كرة كبيرة من اليأس المتماسكة مع الحشوات وأسلاك بالات والرفض يشبه الشكوى من أن آلة القطع بالليزر الصناعية الجديدة تأتي مع ميزات أمان تمنعك من الانحناء والقطع أجزاء مهمة من نفسك.

تضمين التغريدة

"التحرك بسرعة" قد يكون مبالغا فيه ؛ وفقًا لجدول الإصدار السابق لـ Full Framework ، قد يكون من الأفضل ذكره على أنه "بدون إضافة تأخير إضافي لمدة عام إلى عامين" في الشحن. هذا هو مقدار الوقت المجنون في عالم الويب.

تتغير الأمور بسرعة ويجب أن تظل المنصة ملائمة.

هذا قيد سياسي / تنظيمي ، وليس تقنيًا. انظر إلى كيفية تحرك JVM / Java. إذا كانوا يتحركون على الإطلاق. لا تزال صالحة ، أكثر بكثير من .NET اليوم. لذا فإن "التحرك بسرعة" ليس السبب الذي يجعل الناس يختارون Java / JVM. على العكس تماما. اختاروا Java / JVM لأنها تفتقر إلى جميع الجوانب السلبية المرتبطة بـ "التحرك السريع": إنها منصة مستقرة ويمكن الاعتماد عليها ، حيث لا يضيع استثمارك في 1-2 سنوات.

لا أعرف ، إذا أراد MS نقل .net بسرعة كاملة ، فسوف يتحرك بسرعة. هم يمتلكونها ، يمكنهم أن يقرروا ماذا يفعلون. لكن الصلاحيات التي يمكن أن تكون لا تعطي الكثير عن ذلك: .net full "جيدة بما فيه الكفاية" لما هي عليه الآن.

لقد نام MS على عجلة القيادة لسنوات عديدة ، والآن أصبحت كل الأشياء المفاجئة مثل الأداء وضغط الذاكرة مهمة (لا شك في ذلك) ، بينما في JVM ، تم تنفيذ استثمارات الأراضي في تلك الجوانب الخاصة من وقت التشغيل للعديد سنوات وهذا يؤتي ثماره.

لا أعرف ما هو الحل ، على المدى القصير ، ولكن على المدى الطويل ، مع ترك .NET مقسمًا عبر قسمين رئيسيين (.net مليء بالنوافذ ، و. net core مع devdiv) بدون أرضية / أهداف مشتركة بخلاف نفس الشيء صاحب العمل لا يبشر بالخير بالنسبة لنا نحن الغرباء.

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

kolectiv هذا صحيح ، لكن قبول أن المؤسسات لن تتوقف فجأة عن كونها مؤسسات لا يعني أنه يتعين عليك تشجيع / تمكين هذا النوع من السلوك بنشاط.

لا ينبغي أن يعني ذلك أيضًا أن تطبيقات _my_ يجب أن تعمل بشكل أبطأ وأن تكلف استضافتها أكبر.

تشغيل تحليل قابلية النقل على مكتباتنا المستخدمة بكثرة والتي لا تزال تستهدف .NET 4.x على ASP.NET Core 1.x (EF6 و NHibernate و NServiceBus) والرجل ، فإن هذه libs ليست قريبة حتى من القدرة على استهداف netstandard20 .

ليب | Pct
---------- | ---------
EF6 | 62.74
NHibernate | 67.39
NServiceBus | 65.68

ولا تزال هناك فجوات كبيرة في واجهات برمجة التطبيقات المفقودة. لا يزال EF Core به فجوة كبيرة مع EF6 ، وما زلنا نستخدم NHibernate عندما تكون هناك ميزات رئيسية غير موجودة في EF6. NServiceBus نستخدمه في أي مشروع يقوم بإرسال الرسائل.

يا للعجب.

تضمين التغريدة

تلك "مشاريع المؤسسة ... قاعدة بيانات المزيج الكبير التي تحتوي على كود / ليبس تعود إلى عقود ماضية إلى جديدة." هي كل ما هو خاطئ في مشاريع المؤسسة ويحتاج إلى التوقف. إن الشكوى من أن التكنولوجيا الجديدة تمنعك من إلقاء المزيد من كتل الوحل في كرة كبيرة من اليأس المتماسكة مع الحشوات وأسلاك بالات والرفض يشبه الشكوى من أن آلة القطع بالليزر الصناعية الجديدة تأتي مع ميزات أمان تمنعك من الانحناء والقطع أجزاء مهمة من نفسك.

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

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

markrendle لست متأكدًا تمامًا مما تقترحه؟ هل نتخلى عن 15 مليون سطر من كود C # ونكتبها كلها من جديد؟ كنا نتطلع إلى الانتقال (ببطء) إلى الإصدار 2.0 القياسي ونأمل أن نتمكن من الوصول إلى أشياء مثل Span وما إلى ذلك عندما ظهرت ، لكن مثل هذه المشكلات تجعلني أشك في أن هذا أمر حكيم.

نود دعم Linux ولكن هذا يبدو أشبه بالاختلاف. لقد افترضت أن netstandard سيمضي قدمًا في التطبيق الأكثر تقدمًا ومن ثم ستلحق أشياء مثل إطار العمل بالركب ، لكن على الأقل كنا نعلم أنه سيفعل ذلك.

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

markrendle ما الغباء في الرغبة في الاستمرار في تشغيل التعليمات البرمجية؟

اختاروا Java / JVM لأنها تفتقر إلى جميع الجوانب السلبية المرتبطة بـ "التحرك السريع": إنها منصة مستقرة ويمكن الاعتماد عليها ، حيث لا يضيع استثمارك في 1-2 سنوات.

ويمكنك استخدام System.Web بشكل أساسي إلى الأبد ؛ إنه مخبوز في Windows مما يعني أنه من المحتمل ألا يختفي أبدًا. لا تحصل على الكثير من الاستقرار ويمكن الاعتماد عليه من ذلك.

ASP.NET Core 1.x -> ASP.NET Core 2.x ؛ جميع واجهات برمجة التطبيقات هي نفسها إلى حد كبير التغيير الرئيسي هو إسقاط دعم .NET Framework. حتى أنه يغير semver للكسر 😱

يعمل ASP.NET Core 1.x على .NET Core 2.x و .NET Framework ، ويدعم .NET Standard 2.x (عبر .NET Core 2.x) ؛ وله نفس apis مثل ASP.NET Core 2.x ، لذلك هذا هو الإصدار الأساسي.

ASP.NET Core 2.x هو الإصدار الفاصل. لا يزال يدعم .NET Standard 2.x (عبر .NET Core 2.x) ولم يتغير الكثير من واجهة برمجة التطبيقات بين ASP.NET Core 1.x و ASP.NET Core 2.x ؛ لكنه يسقط .NET Framework.

يمكن أن يكون البديل:

• ASP.NET Core هو المضي قدمًا والعمل على شيء مثل netstandard3.0 (يمكن أن يكون 2.x) وإصدار netstandard بشكل أسرع. مرة كل ربع سنة.
• يمكن أن يقفز الإصدار التالي من NetFx مرة أخرى لدعم netstandard3.x متى كان الإصدار التالي. لن يكون من الضروري حتى أن يكون أحدث معيار.

قد تكون هذه فكرة سيئة لأن كل شيء مستخدم قد لا يحتاج إلى أن يكون جزءًا من معيار الشبكة ولكن على الأقل ASP.NET Core 2.x قد يستهدف معيارًا ستستخدمه الأطر الأخرى في النهاية.

مجرد البصق الكرات. أنا متأكد من أن هذا قد تم طرحه.

bencyoung أقترح فقط أنه من الأنانية بعض الشيء الإصرار على أن العالم بأسره يجب أن يدور حول 15 مليون سطر من كود C # العامل (الذي لن يتوقف عن العمل ، راجع للشغل). لذلك لا يمكنك استخدام ASP.NET Core 2.0. لا يزال لديك إطار عمل Windows فقط ASP.NET الذي يحتوي على دعم قديم يعمل من خلاله مثل Brighton من خلال Rock. لذلك هناك لعبة جديدة لا يمكنك اللعب بها لأنها ليست مجدية اقتصاديًا بالنسبة لك لنقل الكود الخاص بك وإعادة بناء / إعادة تصميم تطبيقك. هذا مقرف ، لكن تفعل الكثير من الأشياء أيضًا. ولكن إذا تجنبت Microsoft كل شيء لن ينجح مع قواعد الرموز القديمة الموجودة مسبقًا والتي تعود إلى عقدين من الزمن والتي ربما لا تزال تتضمن مكونات COM مكتوبة في VB 6.0 ، فعندئذٍ في 20 عامًا أخرى ستكون Micro Focus.

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

يمكن أن يقفز الإصدار التالي من NetFx مرة أخرى لدعم netstandard3.x عندما يكون الإصدار التالي.

يعد تحديث .NET Framework تحديثًا إجباريًا لكل جهاز يعمل بنظام Windows (في الغالب) على الكوكب.

تحديث NET Core هو تحديث تختاره لتطبيق فردي تختاره .

هم وحوش مختلفة جدا.

حسنًا ، من السهل إيقاف الارتباط بهذه الصفحة من الصفحة الأولى من مستندات ASP.NET Core .

(أو قم ببساطة بإضافة سطر "لا تختر .NET Framework إذا كنت تريد الاستمرار في استخدام ASP.NET Core!".)

سيكونون التزامًا بأن .NET framework سيلحق به في النهاية.

يوجد https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

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

ولكن بحلول الوقت الذي يتم فيه اللحاق بالركب ، سيكون ASP.NET قد انتقل إلى الإصدار التالي من .NET Standard ولن يكون الإصدار الصحيح من .NET Framework لـ ASP.NET ؛ سيكون دائما وراء.

markrendle لا ، هم ليسوا كرة طينية كبيرة. المزيج الكبير لا يعني أنهم مهندسين سيئين. هم وحدات. هذا هو أن العديد من الوحدات عبارة عن كود تم اختباره في المعركة تم كتابته منذ فترة طويلة بواسطة أشخاص أذكياء حقًا أو تم شراؤها من طرف ثالث. بعضها عن طريق c ، والبعض الآخر في فورتران ، والبعض الآخر في c ++ / cli ، وما إلى ذلك للترحيل أو إعادة الكتابة ، نحتاج إلى فهمها ، وقراءة الأوراق ، وجمع المزيد من بيانات الاختبار الحقيقية ، وإعادة اختبار الإصدار الجديد. يتطلب الأمر مجهودًا ولكن مثل هذه المهام لا يتم وضعها في الميزانية أبدًا ، ولكن الأمر متروك لأنفسنا. رجال الأعمال لا يهتمون باستخدام .net core أم لا ، لكنهم يريدون إنجاز الميزات. وبالنسبة للجهات الخارجية ، يتعين علينا حثهم أو البحث عن بديل.
لذلك ، قد يستغرق الأمر بضع سنوات من الناحية العملية.

تضمين التغريدة

ويمكنك استخدام System.Web بشكل أساسي إلى الأبد ؛ إنه مخبوز في Windows مما يعني أنه من المحتمل ألا يختفي أبدًا. لا تحصل على الكثير من الاستقرار ويمكن الاعتماد عليه من ذلك.

ASP.NET Core 1.x -> ASP.NET Core 2.x ؛ جميع واجهات برمجة التطبيقات هي نفسها إلى حد كبير التغيير الرئيسي هو إسقاط دعم .NET Framework. حتى أنه يغير semver للكسر 😱
يعمل ASP.NET Core 1.x على .NET Core 2.x و .NET Framework ، ويدعم .NET Standard 2.x (عبر .NET Core 2.x) ؛ وله نفس apis مثل ASP.NET Core 2.x ، لذلك هذا هو الإصدار الأساسي.
ASP.NET Core 2.x هو الإصدار الفاصل. لا يزال يدعم .NET Standard 2.x (عبر .NET Core 2.x) ولم يتغير الكثير من واجهة برمجة التطبيقات بين ASP.NET Core 1.x و ASP.NET Core 2.x ؛ لكنه يسقط .NET Framework.

نعم ، ودعنا نرى ما هي الخيارات حقًا :) ASPNET Core 1.x هي طريق مسدود: يمكنك الانتقال إلى ذلك ولكن لا يمكن الانتقال إلى الكود الخاص بك. قد لا يتم نقلها إلى .net core / القياسي عند انتهاء الدعم. يعد اختيار ASP.NET core 1.x أمرًا حكيمًا فقط إذا كانت تبعياتك موجودة بالفعل على netstandard2.0 / .netcore ، فيمكنك الانتقال إلى asp.net core 2.x دون مشاكل ، مع العلم أنك لا تصل إلى طريق مسدود.

اقتراحك لاختيار system.web كبديل لـ nginx ومكدس JVM إذا كنت تريد الاستقرار ضعيفًا بعض الشيء ، ألا تعتقد ذلك؟ :) يتعلق الأمر بخيارات مؤسسة كبيرة ما الذي تختاره كمنصة. ما لم يقموا بإنشاء تطبيق جديد تمامًا ولا يتعين عليه العمل مع التبعيات الخارجية (نادرًا) ، فمن المحتمل أن يأخذوا الرهان الآمن ، ولماذا لا يفعلون ذلك؟ إذا كان الأمر يتعلق بـ system.web أو JVM / nginx ، فسيكون الاختيار بسيطًا جدًا.

إنها الأشياء الصغيرة. لقد توصلت إليه من قبل: ميزات تشفير مؤسسات خادم SQL. لن تستخدم هذه على .net core لأنها ليست موجودة. وحي؟ لا. لذلك إذا كنت ترغب في استخدام asp.net core وهذه الميزات ، فعليك استخدام .net full و asp.net core 1.x. ولكن ماذا يحدث إذا لم يتم نقل / توفر هذه الميزات عند انتهاء دعم asp.net core 1.x؟ (ومن يريد المراهنة على المزرعة على منصة موجودة في "وضع QFE" بالفعل؟) رجوع إلى system.web؟

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

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

بصفتنا كاتبًا لبرنامج HPC يستخدم .NET بكثافة ، فقد طبقنا أيضًا تحليل التخصيص الصفري الخاص بنا وما إلى ذلك دون إجراء تغييرات على النظام الأساسي الأساسي. هل سنستفيد من سبان وما إلى ذلك؟ إطلاقا! هل يمكننا التبديل إلى .NET Core؟ ليس لوقت طويل. هل سنرى إضافة Span وغيرها إلى .NET Framework؟ يبدو من الصعب القول الآن دون أن يكون التزامًا قياسيًا ...

markrendle بالتأكيد ، ولكن ما هي خطتنا الانتقالية؟ لا يمكنني رؤية مسار لا يصل إلى مسارات غير مدعومة. إذا كانت التغييرات في معيار الشبكة ثم استخدمها ASP.NET Core ، فسنعرف على الأقل أنه كان هناك مسار في النهاية ...

markrendle لست متأكدًا من المستخدمين المستهدفين لنواة asp.net. ولكن ما رأيته في الغالب هم مستخدمي .net الذين لديهم استثمارات كبيرة في .net وقاعدة بيانات كبيرة (ليست سيئة). إذا لم نكن المستخدمين المقصودين ، فأنا لا أرى أن node.js / python / go guys تعطي .net sh * t ، بغض النظر عن مدى جودة تفكيرنا. net.
إذا لم يكن من أجل الشركة ولكن لمشاريعي الخاصة ، فلن أستخدم ASP ولكني سأستخدم نانسي بدلاً من ذلك. تحتاج الشركات إلى ضمان ودعم مستقرين. وهم / ندفع أموالاً طائلة مقابل ذلك.

سيكون الحل السهل لهذه المشكلة ، إذا قامت Microsoft بعمل توزيع Windows فقط لـ CoreCLR الذي يدعم النطاق الكامل لمكتبات .NET Framework.

الجانب الشخصي بداخلي هو اللعب الرائع مع .NET Core على PI على ubuntu ولكن الجانب التجاري لم يأخذ حتى في الاعتبار .NET Core لأن .NET Framework يقوم بكل ما نحتاجه و .NET Core يمثل مشكلة فقط بالمقارنة. كانت معظم هذه المشكلة تتعلق بالأدوات وتجهيز الجميع حتى تختفي هذه الآلام أخيرًا ، لكنها لا تزال تفتقر إلى الكثير من الميزات ... لم تقترب EF Core من كونها ناعمة بدرجة كافية لاستبدال EF6 أو NHibernate وقد فازوا لا تعمل على .NET Core 2 أيضًا. يعد عدم وجود WCF (مضيف) لخدمات SOAP عبئًا كبيرًا ، نظرًا لما نقوم به طوال اليوم في الاتصالات التجارية ، ولكن من المحتمل أن يتم ترحيله من خلال التصميم الذكي واستخدام .NET Core و .NET Framework في تطبيقات متعددة. لا يتم أيضًا استبدال AppDomains بسهولة على الرغم من أن هذا هو أقل ما لدي من مشاكلي. كانت القفزة من ASP.NET MVC 5 إلى MVC Core سهلة بشكل غير متوقع لإعادة الكتابة ولكن الانتقال إلى .NET Core يجعل VS يتوقف عن التعاون ، ويعرض جميع الأخطاء.

ستكون الأشياء الممتعة مثل استضافة ASP.NET Core داخل WPF مستحيلة أيضًا.

لا يهم حتى إذا كان توزيع Windows CoreCLR سيكون مغلق المصدر لأنه لا يختلف كثيرًا عن .NET Framework اليوم.

المعذرة الآن بينما أبكي بهدوء وحذف الفروع التجريبية التي تم ترحيلها إلى ASP.NET Core.

اقتراحك لاختيار system.web كبديل لـ nginx ومكدس JVM إذا كنت تريد الاستقرار ضعيفًا بعض الشيء ، ألا تعتقد ذلك؟

انها النهاية المتطرفة؛)

إذا كان الأمر يتعلق بـ system.web أو JVM / nginx ، فسيكون الاختيار بسيطًا جدًا.

نعم ، إذا كان بإمكانك استخدام JVM ، فأنت تستخدم ASP.NET Core 2 نظرًا لعدم وجود حاصرات ولديه إمكانية تشغيل متداخل جيدة و p / استدعاء :)

إذا كانت واجهات برمجة التطبيقات "متشابهة إلى حد كبير" ، فلماذا لا تحتفظ بإصدار واحد له ترقيم 2x للجميع ، ولكن لديك خيار للاختيار من أجل "netstandard" أو "netcore"؟

لأن الأجزاء الداخلية هي التي تتغير ؛ والاستفادة من التغييرات في وقت التشغيل و jit والمكتبات القياسية. بالنسبة إلى المستخدم ، تظهر في الغالب كما هي حيث يكون التوافق بين ASP.NET 1.x و 2.x ؛ على السطح المكشوف لواجهة برمجة التطبيقات ، وليس على الأجزاء الداخلية "إليك كيفية عملها".

يبدو لي أن جزءًا من المشكلة هو أن ASP.NET يقود تطور .NET Core مباشرة.

مثل الآخرين. يمكنك تقديم طلب API في dotnet / corefx كما فعلت على سبيل المثال لـ ValueTask ؛ والتي تطورت بعد ذلك إلى إعجابات المهام وأصبحت الآن جزءًا من C # 7.

بمجرد أن يتم تضمين واجهة برمجة التطبيقات الخاصة بك في .NET Core ، يمكنك البدء في استخدامها (إذا كنت تبحث عن برامج ليلية وتريد التأكد من أن واجهة برمجة التطبيقات مناسبة) ؛ أو في الإصدار التالي من Coreclr / corefx إذا كنت تريد الانتظار لمدة 6 أشهر.

ثم يتم تحديث ASP.NET لاستخدامه عند إصداره.

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

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

هل برنامج HPC الخاص بك معلق مباشرة بطلبات الويب؟ على سبيل التخمين ، قد يكون هناك قوائم انتظار مدفوعة بطلبات الويب ، لكنها تعمل في عملية منفصلة ، لذا يجب ألا تتأثر بهذا التغيير؟

هل سنرى إضافة Span وغيرها إلى .NET Framework؟

نعم

تضمين التغريدة

ولكن بحلول الوقت الذي يتم فيه اللحاق بالركب ، سيكون ASP.NET قد انتقل إلى الإصدار التالي من .NET Standard ولن يكون الإصدار الصحيح من .NET Framework لـ ASP.NET ؛ سيكون دائما وراء.

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

ستقوم Microsoft بعمل توزيع Windows فقط لـ CoreCLR الذي يدعم النطاق الكامل لمكتبات .NET Framework.

أو مجموعة من مكتبات .NET Standard 2.0 ؛ حتى يتمكنوا من العمل على .NET Core ، والتي تعمل فقط على نظام Windows الذي يغطي فجوة API؟

benaadams نعم هذه هي الفكرة ، على الرغم من أن ذلك لن ينجح مع أي شيء يرمي PlatformNotSupportedException

qrli إذا كانت معيارية ، فيمكنك ترقية الوحدات التي يمكن ترقيتها الآن ، وترك الباقي حتى وقت لاحق.

ما لم تقصد بكلمة "معيارية" "إنه تطبيق System.Web ASP.NET IIS متآلف ضخم يضم عشرات المكتبات المختلفة التي تعمل بشكل متداخل عبر PInvoke و COM" في هذه الحالة ، هذه كرة كبيرة من الطين.

هل توجد قائمة نهائية بالمجالس التي ستتأثر وتلك التي لا تتأثر؟ لقد تم ذكر أن Microsoft.Extensions.* آمن و Microsoft.AspNetCore.Razor.Runtime (مفترض) أيضًا ، بفضل Microsoft.AspNetCore.Html.Abstractions يحتاج إلى البقاء على netstandard أيضًا. هل هناك أي شيء آخر في Microsoft.AspNetCore.* يبقى على netstandard ؟

bencyoung خطتي الانتقالية الموصى بها هي ترحيل مكونات مختلفة بمرور الوقت إلى خدمات مستقلة تستهدف .NET Core 2.x (أو أي شيء يعمل بشكل أفضل من عالم أدوات التطوير لهذا المكون المحدد) ، واستهلاك هذه الخدمات من التعليمات البرمجية القديمة أكثر من حد قياسي لواجهة برمجة التطبيقات باستخدام HTTP أو ناقل رسائل ، حتى تحصل على بنية نظام موزعة مناسبة.

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

markrendle لا تتعلق مشكلتي بالترحيل إلى الخدمات ، بل هي أن بعض الكتل الأساسية للبنية التحتية للخدمة تستخدم واجهات برمجة التطبيقات غير الموجودة على خريطة الطريق مقابل netstandard20 أو حتى netstandardbanana . NET Core بالنسبة لنا لا يتعلق بتطبيقات الحقول الخضراء ، إنه يتعلق بأنظمة الحقول الخضراء بأكملها. System.DirectoryServices مثال واحد ولكن بالنسبة للآخرين ، إنه WCF ، وأكثر من ذلك ، فهو System.Data و SqlClient ، وبالنسبة لنا ، System.Messaging .

أنا جميعًا لاستخدام .NET Core عندما يمكنني ذلك. حتى الآن لم يتضمن ذلك أي مشاريع عملاء ، سواء كانت مشاريع جديدة أم لا ، فجميعهم محجوبون على شيء ما .

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

jbogard أرى مشابهًا ، لكن هذا سيكون مختلفًا تمامًا عندما يخرج .NET Core 2.0.

تنهد.

تضمين التغريدة

netstandardbanana

اقتباس من الموضوع

المشكلة الرئيسية في هذا الأمر ، بالنسبة لي وفريقي ، هي أنه لم يكن هناك ما يشير إلى أن هذا المسار هو المستقبل المنشود. لا أعرف المستقبل ، لكنني أسمع أننا بحاجة إلى كسر أي شيء يعتمد على إطار عمل صافي كامل (dlls البائع المكون ، sdks خدمات الدفع ، HSM sdks) في خدماتهم الخاصة وتقديم تلك الخطوة الجديدة STINGS. إنه ليس شيئًا يحتاجه هذا الموقع والآن يتعين علينا إما تقديم المزيد من تعقيد عمليات التطوير أو إعادة تشغيل جزء تطبيق الويب إلى MVC 5.

ذهبنا مع asp.net core من أجل سرعة kestrel وواجهة برمجة التطبيقات الجديدة الرائعة. كان من الجيد أن تكون قادرًا على موازنة الخيارات بدقة أكبر مقابل الافتقار إلى مسار ترقية سهل بالنظر إلى تبعياتنا.

اضافة الى @ jabrown85
لقد كان ASP.NET Core بمثابة أفعوانية من المشاعر حتى الآن.
بعد هبوط csproj ، ذهبت أخيرًا "إنه جاهز الآن" واعتبرت أنه من غير المنطقي بدء أي شيء جديد فيه والتحقق مما يمكن ترقيته. بعد هذا الإعلان ، يبدو الأمر أكثر مثل: "هل يدعم .NET Core السيناريو بالتأكيد أم يجب أن نتحرك بأمان ونبقى مع MVC5؟"

الخسائر البشرية منخفضة حتى الآن ، تطبيق واحد فقط مكتوب في ASP.NET Core يدير المهام الإدارية لتطبيق MVC 5 الأساسي ، لكنه سيظل عالقًا في 1.x إلى الأبد لأن التطبيق الرئيسي يستخدم NHibernate.

markrendle للكمبيوتر يقول لا

سيكون من الرائع لو كانت هناك بعض خارطة الطريق لـ .NET بالكامل -> netstandard. بعض القطع الأساسية تقول "غير مدعوم" من ApiPort. سأقوم بتشغيل تحليل كامل لمشاريع العميل على ASP.NET Core 1.x لمعرفة ما هو مفقود.

ولكنه سيظل عالقًا في 1.x إلى الأبد لأن التطبيق الرئيسي يستخدم NHibernate.

لا ينبغي أن يكون ، NHibernate ليس ميتًا أليس كذلك؟

تضمين التغريدة هناك بعض الأشياء التي تفعلها بحيث لا تمتلك EF6 أي مكافئ. نحن افتراضيًا إلى EF6 ولكن هناك حالات يتعين علينا فيها السير في طريق NH.

benaadams رسميًا لا ، فقد توقف مؤقتًا حيث يبدو أنه ميت تقريبًا ولكن عادةً ما يكون هناك التزام كل بضعة أيام. أبلغ ApiPort عن تغطية بنسبة 72.26٪ لـ .NET Standard ولكني لست مقتنعًا حقًا بأنه سيتم نقله (في المستقبل القريب على الأقل).

عند قراءة التعليقات ، أشعر بالقلق إزاء الاتجاه العام الذي يتجه إليه هذا المشروع. لفترة طويلة ، كان ASP.NET اختيارًا جيدًا لتقنية مستقرة وصلبة. ومع ذلك ، لا أشعر بنفس الشعور الآن. هناك العديد من تقنيات "التحرك بسرعة وكسر الأشياء" ، ولكن هذه فئة مختلفة تمامًا.
آمل أن تتمكن Microsoft من معالجة هذه المخاوف ومواءمة توقعات الجميع.

لا يتعلق الأمر بالمؤسسات مقابل البرامج غير التابعة للمؤسسات. هناك الكثير من تطبيقات Python 2.x قيد الاستخدام اليوم وليست جميعها "مؤسسة". علاوة على ذلك - لا تستخدم جميع المشروعات الجديدة Python 3 (بعد 9 سنوات تقريبًا من إصدار Python 3.0!).

هل يمكن لأي شخص تلخيص الموضوع بأكمله في منشور مدونة؟

لقد قرأت جميع التعليقات البالغ عددها 300+ أثناء التنقل / الغداء و ... ما زلت يبدو أنني لا "أفهمها" تمامًا.

ما أحصل عليه هو:

• لن يتم دعم .NET Framework الكامل على .NET Core 2
• كل تبعية ستعتمد على netcoreapp2.0 بدلاً من netstandard2.0
• إذا كنت أريد شيئًا مثل DirectoryServices أو الرسم ، فأنا بحاجة إلى إسقاط Full Framework والانتقال إلى الإصدار 2.0

لقد فاتني نوعًا ما الباقي ... جدول مزدحم وكل شيء.

تضمين التغريدة

إذا كنت أريد شيئًا مثل DirectoryServices أو الرسم ، فأنا بحاجة إلى إسقاط Full Framework والانتقال إلى الإصدار 2.0

لا ، إذا كنت تريد مكتبة لا تدعم .net core ، فلن تتمكن من استخدام AspNet Core 2.0+ على الإطلاق.

MaximRouiller ، ما فعلوه للتو هو أن مشاريع Asp.Net الأساسية لن تكون قادرة على الإشارة إلى تجميعات إطار العمل الكامل ، مما يجعلها غير مجدية للعديد إن لم يكن معظمها ، كما يقولون ، مثل النظام. أو لا أعلم ، مع ذلك ، لن تعمل التجميعات القديمة إلا إذا كان هناك شخص ما ينفذها ، لذا فهي غير مجدية إلى حد كبير بالنسبة للكثيرين لأن بعض التجميعات قديمة ولن يتم نقلها أبدًا. في الختام ، فإن أي شخص كان يستخدم .net core مع الإصدار الكامل من .NET framework قد أصيب بالفشل ويحتاج إلى العودة إلى MVC 5.

davidfowl شكرا لهذه القائمة بالمناسبة. هذا هو الشيء المهم للغاية "إذن ما الذي نستخلصه من هذا؟" قطعة مطلوبة للناس لتحقيق التوازن بين التكلفة / الفائدة في أذهانهم.

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

davidfowl قلت:

يمكن كتابة المكتبات فوق المعيار. عندما تحتاج الأشياء في المعيار نفسه إلى التغيير ، فسوف يستغرق الأمر وقتًا أطول ليتم اعتماده في جميع تطبيقات .NET والتي تتضمن .NET Framework. يمكن أن تعني أمرين:
سوف يتم تطوير .NET Standard بمعدل أبطأ تطبيق
سوف يتطور .NET Standard بوتيرة أخرى وسيكون .NET Framework هو آخر من يلحق بالركب.

لكن لماذا هذا هو الحال؟ ألا يمكنك إصدار .NET Standard vNext وجعل .NET يلحق به بعد بعض الوقت (بعد بضعة أشهر إلى عام)؟ هذا يعني أن الأشخاص الذين هم على حافة النزيف ويريدون أحدث إصدار من ASP.NET Core يمكنهم الاستضافة في .NET Core ، ويمكن للأشخاص الذين يحتاجون إلى .NET للحصول على التعليمات البرمجية القديمة استخدام هذا الإصدار من ASP.NET Core في النهاية بمجرد أن تدرك NET. إلى إصدار .NET القياسي الذي يستخدمه. لا أفهم لماذا يجب أن يتم تسريع .NET Standard بأسرع ما يمكن في التطبيق الأقل.
نتحدث هنا أيضًا عن عمليات التنفيذ الرسمية للمعيار ، ولكن ستكون هناك تطبيقات أخرى لن يتم تحديثها جنبًا إلى جنب مع المعيار.
بهذه الطريقة لا تترك الناس وراءك. بالتأكيد ، سيستغرقون وقتًا أطول قليلاً للاستفادة من أحدث الميزات إذا كانت موجودة في .NET ، لكنها ليست عالقة إلى الأبد.

jdom لأنني أعرف المعدل الذي يتغير به .NET Framework ولماذا يجب أن يكون بطيئًا. إنه توزيع مختلف وربما لا يوجد تقدير كاف لذلك. يتم دفع أي تغيير في مكانه إلى مليارات الآلات. تختلف الطبقات أيضًا تمامًا ، لذا فهي ليست بالأمر التافه حتى التفكير.

لا أفهم لماذا يجب أن يتم تسريع .NET Standard بأسرع ما يمكن في التطبيق الأقل.

إذا واصلنا رفع العلامة المائية المنخفضة لمعيار .net في ASP.NET Core ، فإنه يتعارض مع الغرض ويتركك في نفس الموقف. من المؤكد أنك لا تشعر بالتخلف عن الركب لأن هناك وعدًا بأن واجهات برمجة التطبيقات هذه ستأتي يومًا ما إلى .NET Framework ولكن في أي مخطط زمني؟ لا يزال .NET 4.7 لا يكمل تماثل الميزات مع .NET Standard 2.0.

davidfowl ولكن هذا سيعيد نفس المشكلة كما هو الحال مع PCLs ، وسيصبح القاسم المشترك الأدنى والألم الذي يجب استخدامه ، وحقيقة أن ASP.NET تخلى عن استخدامه تظهر ذلك بالفعل.

davidfowl ولكن هذا سيعيد نفس المشكلة كما هو الحال مع PCLs ، وسيصبح القاسم المشترك الأدنى وألمًا للاستخدام ،

Suchiman كيف هذه مشكلة؟ كانت المشكلة الوحيدة في PCLs هي كيفية حسابها وتمثيلها ديناميكيًا في NuGet مما جعل من الصعب التنبؤ بما ستحصل عليه. وإلا كيف سيعمل netstandard إذا لم تكن مجموعة API يمكن تنفيذها من خلال تطبيقات مختلفة؟

ما جعل PCLs مزعجة للاستخدام هو مساحة سطح API الصغيرة فائقة المخادعة. يعد .NET Standard 1.3-1.4 كافيًا لتنفيذ معظم المكتبات الأساسية في واجهة برمجة التطبيقات.

كان NET Standard دائمًا حول الاتساع.

كان كل من ASP.NET Core و .NET Core عبارة عن مجموعة خوادم تنافسية عبر الأنظمة الأساسية لبناء خدمات صغيرة خفيفة الوزن. كان التنفس بهذا المعنى هو دعم النظام الأساسي الأوسع (الذي يعمل على Linux و OSX و tizen و pi وما إلى ذلك).

تضمين التغريدة

لقد حددنا السلاسل كأحد الأشياء الرئيسية التي نود أن نحاول معالجتها في .NET Core ، هناك الكثير من الأفكار ولكن إحداها أن يكون لديك سلسلة تكون utf8 افتراضيًا (العديد من مشاكل التوافق ولكن اتبعني هنا).

الشيء الآخر الذي نرغب في إصلاحه هو القدرة على أخذ شرائح رخيصة من المصفوفات / السلاسل ، أي قطعة من الذاكرة المتجاورة. لقد أضفنا سبانويبحثون في Bufferلتمثيل هذا. قد يعني ذلك أن String and Array يطبقان واجهات جديدة تجعل من الممكن أخذ شريحة تتطلب تخصيصًا صفرًا.

يبدو أن هذا يعني أنه إذا كنت أرغب في استخدام هذه البتات الجديدة في مكتبة ، فستحتاج المكتبة أيضًا إلى استهداف netcoreapp2.0 بدلاً من netstandard2.0 . هل هذا صحيح؟

إنها فكرة سيئة حقًا ألا تدعم إطار عمل 4.x القديم بعد الآن. لا يقوم الأشخاص بالترقية إذا تسبب ذلك في الكثير من العمل. شاهد ASP الكلاسيكي الفائق القديم ، والذي تم إهماله منذ عام 2002 - حوالي 15 عامًا. ولدينا تطبيقات قديمة لا تزال موجودة في ASP الكلاسيكي! هل تحب Microsoft رؤية شيء مشابه مرة أخرى؟ يعد إسقاط دعم 4.x القديم أمرًا إلزاميًا - ولكن على المدى الطويل! ليس الان. يمكن أن يكون هذا خيارًا في غضون بضع سنوات ، عندما يكون .NET core هو المعيار الفعلي وتستخدم التطبيقات القديمة فقط net 4.x.

إن الفكرة من وراء (ASP) .NET Core رائعة حقًا ، وهي أفضل شيء فعلته Microsoft منذ إطلاق .NET. لكن مثل هذه الفوضى تبدد هذا المفهوم الجميل. ومن المحزن أيضًا أن تقرر Microsoft مثل هذه التغييرات الهائلة من تلقاء نفسها ، دون حتى مناقشتها في المجتمع! يبدو أن هذه الشركة لم تتعلم تمامًا بعد كيفية التعامل مع المشاريع مفتوحة المصدر.

تضمين التغريدة

كان NET Standard دائمًا حول الاتساع.

اتساع في واجهات برمجة التطبيقات أو المنصات؟

ما هي مشكلة تطوير .netstandard بنفس الوتيرة مثل .netcoreapp ؟
هل أي من أهداف ضبط BCL مخصصة لـ .netcoreapp لأنها لن يتم تنفيذها أبدًا في أطر العمل الأخرى؟

تحرير .netstandard2.1 في نفس الوقت مثل .netcoreapp2.1 لا يُحدث فرقًا في تحرير .netcoreapp2.1 أولاً وبعد عام واحد .netstandard2.1 في نفس الوقت مثل .net50 ، باستثناء الحزم التي تستهدف .netstandard2.1 ستبدأ العمل فورًا على .net50 ولكن سيتم حظرها إذا كانت تستهدف .netcoreapp2.1

ASP.NET Core عبارة عن إطار عمل webapp عالي المستوى مبني على .NET Core وسيكون في المستقبل NET Core الهدف ، _ ومع ذلك_ يمكن أن يكون أيضًا إطار عمل webapp عالي المستوى مبنيًا على .NET Standard بدلاً من ذلك ، بحيث يستهدف واجهة API مرجعية بدلاً من تنفيذ محدد لها.

يُعد تحديد المواقع العامة لـ .NET Standard هدفًا سهلاً للبناء عليه مع ترك تفاصيل التنفيذ جانبًا - مع إطارين رسميين مباشرة من Microsoft لتغطية معظم حالات الاستخدام.

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

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

أعتقد أنه يجب اعتبار أن ASP.NET إلى ASP.NET Core ليس مسار الترحيل للجميع.

سيبقى ASP.NET في إطار العمل الكامل ويحصل على ميزات ولكن ليس مثل Core.

ستصبح عملية الترحيل أسهل بمرور الوقت ولكنها لن تكون مطابقة بنسبة 100٪ أبدًا.

لا يزال الأشخاص يشغلون ASP الكلاسيكي. هذا جيد بالنسبة لهم أيضًا.

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

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

• لقد حددنا السلاسل كأحد الأشياء الرئيسية التي نود أن نحاول معالجتها في .NET Core ، هناك الكثير من الأفكار ولكن إحداها أن يكون لديك سلسلة تكون utf8 افتراضيًا (العديد من مشاكل التوافق ولكن اتبعني هنا).

من المؤكد أن هذه النقطة هنا ستغير قواعد اللعبة ، لكن IMO هي النقطة الوحيدة التي تتطلب تمامًا عدم استهداف إطار عمل ، وهي ليست لـ netcoreapp20 على أي حال.

• الشيء الآخر الذي نرغب في إصلاحه هو القدرة على أخذ شرائح رخيصة من المصفوفات / السلاسل ، أي قطعة من الذاكرة المتجاورة. لقد أضفنا سبانويبحثون في Bufferلتمثيل هذا. قد يعني ذلك أن String and Array يطبقان واجهات جديدة تجعل من الممكن أخذ شريحة تتطلب تخصيصًا صفرًا.
• يؤدي هذا إلى عمليات جديدة على String تسمح بالتقسيم الذي لا يخصص مصفوفة في كل مرة.
• يؤدي هذا إلى زيادة الحمولة إلى Int و UInt وما إلى ذلك (TryParse) التي تستغرق Spanوسبان.
• هذا يؤدي إلى إجراءات ترميز جديدة تأخذ Span.
• متعادلوسبانتتيح لك تمثيل الذاكرة بطريقة موحدة ونريد ترقية مكدس الشبكات للسماح بتمرير المخازن المؤقتة المثبتة مسبقًا التي تأخذ Spanأو العازلة.

كل هذا لا يزال قابلاً للتنفيذ كحزم فوق الشبكة القياسية الحالية. لا تحتاج حتى إلى netstandard20 لهذا الغرض. أتفهم عدم الرغبة في حمل هذه الأمتعة ، ولكن يتعين على بقيتنا في العالم غير المتصل بالتصلب المتعدد إنشاء أدوات BCL-esque المخصصة طوال الوقت عندما لا تكون حالة الاستخدام أو الأداء مناسبًا. ناهيك عن أن Span API لا تستهدف الإصدار 2.0 أيضًا (ما لم يتم تغيير ذلك مرة أخرى).

سيطبق Kestrel HTTP2 في الإطار الزمني 2.x (يهدف حاليًا إلى 2.1) ويتطلب ذلك واجهات برمجة تطبيقات جديدة على دفق SSL للقيام بـ ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
يدعم Http Client على .NET Core الدفق المزدوج ، مما يجعل من الممكن تنفيذ نقاط نهاية الدفق عبر http في signalr عبر طلب http واحد غير مزود بمقبس ويب.

أشعر أن هذا الشخص أصعب قليلاً ، لكن ليس كل ذلك مختلفًا عن Kestrel الذي يحمل libuv. يمكن سحب تطبيق CURL من .Net Core بسهولة إلى حزمة تمديد قياسية حتى يتمكن الجميع من اللحاق بالركب.

• قمنا بتقسيم تطبيقات محلل الرأس من HttpClient و System.Net.Http وأعدنا تسميتها (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Http.Http.Http. واجعلهم يدعمون كلاً من .NET Framework و .NET Core. NET Core لديه نسخة من هذه التحسينات لم تتمكن من إعادتها لأنه ليست هناك حاجة لتحسينها (لم نتمكن من استهلاكها).

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

• بدون القدرة على تسريع الأساسيات الأساسية ، نشجعنا على تفرعها وصنع أشياء تبدو مثلها ولكنها ليست كذلك. هذا هو السبب في أن لدينا BCL الصغير الخاص بنا داخل ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

مرة أخرى ، تمامًا مثل بقيتنا.

كان كل من ASP.NET Core و .NET Core عبارة عن مجموعة خوادم تنافسية عبر الأنظمة الأساسية لبناء خدمات صغيرة خفيفة الوزن.

لدى ASP.Net Core بعض الرسائل من هذا القبيل. تم إرسال .Net Core منذ اليوم الأول باعتباره مجموعة فرعية لإطار عمل xplat من جانب الخادم. لم أسمع أبدًا أي شخص يقول ذلك. Net Core مخصص للخدمات المصغرة فقط. لقد سمعت أنه يمكنك استخدامه مع ASP.Net Core إذا كنت تريد ، ولكن أيضًا تطبيقات وحدة التحكم وتحليل البيانات وخدمات DB وما إلى ذلك.

سيبقى ASP.NET في إطار العمل الكامل ويحصل على ميزات ولكن ليس مثل Core.

فإنه سوف؟ ما زلت لم أر أي شخص من MS يؤكد أنه لا يزال قيد العمل. حدسي يقول إنه ليس كذلك. فهمت. يحتاج الفريق إلى لحظة من نوع "حركه أو يخسره" للتحرر. لا أعتقد أن هذه هي اللحظة بعد.

بافتراض أن لدينا مجموعة 4.6 منطق عمل ، والتي تستخدم برنامج تشغيل Oracle.Net و NHibernate و RabbitMQ (جميعها في 4.6). تكون الواجهة مع ASP.Net فقط من خلال كائنات أعمالنا وطلباتنا واستجاباتنا. هل يمكننا الإشارة إلى هذا التجميع في ASP.Net Core 2 الخاص بنا ، بدون إعادة تجميع؟

ملخصي السريع

@ stefan2410 إجابة مختصرة ، لا ، لا يمكنك الرجوع إلى إطار Framewrok بالكامل ، ولا يمكنك الرجوع إلى هذه التجميعات إلا إذا تم إنشاؤها من أجل netstandar 2.0.

تضمين التغريدة

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

أنا آسف ولكن الأمر ليس كذلك حقًا. لا يمكنك القرد أنواع التصحيح. ما لم تكن تقترح ، فإننا نضيف أنواعًا جديدة ولا نغير الأنواع الحالية.

ناهيك عن أن Span API لا تستهدف الإصدار 2.0 أيضًا (ما لم يتم تغيير ذلك مرة أخرى).

يوجد Span في الإصدار 2.0 كتطبيق ولكن ليس واجهة برمجة تطبيقات عامة. نجري تغييرات جذرية في التخصصات الجديدة حتى نتمكن من القيام بمزيد من الميزات في الإصدارات الثانوية. إذا كان ASP.NET Core 2.1 يستهدف .NET Standard 2.1 ، فسيتم إسقاط دعم .NET Framework مرة أخرى.

أشعر أن هذا الشخص أصعب قليلاً ، لكن ليس كل ذلك مختلفًا عن Kestrel الذي يحمل libuv. يمكن سحب تطبيق CURL من .Net Core بسهولة إلى حزمة تمديد قياسية حتى يتمكن الجميع من اللحاق بالركب.

لذا ما تقوله هو أننا يجب أن نعيد تسمية جميع الفئات في BCL حتى نتمكن من استخدامها على كل من .NET Standard.

لم أسمع أبدًا أي شخص يقول ذلك. Net Core مخصص للخدمات المصغرة فقط. لقد سمعت أنه يمكنك استخدامه مع ASP.Net Core إذا كنت تريد ، ولكن أيضًا تطبيقات وحدة التحكم وتحليل البيانات وخدمات DB وما إلى ذلك.

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

فإنه سوف؟ ما زلت لم أر أي شخص من MS يؤكد أنه لا يزال قيد العمل. حدسي يقول إنه ليس كذلك. فهمت. يحتاج الفريق إلى لحظة من نوع "حركه أو يخسره" للتحرر. لا أعتقد أن هذه هي اللحظة بعد.

نعم ، تمت إضافة دعم HTTP / 2 في الإصدار الأخير. هناك فريق آخر يعمل على ASP.NET و IIS ويقومون بإجراء تحسينات. ومع ذلك ، فهي ليست على نفس المقياس الذي يقوم به ASP.NET Core.

ليس لدي مشاعر قوية حول هذا الأمر حيث أنني تجنبت تشغيل خدمات ASP.NET Core الخاصة بي في إطار عمل كامل مثل الطاعون. مع ما يقال ، اضطررت إلى تجنب استخدام بعض المكتبات اللطيفة والناضجة لأنها لا تدعم .NET Standard لأنهم كانوا إما ينتظرون netstandard2.0 أو لمجرد أنهم لم يرغبوا في ذلك.

ما أخشاه هو أن إزالة القدرة على تشغيل ASP.NET Core في إطار العمل الكامل ستثني المستخدمين عن نقل تطبيقات MVC 5 / Web API 2 الحالية إلى ASP.NET Core والتي ستوفر فقط سببًا آخر لمؤلفي المكتبة لتجنب الانتقال إلى .NET معيار. لماذا تكلف نفسك عناء القيام بترقية العمل إذا لم يستفيد أي من المستخدمين لديك؟ لقد أصبحت مشكلة الدجاج والبيض وأخشى أن يؤدي ذلك إلى الإضرار بالنظام البيئي ككل تمامًا كما بدأ في الحصول على بعض الجر. تحتاج أولاً إلى مستخدمي ASP.NET Core ولست مقتنعًا بوجود العديد من هؤلاء كما نرغب جميعًا. آمل أن أكون مخطئا.

إذا كان ASP.NET Core 2.1 يستهدف .NET Standard 2.1 ، فسيتم إسقاط دعم .NET Framework مرة أخرى.

لا ، هذا يعني فقط أن Net Framework سيدعم تلقائيًا ASP.NET Core 2.1 بمجرد أن يدعم .NET Standard 2.1 ، متى كان ذلك ، حتى لو استغرق عام أو عامين.

الشيء نفسه بالنسبة لجميع الأنظمة الأساسية الأخرى المتوافقة مع .NET Standard (Xamarin / Unity / ...).

الاعتماد على .NET Standard يعني أن الأنظمة الأساسية الأخرى ستضيء _ في بعض الأحيان_ ، والبناء على .NET Core يعني أنها ستضيء ____ أبدًا_.

أفترض أن الخطة لا تزال أن full-fx سوف يلحق بالمعايير القياسية ، حتى لو كان ذلك مع تأخير طويل؟
(وإذا لم يكن هناك نظام أساسي آخر باستثناء NET Core من المتوقع أن يطبق .NET Standard 2.1 ، فلماذا يكون لديك NET Standard؟)

أنا آسف ولكن الأمر ليس كذلك حقًا. لا يمكنك القرد أنواع التصحيح. ما لم تكن تقترح ، فإننا نضيف أنواعًا جديدة ولا نغير الأنواع الحالية.

هذا الأخير هو ما تم فعله بالفعل في معظم الحالات في 1.x ، أليس كذلك؟ هل هذا فجأة لم يعد ممكنًا؟

يوجد Span في الإصدار 2.0 كتطبيق ولكن ليس واجهة برمجة تطبيقات عامة. نجري تغييرات جذرية في التخصصات الجديدة حتى نتمكن من القيام بمزيد من الميزات في الإصدارات الثانوية. إذا كان ASP.NET Core 2.1 يستهدف .NET Standard 2.1 ، فسيتم إسقاط دعم .NET Framework مرة أخرى.

لماذا يتم إسقاطه؟ هل تقول أن Span لن يكون موجودًا أبدًا في Framework؟

لذا ما تقوله هو أننا يجب أن نعيد تسمية جميع الفئات في BCL حتى نتمكن من استخدامها على كل من .NET Standard.

واو لا. أقول إنني إذا كنت بحاجة إلى قاموس بواجهة برمجة تطبيقات مختلفة ، فلا بد لي من إنشاء شيء آخر وأيضًا عدم تسميته System.Collections.Generic.Dictionary ، كما فعلتم يا رفاق بالفعل مع Microsoft.Net. *

نعم ، تمت إضافة دعم HTTP / 2 في الإصدار الأخير. هناك فريق آخر يعمل على ASP.NET و IIS ويقومون بإجراء تحسينات. ومع ذلك ، فهي ليست على نفس المقياس الذي يقوم به ASP.NET Core.

هذا عادل. لم أكن على علم بذلك.

هذا الأخير هو ما تم فعله بالفعل في معظم الحالات في 1.x ، أليس كذلك؟ هل هذا فجأة لم يعد ممكنًا؟

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

لماذا يتم إسقاطه؟ هل تقول أن Span لن توجد أبدًا في Framework؟

يجب أن يتم إسقاطها من ASP.NET Core 2.0 ، حيث لن يتم محاذاة المخططات الزمنية بعد الآن ، نظرًا لأن الإطار الكامل لن يكون موجودًا بعد .

يجب أن يتم إسقاطها من ASP.NET Core 2.0 ، حيث لن يتم محاذاة المخططات الزمنية بعد الآن ، نظرًا لأن الإطار الكامل لن يكون موجودًا بعد.

AFAIK ، Spans هي جزء من حزمة netstandard1.x يمكن استخدامها على .NET Desktop (إنه تطبيق محمول لذلك لا يتمتع بنفس تعزيز الأداء كما لو كان مدعومًا في CLR ، ولكن من المحتمل جيد بما فيه الكفاية).

تحرير: تحتوي الحزمة System.Memory netstandard1.0 TFM $ # $ 2 $ # $ ، لذا يمكن استخدامها حتى على .NET 4.5.

هذا الأخير هو ما تم فعله بالفعل في معظم الحالات في 1.x ، أليس كذلك؟ هل هذا فجأة لم يعد ممكنًا؟

نوقف ميزة العمل في اتجاهات معينة اليوم بسبب ذلك. إنه متعمد ونحبط أنفسنا ونرفض استخدام واجهات برمجة تطبيقات جديدة عن طريق نسخ وإعادة تنفيذ الأشياء خارج .NET Standard بحيث يمكن لـ .NET Framework العمل. هذا ليس كل شيء ولكن هناك بعض القطع الأساسية التي نود أن نتطرق إليها للمضي قدمًا ، بعد كل شيء ، نحن (Microsoft) نتحكم في كلا الجانبين.

لماذا يتم إسقاطه؟ هل تقول أن Span لن توجد أبدًا في Framework؟

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

واو لا. أقول إنني إذا كنت بحاجة إلى قاموس بواجهة برمجة تطبيقات مختلفة ، فلا بد لي من إنشاء شيء آخر وأيضًا عدم تسميته System.Collections.Generic.Dictionary ، كما فعلتم يا رفاق بالفعل مع Microsoft.Net. *

هذا بالضبط ما تقترحه. لا نريد أن يكون لدينا Microsoft.Extensions.Collections.Generic. نبذل قصارى جهدنا لتجنب ذلك ونعيش مع واجهات برمجة التطبيقات القديمة و polyfill حيثما أمكن ذلك هذا ليس مستدامًا ويعني أن .NET Core لا يحصل على الفوائد لأننا نتجنب استخدامه بنشاط.

PinpointTownes وجود مسافات ليست جيدة بما يكفي ، فهم بحاجة إلى استخدامها في استدعاء الأساليب للأنواع الموجودة. وذلك عندما يتم تشغيل إعادة توجيه النوع على مستوى الفصل ويسبب العديد من المشكلات.

@ 0x53A

هذا عادل. هل يمكن أن تخبرني لماذا لا تتخلى المكتبات الشائعة على NuGet عن دعم إصدارات .NET Framework الأقدم التي من الواضح أنها خارج الدعم؟ تستهدف المكتبات الأكثر شيوعًا net20 و net35 و net40 وما إلى ذلك. فلماذا يصبح من المناسب فجأة طلب أحدث إصدار من .NET Framework للاستمرار في استخدام ASP.NET Core؟ هل تعتقد أن ذلك سيكون معقولاً؟

هذا هو توقف العرض. يجب أن أفكر في إلغاء عمليات الترحيل من ASP.NET MVC 5 / Web Api 2 To Core. العديد من الأطر المستقرة ليست متاحة بعد للنواة. ما زلنا نستخدم EF6.x لأن EF Core ليست ناضجة بدرجة كافية مقارنة الميزات .

PinpointTownes وجود مسافات ليست جيدة بما يكفي ، فهم بحاجة إلى استخدامها في استدعاء الأساليب للأنواع الموجودة.

ربما تكون "الحاجة" مفرطة بعض الشيء. تُستخدم الامتدادات بشكل أساسي للأداء ، لذلك لا شيء يمنعهم من استخدام الأحمال الزائدة الحالية غير الممتازة على .NET Desktop باستخدام ifdefs حتى يحصل .NET Desktop على دعم أصلي لـ Spans.

davidfowl أعتقد أن القضية الكبرى عاطفية. إذا كنت تستهدف netstandard ، فأنا أعلم أنني سأتمكن من الترقية من 1.x إلى 2.x في النهاية (حتى لو كان ذلك مع تأخير). في معظم الأحيان ، لا يعد تحديث netfx أمرًا بالغ الأهمية لتطبيق ما (يختلف عن lib).

لكن بعض التطبيقات لن تكون قادرة أبدًا على إجراء قفزة netfx -> netcore ، لذلك إذا كنت تستهدف netcore ، فإنهم يعرفون أنهم في طريق مسدود مع 1.x.

في هذا الصدد ، كان من الأفضل لو لم يتم تشغيل Asp.net الأساسي على netfx ، كما هو الحال ، فقد توقعوا استمرار ذلك ، ويشعرون الآن (بحق ، IMO) بالخيانة. بعد كل شيء ، ربما يكونون قد استثمروا بالفعل الكثير من الوقت في هذا الأمر.

أنا لست مستثمرًا شخصيًا في هذا ، لأنني لست مستخدمًا لـ asp.net ، سؤالي الكبير هو في الواقع فقط

أفترض أن الخطة لا تزال أن full-fx سوف يلحق بالمعايير القياسية ، حتى لو كان ذلك مع تأخير طويل؟
(وإذا لم يكن هناك نظام أساسي آخر باستثناء NET Core من المتوقع أن يطبق .NET Standard 2.1 ، فلماذا يكون لديك NET Standard؟)

فيما يتعلق بـ libs الأخرى التي تستهدف net20 و net35 وما إلى ذلك ، في تجربتي ، يحاول معظم المؤلفين استهداف الإصدار الأقل الذي يمكنهم فعله وقطع الأنظمة الأساسية فقط حيث ليس لديهم خيار آخر.

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

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

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

davidfowl أعتقد أن هذا ربما جزء من المشكلة. لقد كنت بصراحة ألعب دور محامي الشيطان قليلاً هنا ، لأننا عالقون في المنتصف كتطبيق جديد بدأ قبل ذلك بقليل. Net Core كان شيئًا ، لذلك نحن نتجاوز الخط.

لطالما كان تفكيرنا ، استخدام libs الجديدة الفاخرة (مثل Kestrel) إذا كان ذلك ممكنًا ، ولكن انتظر .Net Core حتى يستقر (ويسعدني أننا فعلنا ذلك ، إذا تغيرت الأدوات فقط) ، _ أو انتظر بتات Core رائعة لإعادتها إلى Framework. أعتقد أن افتراض معظم الناس كان أن معظم التطورات التي حققتها شركة Corefx ، إن لم يكن كلها ، ستجعلها في Framework vNext أو vNext + 1. ولكن ، يبدو (من وجهة نظرنا التي تبلغ 30 قدمًا) من هذا التغيير وغيره من التغييرات أن Framework ليس منصة للمستقبل.

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

إنه سؤال جيد في الواقع: ما الذي تبقى من backporting لميزات net core إلى .NET ممتلئة؟ كما قرأت هنا ، يعد .NET full هشًا للغاية ، حيث يستغرق نقل الكود إليه وقتًا طويلاً (يتحرك ببطء شديد) ويمكن أن ينكسر في أي لحظة (يمكن أن يكون ، ليس لدي فكرة عن مدى تشابكه) لذا استنتج بعد ذلك أن ذلك لن يحدث غالبا.

لا يمكن أن يكون كلاهما: إما backporting إلى .NET ممتلئ على ما يرام ، فهي تصدر مرات أقل (على سبيل المثال كل 6 أشهر إلى سنة) أو أنها معقدة للغاية وعرضة للخطأ. إذا كان الأمر هو السابق ، فما عليك سوى زيادة السرعة وعدم السماح للمستخدمين بدفع الفاتورة والتوقف عن استخدام الأخير كذريعة. إذا كان هذا هو الأخير ، أليس الاستنتاج الصحيح إذن أن معيار الشبكة هو مغالطة ، حيث أن كل ما يهم في المستقبل هو واجهة برمجة تطبيقات netcore على أي حال؟

أنا قلق للغاية بشأن مستقبل اتجاه .NET. تصنع شركتي أدوات لـ .NET full و .NET standard1.6. آخر شيء نريده هو أن القوة الدافعة لاتجاه .NET (الميزات الجديدة التي على وشك أن يتم نقلها إلى .NET full ، كما قيل في إعلان .NET core عن كل تلك الأقمار قبل) تقسم الأشياء والنظام البيئي بشكل فعال تنقسم إلى نصفين ، حيث أن التجزئة تقتل.

لم يطمئنني أي شيء في هذا الموضوع إلى أن الأمور على ما يرام بالنسبة لمستقبل _all_ .NET والنظام البيئي المطلوب لإبقائه على قيد الحياة: أرى مجموعتين فقط:

• الأشخاص الذين يشعرون بالقلق من أن الخيارات تزداد تعقيدًا ولديهم مشكلة صعبة في المستقبل
• مايكروسوفت التي ترى طريقًا واحدًا إلى الأمام: الطريق الأساسي. net.

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

بينما أوافق على أن كل هذا شيء جيد على المدى الطويل ، أعتقد أيضًا أن إسقاط الدعم لإطار العمل الكامل مع 2.0 هو أمر مبكر جدًا.

نود الانتقال إلى .NET Core في أقرب وقت ممكن ، ولكن لسوء الحظ ، فإن أكبر أدوات الحظر لدينا الآن هي مكتبات Microsoft حصرية تقريبًا (على سبيل المثال ، Entity Framework Core ليس جيدًا بما يكفي حتى الآن ، فإن Azure Service Bus لديه معاينة مبكرة جدًا فقط).

بينما آمل أن تكون مكتبات Azure جاهزة في الأسابيع / الأشهر القادمة ، لا يبدو أن EF Core لديها ميزات كافية في أي وقت قريبًا.

لا أعرف أي شيء عن المكونات الداخلية لـ EF6 ولكن ألن يكون من الممكن بجهد معقول أن يكون هدفًا معياريًا؟ سيؤدي هذا إلى إزالة مانع ضخم ...

لا يبدو "مجرد البقاء على 1.x" بديلاً جيدًا لأنه سيكون هناك بالتأكيد الكثير من المكتبات التي لا تهتم (أو ليس لديها الموارد / المعرفة لدعم كليهما) وتقوم فقط بترقية التبعية إلى 2.0

ملاحظة: أشعر بالإحباط الشديد من مدى تعقيد النظام البيئي .NET خلال السنوات القليلة الماضية. اضطررت إلى قضاء الكثير من الوقت لفهم كل الأشياء الجديدة ولا أرى كيف يجب أن يفهم المطور الجديد أيًا من هذا. هناك الكثير من المعلومات التي عفا عليها الزمن على الإنترنت الآن بسبب كل هذه التغييرات الهائلة للغاية.
أيضًا ، جميع إصدارات المنتجات المختلفة (.net core ، sdk ،. net standard ، ...) مربكة للغاية. ما زلت أرى شخصًا يفهم جدول .NET القياسي دون الحاجة إلى تفسير مدته 20 دقيقة. 😞

أي شخص كان يستخدم .net core مع الإصدار الكامل من إطار عمل .NET ، قد أصيب بالفشل ويحتاج إلى العودة إلى MVC 5

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

لدينا تطبيق ecosytem ، مثل العديد من التطبيقات الأخرى ، مع مكتبات مشتركة يعود تاريخها إلى عقد أو أكثر ، وتطبيقات متعددة MVC 3 و 4 و 5 وتطبيقات وحدة التحكم وخدمات Windows ومئات الآلاف من سطور التعليمات البرمجية. نحن لسنا في وضع سيء للترقية مقارنة بالبعض.

لقد أنشأنا مؤخرًا تطبيقين جديدين للويب باستخدام ASP.Net Core 1.1 ، يستهدفان بالضرورة إطار العمل 4.6.2 الكامل. تستخدم هذه التطبيقات مساحات كبيرة من مكتباتنا المشتركة الحالية. لقد استنفدنا قدرًا محرجًا من وقت التطوير في التعامل مع project.json ، ثم ملف .csproj الجديد ، في محاولة لدمج ملفات .csproj القديمة والجديدة في نفس الحل ، والعودة إلى VS15 لإنجاز المهام باستخدام أنواع .csproj القديمة ، المعطلة نظام. التبعيات ، وسلسلة من مشكلات ربط التجميع ، ومشكلات الإنشاء والنشر .. والقائمة تطول وتطول.

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

لا أستطيع أن أقول إنني لا أتفق مع الاتجاه وضرورة ذلك ، لكن التواصل المبكر كان سيكون موضع تقدير.

أوه ، وبالطبع ، مكتبات Azure Service Fabric لا تعمل على .NET core أيضًا - وهو مانع آخر بالنسبة لنا.

أود أن أقول أنه يجب عليك دعم إطار عمل .NET الكامل حتى تتمكن من تقديم قصة NET core مناسبة داخل Microsoft (وخاصة Azure).

@ cwe1ss سيقلل هذا التغيير بعض تعقيد النظام البيئي .NET بالرغم من ذلك. نظرًا لأنه لن يكون لديك تنسيقان مختلفان (ASP.NET Core + .NET Full و ASP.NET + .NET Core). أوافق تمامًا على المعلومات القديمة ، لكنني أعتقد أنه لا يمكن تجنب ذلك عندما تتطور في العلن كما تفعل Microsoft الآن.

تضمين التغريدة

قصة مشاركة الكود عبر أوقات تشغيل .NET المختلفة هي .NET Standard. يجب أن تحاول مكتباتك توجيه ذلك إلى رمز مشترك عبر .NET Core و .NET Framework. <

لكن الإطار الكامل كما أفهمه لا يدعم حتى معيار net لذا فهو في الحقيقة ليس معيارًا مفيدًا.

يبدو أن Microsoft قد نسيت أهمية التوافق مع الإصدارات السابقة. <<

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

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

تم تسويق ASP .net Core دائمًا على أنه يعمل على كل من .net الأساسية وإطار العمل. كما قال آخرون ، لا يزعجني إذا اضطررنا إلى الانتظار ستة أشهر أو سنة حتى يلحق الإطار. عادة ما أتخلف ستة أشهر أو أكثر على أي حال. ولكن ما يبدو أنه يحدث هو أن استثمارنا الحالي تم التخلي عنه تمامًا ، مثل العديد من تقنيات Microsoft الأخرى التي استثمر الكثير منا الوقت فيها.

ستيفان

Rutix لـ "التطوير في العراء" تم إجراء هذا التغيير الفاصل الرئيسي بشكل صامت بشكل مدهش دون أي إعلان أو مسح (بعد كل شيء ، تم إنشاء هذه المشكلة من قبل أحد أعضاء المجتمع الذي يشاهد طلبات السحب).

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

كان الحادث الأخير https://github.com/dotnet/roslyn/issues/17054 لكنهم قاموا بتصحيحه بسرعة ، وأنا أتساءل كيف سينتهي الأمر.

لكن الإطار الكامل كما أفهمه لا يدعم حتى معيار net لذا فهو في الحقيقة ليس معيارًا مفيدًا.

stefanolson هذا ليس صحيحا. يمكن للمكتبات التي تستهدف .Net Standard 1.x تشغيل العديد من إصدارات إطارات العمل الكاملة اليوم. تستهدف المكتبات .Net Standard 2.0 لتكون قادرة على العمل على 4.6.1 آخر مرة نظرت فيها.

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

لكن الإطار الكامل كما أفهمه لا يدعم حتى معيار net لذا فهو في الحقيقة ليس معيارًا مفيدًا.

تضمين التغريدة تقوم الإصدارات المختلفة (الموجودة) من .NET Framework بتطبيق إصدارات مختلفة من معيار .NET. راجع https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

أعلم أنني تأخرت قليلاً في هذا الموضوع ولكن فيما يلي حالتان من حالات الاستخدام الخاصة بنا لاستخدام ASP.NET Core على NetFX على Windows:

استخدام ASP.NET لاستضافة REST API لتطبيقك

تطبيقنا هو نوع من التطبيقات ". NET API - تحول إلى REST API". تم شحنها لأول مرة كـ .NET API ، ولها تبعيات في جميع أنواع عناصر Windows.

عندما أضفنا واجهة برمجة تطبيقات REST ، اخترنا ASP.NET Web API لاستضافتها. عندما أصبح من الواضح أن Web API كانت موحدة في ASP.NET vNext / 5 / Core ، __و__ اكتشفنا أن __ASP.NET Core سيعمل على NetFX__ من المنطقي استخدام ASP.NET vNext / 5 / Core.

بينما نستفيد من NET Core في نقل (جزء من) تطبيقنا إلى Linux و macOS ، لا تزال هناك تبعيات لنظام Windows لا تعمل على .NET Core (للحصول على قائمة بالتبعية التي قمنا بتنفيذها ، تحقق من حزم CoreCompat.* NuGet).

قصة طويلة جدًا ، نجد أنفسنا الآن مقفلين على ASP.NET Core 1.x والذي سيظل دعمًا لفترة زمنية محدودة تقريبًا. ثم ماذا؟ العودة إلى ASP.NET 4؟

أتفهم كل الأعمال المثالية التي تقوم بها وتدفع الحدود في مجالات أخرى من .NET Core ، ولكن في حالة الاستخدام الخاصة بي ، لا أستضيف موقعًا إلكترونيًا مكشوفًا على الإنترنت بكميات كبيرة ، فأنا أستضيف واجهة برمجة تطبيقات REST والتي ستستضيف احصل على مثل ماذا ، 10-20 RPS كحد أقصى؟

دعم Visual Studio

حقًا ، لا تزال تجربتي في Visual Studio 2017 على NET 4.x أفضل بكثير من .NET Core - مثال جيد على مقدار الوقت المستغرق لإعادة تجميع مشروع اختبار وعرض الاختبارات الجديدة في نافذة الاختبار . إنه أسرع بكثير على NetFX.

ينتهي بنا الأمر بموقف حيث لدينا اليوم مشروع NetFX و .NET Core جنبًا إلى جنب يجمعان أساسًا نفس التعليمات البرمجية. السبب الوحيد لمواكبة هذه الصيانة المزدوجة هو أداء Visual Studio مع مشاريع .NET Core (خاصة_اختبارات الوحدة ومصحح الأخطاء).

كفكرة لاحقة ، ما أذهلني حقًا هو أن هذا التغيير تم إجراؤه الآن ، قبل يومين من إصدار المعاينة. يبدو أنه يشير فقط إلى أنه لا يوجد سبب تقني للقيام بذلك حتى الآن - فلماذا لا يتم إجراء التغيير في ASP.NET Core v3؟

تضمين التغريدة

stefanolson هذا ليس صحيحا. يمكن للمكتبات التي تستهدف .Net Standard 1.x تشغيل العديد من إصدارات إطارات العمل الكاملة اليوم. تستهدف المكتبات .Net Standard 2.0 لتكون قادرة على العمل على 4.6.1 آخر مرة نظرت فيها. <

يبدو لي كما لو أن نواة asp.net ستشغل. net core وليس معيار net؟ لذلك ما زلت غير متأكد من الهدف من معيار .net - إذا تم التخلي عنه فعليًا بمجرد إنشائه.

سيكون من المنطقي تمامًا أن يتطلب نواة asp.net. net standard 2.1 لأن هناك أشياء يحتاجون إليها ليست في إطار العمل في الوقت الحالي. لذلك كان علينا الانتظار حتى يدعم إطار .net الكامل تلك الوظائف الإضافية قبل أن نتمكن من استخدام أحدث إصدار من Asp.net core. هذا من شأنه أن يعمل ويعطي معنى.

لكن بدلاً من ذلك ، هم فقط يتخلون عن المعيار الذي يجعل المعيار عديم الفائدة (إذا كنت أفهم هذا الموقف المربك بشكل صحيح)

لذلك ... سيبدأ بناء 2017 غدًا ؛ أتخيل أن الفريق مشغول جدًا بالتحضير لذلك. ربما بعض الإعلانات ، وربما لا. ربما ، امنحهم مساحة للتنفس واجتمع مرة أخرى في غضون أسبوع؟

ربما يمكنك مشاهدة العرض https://build.microsoft.com/ (الأربعاء 8:00 بتوقيت المحيط الهادئ ، 15:00 بتوقيت غرينتش والخميس متشابهين؟)

قد نعرف المزيد ؛ ربما لا. قد تكون الأمور أوضح ، وربما لا. ومع ذلك ، من المحتمل أن يكون فريق ASP.NET قادرًا على الاستجابة بشكل أفضل قليلاً والتركيز على مخاوف الجميع بشكل أكبر. على الرغم من أن davidfowl كان يعمل ببسالة!

stefanolson لكن بدلاً من ذلك ، هم فقط يتخلون عن المعيار مما يجعل المعيار عديم الفائدة (إذا كنت أفهم هذا الموقف المربك بشكل صحيح)

أعتقد أن الهدف من .NET Standard هو التوافق. يمكن لمؤلفي المكتبات استهداف .NET Standard ومن ثم يمكن لأي شخص استخدامها ، سواء كان ذلك على .NET Framework أو .NET Core أو أي شيء آخر يدعم .NET Standard.

أعتقد أن الهدف من .NET Core هو إعادة تخيل .NET Framework. NET Core هو نظام متعدد المنصات ، وعالي الأداء ، ومفتوح المصدر ، وسريع التطور.

يعد تغيير تنفيذ السلسلة إلى utf8 افتراضيًا أمرًا هائلًا وليس شيئًا تتوقع رؤيته على .NET Framework.

بعد قراءة هذا الموضوع أشعر:
NET Core -> NET Framework مثل ASP.NET MVC -> WebForms.

أرغب في دعم جانب الأدوات أيضًا. أداء الاستعادة / البناء / الاختبار الحالي وما إلى ذلك سيء للغاية ومؤلِم ملكي. إذا كان علينا "البقاء على الإصدار 1.0" ، فهل سنظل قادرين على استخدام حزم SDK الأحدث بأداء أفضل (ونأمل) أم أننا سنبقى عالقين مع 1.x SDK؟

قصة .NET Core هي جولة رائعة مليئة بالتقلبات. لقد بدأنا مؤخرًا العمل على ASP.NET Core بسبب كل عمليات "fuck ups" السابقة (تعيين الإصدار ، والتسمية ، وانتقال project.json - .csproj) وكنت (وأنا) أتطلع إلى .netstandard 2.0 ، لأنني أعتقد سيكون هذا أول إصدار "حقيقي".

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

إذا كنت تريد معرفة ما هو مانع (إلى جانب خدمات الدليل) من جانبنا: ما زلنا نستخدم EF6 وما زلنا ننتظر حزمة Open XML SDK NuGet الرسمية التي تستهدف معيار الشبكة على أي حال.
قد يستغرق ترحيل الشفرة وقتًا طويلاً ...

هل سيكون من الممكن إضفاء الطابع الرسمي على نوع من العملية للدفع للأمام netstandardXX بناءً على التغييرات التي تحدث في Core والتي تتضمن استهدافها كجزء من مرحلة الصيانة لإصدار مكتبة Asp.Net Core؟

كما هو الحال ، لدي تطبيق WebForms / MVC كنا على وشك سحب مشغل على تعريض واجهة برمجة تطبيقات ويب ANC والاتصال من SPA (وفي النهاية من تطبيق WebForms القديم) ، لكن لا يمكننا تطوير CoreCLR بسبب الاعتماد على برنامج تشغيل Sybase (الآن SAP) Ase ADO.NET (إذا كان شخص ما يقرأ هذا يمكن أن يضغط على زر في مكان ما في SAP ... للأسف لا يمكنني أن أسمع على الإطلاق عن هذا أو عن الأخطاء التي عرفتها منذ أكثر من 9 سنوات حتى الآن).

عند قراءة هذا العدد ، لم أعد متأكدًا بعد الآن مما يجب أن يكون عليه طريقي. الشيء الوحيد الذي أثق أنه يمكنني التخطيط له هو استمرار وجود برنامج تشغيل عربات التي تجرها الدواب لإطار عمل سطح المكتب. هل كان من المفترض أن أتجاهل التغييرات التي تم إجراؤها على ASP.NET على مدار السنوات العديدة الماضية لأنها كانت ستضيع وقتي ويجب أن أستهدف WebApi2 فقط؟ هل من المفترض أن أقول المضي قدمًا مع ANC 1.x مع العلم بأنني على الأرجح لن أقوم بالترحيل مطلقًا وأرى فوائد 2.x في تطبيق أعتقد أنه سيتم دعمه هنا لمدة 10-15 عامًا (تطبيق WebForms لديه تم ترحيلها وصيانتها منذ إصدار إطار العمل 1.1)؟

تضمين التغريدة

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

انتظر ماذا؟

لسنا جميعًا من مطوري الويب. لقد كنا ننتظر بفارغ الصبر دعمًا أفضل للتعامل مع السلسلة لسنوات ، والآن فجأة تخبرنا أننا SOL؟ أن .NET Framework والتطبيقات التي لا تعد ولا تحصى غير الويب المبنية عليه لن تتمكن أبدًا من الوصول إلى مكتبات معالجة السلاسل استنادًا إلى Span؟

لم يعد هذا مجرد مشكلة ASP.NET. إنه يذهب إلى صميم التزام Microsoft طويل الأجل بـ .NET Framework ومكتبة الفئة الأساسية الخاصة به.

كما تعلم ، يجب أن أعطيها لأشخاص مثل davidfowl لمواصلة الرد على الجميع والجميع للمساهمة في هذه المناقشة. لدي الكثير لألحق به من وقت سابق اليوم ، لكني أشعر كما لو أنني أتعلم الكثير من خلال كل تعليق فيما يتعلق بما يستخدمه الجميع / آمل في استخدام .NET من أجله.

أعتقد أننا سنصلح في النهاية بعض المسارات بمساعدة الجميع وآمل أن يتم أخذ جميع الأطراف في الاعتبار.

أنا في انتظار الإعلان الرسمي بفارغ الصبر

إذا فهمت ذلك بشكل صحيح ، فإن net coreapp 2.0 سيوفر شريحة توافق تسمح لمشاريعنا ASP.NET Core 2.0 بالاعتماد على مكتبات فئة NetFx القديمة (على سبيل المثال ، net461).
أين يمكنني العثور على مزيد من المعلومات حول القدرات / القيود المخططة حاليًا لمثل هذا الرقاقة المتوافقة؟

dgaspar هذا ليس دقيقًا حقًا ، وإليك طريقة عمله: netcoreapp2.0 يدعم معظم واجهات برمجة التطبيقات في net461 . إذا تم إنشاء مكتبتك مقابل net461 واستدعت فقط واجهات برمجة التطبيقات الموجودة داخل المجموعة الفرعية التي يدعمها netcoreapp2.0 ، فيمكنك عندئذٍ استيراد المكتبة على أي حال (فكر في الأمر على أنه تجاوز ، أنت تعرفه بشكل أفضل) وتشغيله ، لأن جميع الفئات والطرق التي تستدعيها يجب أن تكون موجودة.

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

MustafaHosny اللهم امين ...

"imports": [ "dnxcore50", "portable-net45+win8" ]

تعليق ذي صلة أدليت به في ديسمبر. تم ترحيل 11 إبهامًا إلى الأمام:

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

إذا أردت أن أتفاجأ في وقت التشغيل من خلال مكتبة عشوائية وأخطاء ناجمة عن إدارة الحزم لم يكتشفها المترجم ، فسأكتب تطبيقاتي بلغة Ruby.

حتى node.js يسمح لنا بالاتصال بكل مكتبات netfx بسهولة.

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

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

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

تضمين التغريدة

كفكرة لاحقة ، ما أذهلني حقًا هو أن هذا التغيير تم إجراؤه الآن ، قبل يومين من إصدار المعاينة. يبدو أنه يشير فقط إلى أنه لا يوجد سبب تقني للقيام بذلك حتى الآن - فلماذا لا يتم إجراء التغيير في ASP.NET Core v3؟

نحن نقوم بدعم HTTP2 بعد ذلك ويتطلب واجهات برمجة تطبيقات جديدة.

أرغب في دعم جانب الأدوات أيضًا. أداء الاستعادة / البناء / الاختبار الحالي وما إلى ذلك سيء للغاية ومؤلِم ملكي. إذا كان علينا "البقاء على الإصدار 1.0" ، فهل سنظل قادرين على استخدام حزم SDK الأحدث بأداء أفضل (ونأمل) أم أننا سنبقى عالقين مع 1.x SDK؟

نعم ، هذا سوف يعمل.

تضمين التغريدة

نحن نقوم بدعم HTTP2 بعد ذلك ويتطلب واجهات برمجة تطبيقات جديدة. <

لذا فإن نوع دعم HTTP2 الذي سيكون متاحًا في asp.net core 2.0 لن يكون متاحًا في 1.x؟ هذا هو نوع المشكلة التي أشعر بالقلق حيالها حيث لن نتمكن من الوصول إلى أحدث التقنيات لأننا ملزمون بإطار عمل .net الكامل لأي سبب من الأسباب. كما قلت أعلاه ، لا يهم ما إذا كان الأمر يستغرق من ستة أشهر إلى عام حتى يصل هذا المرشح إلى كل ما أستخدمه ولكن في النهاية لا أريد أن أتخلف كثيرًا. بسبب مشاركة الرموز واستخدام مكتبة الجهات الخارجية في هذه المرحلة ، أحتاج إلى إطار عمل .net كامل.

أخيرًا ، أوضحت بعض الأشياء:

• عندما أقول وحدات قديمة ، فهي dlls اعتمادًا على netfx أو c ++ / cli dlls ، والتي بدورها قد تؤدي إلى تثبيت بعض ملفات dlls الأصلية. هم للعمل / الخوارزمية ، لا COM ، لا asp.net. هم ليسوا سيئين. تصبح إرثًا بشكل رئيسي لأن .net core لا يديرها.
• من الممكن الانتقال إلى net core على المدى الطويل ، ونحن نريد ذلك حقًا. ولكن من الصعب حقًا دفع ذلك لتحقيق ذلك. سوف يستغرق الأمر بضع سنوات بالنسبة لنا وللأطراف الثالثة لنكون جميعًا هناك.
• المكتبات الخاصة بالمجال أبطأ بكثير من المكتبات السائدة لتغييرات مكدس التكنولوجيا. نعلم جميعًا مثال بيثون 3. هذه المكتبات الخاصة بالمجال هي أعمال حقيقية.

تضمين التغريدة

أعتقد أن الهدف من .NET Core هو إعادة تخيل .NET Framework. NET Core هو نظام متعدد المنصات ، وعالي الأداء ، ومفتوح المصدر ، وسريع التطور. <

وهو أمر رائع. يتمثل التحدي في كيفية التعامل مع قواعد الكود الحالية وكيف يمكننا الحصول عليها مع .net core. إذا كان WPF متاحًا على أساس .net core فيمكنني استخدام .net core في كل مكان. ولكن نظرًا لأنه ليس كذلك ويتم مشاركة الكود الخاص بي بين WPF و ASP.net ، فأنا بحاجة إلى طريقة لمشاركتها. لكنني لا أريد أن أتخلف كثيرًا عن أحدث تقنيات الويب وتقنيات الأمان التي يبدو أن معظمها (كلها؟) سيكون فقط في 2.x وما بعده

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

لا يبدو أن هذا هو الحال ولكن كما تم توضيحه في هذه المحادثة على Twitter

https://twitter.com/James_M_South/status/861595907782987776

والتعليق أعلاه ؛ التركيز منجم.

الفجوات الكبيرة المتبقية المفقودة في .NET Core 2 هي System.DirectoryServices و System.Drawing. نحن نعمل على الحصول على حزمة توافق Windows والتي من شأنها تمكين كل من تلك الموجودة على .NET Core على Windows هذا الصيف.

لقد كنت أعمل بجد مع .NET Core منذ وقت مبكر جدًا في محاولة لملء الفجوة التي خلفها System.Drawing باستخدام ImageSharp وأنا الآن مرتبك للغاية وأكثر من ساخط وأسأل:

ما هو NET Core الآن؟

هذا هو الوصف من MS Docs .

NET Core هو نظام أساسي لتطوير الأغراض العامة تحتفظ به Microsoft ومجتمع .NET على GitHub. إنه متعدد الأنظمة الأساسية ، ويدعم Windows و macOS و Linux ، ويمكن استخدامه في سيناريوهات الجهاز والسحابة والمضمنة / IoT.

هناك هذا البيان عبر النظام الأساسي مرة أخرى. هل هو أم لا؟ أعتقد أن محاولة تحديد هذا الأمر يؤدي إلى الكثير من الارتباك عبر مجتمع التنمية.

يبدو أن كل وصف قرأته مختلف.

هل يمكننا:

1. يرجى الحصول على رسالة لائقة ومتسقة ومكتوبة في مكان ما حتى نتمكن في الواقع من الحصول على هدف نهدف إليه وفهم شامل أفضل.
2. احصل على بعض الوضوح في خريطة الطريق الفعلية مقابل System.DirectoryServices و System.Drawing

System.Drawing على وجه الخصوص أمر محير ومقلق. لا أستطيع أن أفهم سبب رغبتك في نقل واجهة برمجة التطبيقات هذه إلى .NET Core على أي نظام أساسي. من الصعب العمل معه ، وغير مدعوم على الخادم ، ويفتقر إلى العديد من الميزات الهامة المطلوبة للتطوير الحديث (خيوط متعددة ، وتنسيقات بكسل ، و ICC ، و EXIF ​​، و Quantization ، و Indexed Png وما إلى ذلك).

يوجد الكثير من الأسماء والوجوه التي يمكن التعرف عليها هنا ، وأعلم أنني أضيف بعض الضجيج هنا ، ولكن:

• خدمات الدليل
• الرسم (ليس ما أحتاجه)
• إي أف

يبدو أن هذه الأشياء الثلاثة الأكثر أهمية يجب أن تكون على دراية بالسرعة قبل القيام بمثل هذا الاستراحة الكبيرة. شخصيًا ، معظم كل ما أعمل عليه موجود على net4x فقط بسبب EF6 ، منذ EFCore ... حسنًا ...: trollface:

تضمين التغريدة
أعتقد أنه من المتوقع أن تفصل الشفرة المشتركة في مكتبة .NET Standard. بعد ذلك سيكون قابلاً للاستخدام من WPF و ASP.NET على .NET Framework ومن ASP.NET على .NET Core وتطبيقات .NET Core الأخرى.

تضمين التغريدة
لا أعتقد أن حزمة توافق Windows جزء من .NET Core. إنها مكتبة خاصة بنظام Windows تقع فوق .NET Core. يمكنك أن تتخيل وجود مكتبة خاصة بـ Linux تعرض ميزات Linux فقط.

أعتقد أن حزمة Windows Compatible تدور حول تسهيل ترحيل قواعد التعليمات البرمجية لـ .NET Framework الحالية. من الواضح أنه بمجرد أن يتحول شخص ما إلى .NET Core ، يجب عليه بعد ذلك النظر في الانتقال إلى حلول أفضل مثل ImageSharp.

تضمين التغريدة
من المحتمل أن يتمكنوا حتى من إنشاء حزمة WPF لنظام التشغيل Windows فقط والتي تتيح لك إنشاء تطبيقات WPF في .NET Core ، ولكنها لن تعمل إلا على Windows.

تم ذكر مشكلة GitHub هذه في موقع إخباري ألماني لتكنولوجيا المعلومات:
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

شكرًا danielcrabtree ، هذه أول مرة أسمع فيها عن أي حزم توافق.

ترجمة رابط MJomaa : https://translate.google.com/translate؟u=https٪3A٪2F٪2Fwww.golem.de٪2Fnews٪2Fasp-net-core-2-0-microsoft-veraergert- net-entwickler-mit-support-entscheidung-1705-127712.htm

أنا في انتظار System.Xaml ليتم نقله.

alexwiese لا تحبس أنفاسك.

أنا في انتظار System.Xaml ليتم نقله.

تابع؛ أنا لدغة. كيف تستخدم Xaml على موقع الويب الخاص بك؟

تابع؛ أنا لدغة. كيف تستخدم Xmal على موقع الويب الخاص بك؟

واجهة مستخدم عبر النظام الأساسي (قوالب شاشة مشتركة بين تطبيق وحدة تحكم "الشاشة الخضراء" وتطبيق Xamarin و Angular SPA) ، تُستخدم أيضًا لمحرك قواعد الأعمال.

رائع ، حسنًا ، أنت تقوم بتحويل XML الخاص بـ XAML بطريقة ما إلى HTML و Javascript؟ عادل بما فيه الكفاية 😄

لم أكن متأكدًا مما إذا كنت تتصيد فقط.

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

رائع ، حسنًا ، أنت تقوم بتحويل XML الخاص بـ XAML بطريقة ما إلى HTML و Javascript؟ عادل بما فيه الكفاية 😄

بالطبع لا؛ أنا أقوم بالتحويل إلى JSON أولاً 😉

مقال إخباري آخر حول هذا الموضوع مع اقتباس العديد منا: https://www.infoq.com/news/2017/05/ASPNET-Core-2

@ cwe1ss المؤلف هو Grauenwolf

alexwiese @ yaakov-h أود قراءة منشور مدونة حول ذلك ؛ تبدو مثيرة للاهتمام ويجب أن تأتي مع مجموعة مختلفة من التحديات عما اعتدت عليه.

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

مع هذا التغيير ، تكون قفزة الكل أو لا شيء. ونظرًا لأنك لا تفهم دائمًا كل التبعيات مقدمًا ، فهذا يزيد من المخاطر.

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

يجب القيام بهذه الخطوة في نهاية المطاف ، ولكنها أقرب إلى أواخر عام 2019 أو 2020 على أقرب تقدير. حتى مع ذلك ، ما زلت تريد نموذجًا طويل المدى لدعم أولئك الذين اختاروا مزج الأشياء.

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

davidfowl ماذا عن شيء مثل edge.js لـ netcore؟ إنه يجعل مستهلك واجهة برمجة التطبيقات مسؤولاً عن فحوصات النظام الأساسي ، كما أن الواجهة المكتوبة بقوة بين netfx و netcore كافية لمعظم السيناريوهات.

هل سيتم إزالة هذا القالب بعد ذلك؟

لقد تم خبزه في VS2017 في الوقت الحالي.

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

أنا أقدر حقًا أيها الرجال الذين يتمتعون بتجربة ركوب وتشفير لطيفة ، ويمكنك التألق في إدخالات مدونتك وتويتر (مرحباً!) ، وتحسين ملفات التعريف الخاصة بك وسيرتك الذاتية (مرحبًا ^ 2) ، وجميع حفلات الإصدار أمامك ، والفتيات والمشروبات و الأشياء تبدو واعدة ، ولكن .. من سيستخدمها؟ هل تستهدف الشركات وتريد اعتمادًا كبيرًا وقاعدة مستخدمين صلبة؟ أو بعض الهيبيين بدء التشغيل فقط؟!؟

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

لقد ذكرت أنه إذا كنت تريد أن تكون المكتبة الخاصة بك مشتركة بين الأنظمة الأساسية ، فيجب عليك استهداف معيار الشبكة ، ولكن ما هو ASP.NET Core إذا لم تكن مكتبة مستخدمة على نطاق واسع؟ هل توصي المكتبات الأخرى ببدء إسقاط الدعم لشبكة الإنترنت والتحول إلى NET Core؟ هل يجب أن يكون الإصدار الرئيسي التالي من JSON.NET أو أيا كان معيار الإسقاط؟ يمكن أن تفعل بالتأكيد مع التحليل السريع!

ملاحظة تمكنت Java من إضافة إدخال / إخراج سريع بدون نسخ وما إلى ذلك بطريقة متوافقة مع الإصدارات السابقة مع Netty (https://netty.io/)

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

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

إن التحرك بسرعة وفي نفس الوقت "الابتعاد أيضًا" عن عملائك ليس بالأمر الجيد أيضًا. كما تعلم ، يمتلك عملاؤك (وأنا منهم) مجموعة جادة من البرامج القديمة واستثمار الوقت في التطبيقات والمكتبات الحالية. لا يمكنك تركنا وراءنا والذهاب إلى مكان لا يمكننا اتباعه أو عدم اتباعه.

يجب أن تفكر في عملائك الذين لا يمكنهم الذهاب إلى .Net core ويجب أن يستخدموا Full Framework لبعض الوقت على الأقل من الآن. إذا ابتعدت عن Full Framework ، فإنك تترك الكثير من الأشخاص عالقين في الإصدارات القديمة وتخلق انقسامًا كبيرًا في عالم الشبكة.

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

أتساءل كيف سيبدو ذلك ، وما إذا كان سيعتمد على Mono libgdiplus أم لا (وهو ما قد يزيل بعض المخاوف التي لديك مع System.Drawing ، لكن هذه قصة أخرى)

حسنًا ، بالطريقة التي أراها ، هناك مشكلتان على المحك:

1. تم توصيل هذا بشكل سيئ نوعا ما.
2. لم يشارك الناس في القرار. لاحظ أن مايكروسوفت حرة بالطبع في اختيار الاتجاه الذي تريده ، لكن عدم مناقشة هذا النوع من التغيير الكبير مع المجتمع ليس من منطلق تطوير المصادر المفتوحة.
3. لا يوجد "مخطط كبير" يمكن للمجتمع استخدامه لفحص هذه الأنواع من القرارات. في البداية ، كان .NET Core عبارة عن إصدار مقتطع متعدد الأنظمة من إطار العمل الكامل. بعد ذلك ، مع .NET Standard 2.0 ، بدا للكثيرين أن NET Core 2 سيكون بمثابة بديل سريع للإطار الكامل ، ضمن حدود معقولة بالطبع (بدون UWP ، WinForms ، إلخ).
4. سيفقد .NET Core 2 العديد من الوظائف المهمة الموجودة في إطار العمل الكامل ، مثل System.DirectoryServices. بقدر ما أستطيع أن أقول ، لقد تم الاعتراف بهذا ، ولكن ربما يكون الطريق إلى إضافة هذه الميزات إلى .NET Core أكثر وضوحًا.
5. لن يتم تشغيل ASP.NET Core 2 على إطار العمل الكامل بسبب عدم وجود ميزات أحدث في إطار العمل الكامل. أنا في الواقع بخير تمامًا مع هذا. إذا كانت إضافة الميزات المفقودة إلى إطار العمل الكامل صعبة للغاية ، فلا تفعل ذلك. إن تشغيل ASP.NET Core 2 فقط على .NET Core 2 أمر منطقي إلى حد ما ، على الرغم من أن ذكرهم على أنهم منتج واحد ربما لم يكن أفضل طريقة لوصف علاقتهم.

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

davidfowl أعتقد أن الأمر لا يتعلق فقط بـ HTTP 2.0 ؛ إذا كان الأمر يتعلق بالفعل بـ HTTP 2.0 ، فهل يمكن أن يكون لديك ASP.NET Core 2.0 هدف NetFX باستثناء دعم HTTP 2.0؟ ربما حتى نموذج قابل للتوصيل بحيث يمكن للمجتمع إجراء HTTP 2.0 على NetFX إذا أرادوا حقًا؟

cokkiy @ popcatalin81xprzemekw إذا لم يكن لديك أي شيء بناء لتقوله ، يرجى الامتناع عن التعليق ، فهذه الأنواع من التعليقات لا تساعد أي شخص.

هناك أسباب مشروعة وراء إجراء هذه الخطوة التي وصفها davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

تشمل أسباب تأجيله (على سبيل المثال asp.net core 3.0):

• EF Core ليست جاهزة بعد لاستبدال EF 6.0 بسبب نقص العديد من الميزات
• لا يوجد إنتاج جاهز لاستبدال System.Drawing
• لا System.DirectoryServices
• تم ذكر office xml sdk ، لكن يبدو أن هذا متاح بالفعل على netstandard اعتبارًا من 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/
• الحزم الأخرى خارج نطاق MS غير متوفرة على .net core (nhibernate ، مختلف موفري db ، ikvm)

تشمل أسباب عدم القيام بذلك على الإطلاق ما يلي:

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

مثال على التعليق البناء هو إضافة سبب رغبتك في رؤية أحد هذه السيناريوهات الثلاثة أو اقتراح حل بديل. إذا كنت تريد فقط التعبير عن الموافقة / عدم الموافقة ، فاستخدم أزرار "رد الفعل".

تضمين التغريدة

قام الأشخاص بنقل التطبيقات إلى asp.net الأساسية مع التبعيات القديمة مع عدم وجود نية للانتقال إلى .net core.

أتفق تماما. لأن Microsoft قد أعلنت أن ASP.NET Core سيعمل على كل من إطار عمل net core و .net. والآن فإن تركهم في AspNet Core 1.x ليس عدلاً.

الملخص الأخير جيد جدًا. أود فقط أن أضيف شيئًا أو شيئين:

1.) يجب أن يكون من الممكن كتابة Windows Services باستخدام .NET Core (أعلم أن العناصر الشريرة على الأنظمة الأساسية * NIX تعمل بشكل مختلف). لذلك ستظل هناك حاجة إلى ServiceBase ، وهذه أولوية عالية مع EF.

2.) يجب أن يكون من الممكن أيضًا كتابة خدمات مستقلة باستخدام .NET Core ، واستضافتها بشكل إضافي ضمن تطبيق .NET الحالي القائم على إطار كامل (أي خدمة مجانية من تطبيق Windows Forms / WPF) لتوسيعها.

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

أتفق تماما. لأن Microsoft قد أعلنت أن ASP.NET Core سيعمل على كل من إطار عمل net core و .net. والآن فإن تركهم في AspNet Core 1.x ليس عدلاً.

أود أيضًا أن أؤكد مرة أخرى أن التغيير الضخم الذي تم إجراؤه على .csproj و msbuild قد تم إعفاؤه بشكل أساسي من حقيقة أنه لن يكون من الممكن الرجوع إلى مشاريع .NET Core (ASP) من مشاريع .NET الحالية (ذات الإطار الكامل).

يجعل هذا التغيير الأخير مستحيلاً (على الأقل بالنسبة لجزء ASP.NET الأكبر). فلماذا كان التوافق أمرًا بالغ الأهمية في ذلك الوقت (وتسبب في الكثير من الألم) ، ولكن ليس الآن (ومرة أخرى يسبب الكثير من الألم)؟

آسف لا بد لي من التأكيد أيضا. لكن ما يقرب من 500 تعليق ، أعتقد أنه إذا كنت مشتركًا كرجل Microsoft في هذه المشكلة ، كان لدي خياران:
1: تجاهل المشكلة
2: إعادة التفكير في قراري

gingters كان تغيير csproj أساسًا لـ _.net_ core ، من أجل xamarin و asp.net و uwp وجميع الآخرين لمشاركة التعليمات البرمجية والإشارة أيضًا إلى أنواع المشاريع الأخرى مثل الكود الأصلي.

كما أنه يمكّن مشاريع asp.net الأساسية 2 من الرجوع إلى مشاريع الإطار الكامل ، مرة أخرى ، عبر الرقاقة المتوافقة

تضمين التغريدة

ربما حتى نموذج قابل للتوصيل بحيث يمكن للمجتمع إجراء HTTP 2.0 على NetFX إذا أرادوا حقًا؟

يمكنهم تقنيًا. لكن يبدو أنهم لا يريدون ذلك. بالنسبة لي ، أشعر أنهم لا يريدون التفكير في الاحتياجات الحقيقية للمؤسسات / الشركات الكبيرة ، أو حول التوافق مع الإصدارات السابقة أو الحاجة إلى التعامل مع شيء آخر غير الأشياء التأسيسية.

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

@ aL3891

من أجل xamarin و asp.net و uwp وجميع الآخرين لمشاركة التعليمات البرمجية

نعم. بالضبط. ويتضمن ذلك أيضًا تطبيق WPF / Windows Forms لاستهلاك مكتبات .NET Core ، وهو أمر مستحيل الآن عندما تريد الانتقال إلى .NET Core 2.

هل يمكن لشخص ما أن يشرح بالضبط سبب عدم تمكن هذه المكتبات من استهداف netstandard2.0 ؟

حتى الآن ، لقد اعتبرت netcoreapp لقبًا لمنصة تنفيذية عبر النظام الأساسي (تستخدم فقط في مشروع csproj القابل للتنفيذ) ، لكنني لم أعتبرها منصة ، الآن ، يجب اعتبارها منصة حقيقية؟ لماذا لماذا لماذا وكيف توصلنا إلى هذا الخيار العبثي؟