Aspnetcore: مناقشة: سيتم تشغيل ASP.NET Core 3.0 على .NET Core فقط

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

ومع ذلك ، أنا حزين بشأن الآثار المترتبة على بعض مكونات ASP.NET Core التي يمكن أن توجد حاليًا كتبعية منفصلة. لأن هذا سيعني على الأرجح أن المكونات الفردية ستسقط الدعم القياسي للشبكة ، مما يتطلب netcoreapp3.0 بدلاً من ذلك ؛ وخاصة مع # 3756 ، ستكون هذه المكونات غير قابلة للاستخدام خارج سياق ASP.NET Core.

على سبيل المثال ، سيتم إجبار مشاريع مثل

سيؤدي هذا إلى ترك الكثير من الأشخاص الذين باعوا ينتقلون إلى نموذج برمجة ASP.NET Core الجديد في مؤسستهم للبقاء على نظام أساسي مدعوم ومطور بشكل نشط في البرد على نظام أساسي غير مدعوم في أقل من 3 سنوات (. NET Core 2.1 LTS).

لست متأكدًا من التحليلات التي استخدمتها لتبرير هذه الخطوة ولكن لتشغيل تطبيقات ServiceStack ASP.NET Core على .NET Framework ، نرى أن قالب web-corefx الأكثر شيوعًا لتشغيل مشروع ASP.NET Core على NET Framework أكثر من 1/3 (33.8٪) حصة ثم نفس قالب الويب الفارغ الذي يعد أكثر قوالب المشاريع شيوعًا لدينا للتشغيل على .NET Core.

IMO 3 سنوات ليست وقتًا كافيًا للتخلي عن العملاء الذين بدأوا أو انتقلوا إلى نموذج برمجة ASP.NET الجديد (للهروب من منصة ASP.NET Framework الراكدة) فقط لمعرفة الآن أن النظام الأساسي الذي قاموا ببيعه تم التخلي عن منظمتهم للانتقال إليها.

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

"Killing .NET Framework" ، الحلقة الثانية: نفس القصة ، نفس الشخصيات : rofl:

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

ربما هذا أنا فقط ، لكنني لم أفهم أبدًا سبب عدم تحركها بسرعة netcoreapp (وهو أول من حصل على واجهات برمجة التطبيقات الجديدة ، حسب التعريف)

أنت مؤلف حزمة NuGet وتريد منهم استخدام أحدث الأشياء؟ استهدف أحدث إصدار من netstandard : بالتأكيد ، في البداية ، لن تتمكن سوى التطبيقات المستندة إلى netcoreapp من استخدامها ، ولكن في النهاية الأنظمة الأساسية الأخرى - مثل Xamarin أو Mono أو .NET Framework - ستلحق بالركب وسيتمكن الأشخاص من استخدام الحزم الخاصة بك دون مطالبتك بتغيير أي شيء. هذه هي الطريقة التي يجب أن تعمل بها الأشياء.

بالطبع ، قد يستغرق الأمر بعض الوقت حتى تتمكن الأنظمة الأساسية غير .NET Framework مثل .NET Framework من اللحاق بالركب لأن الإصدارات نادرة وشريط الاستقرار أعلى بكثير ، ولكن حتى لو استغرق الأمر 6 أو 12 أو حتى 18 شهرًا ، أعتقد أنها مشكلة ، لأن هذا ما يريده الناس عند استخدام .NET Framework: إطار عمل ثابت ، وليس هدف سريع الحركة.

IMHO ، سيكون أسلوبًا أفضل بكثير لجعل ASP.NET Core 3.0 يستهدف TFM جديدًا netstandard يعرض جميع واجهات برمجة تطبيقات .NET Core API التي تحتاجها. بمجرد التأكد من أن واجهات برمجة التطبيقات الجديدة مستقرة بدرجة كافية ، قم بنقلها إلى .NET Framework بحيث تكون متوافقة مع أحدث المعايير.

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

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

لا احب هذا. في بداية .net core ، لم تكن Microsoft تختار mono أو .net framework كمنصة مشتركة ، و قال u أن هناك عدة وقت تشغيل. net هناك لذلك قمت بتصميم .netstandard ، الآن لا يزال هناك العديد من حزم nuget التي لا تدعم .net core (السبب المتوسط). سيترك العديد من المطورين بعيداً عن نموذج البرمجة الأساسي القديم asp.net إذا كان asp.net core يعمل فقط على .net core. ثم .net standard سيوجد بالاسم فقط (على الأقل بالنسبة لنواة asp.net ، يبدأ الناس في بناء حزم netcoreapp فقط).
ربما في يوم واحد ، يمكن أن يحل. net core محل إطار.
وهناك سبب آخر لوقت ما أفضل إطار عمل .net وهو أن إطار المشاركة الأساسي .net ضخم حقًا ، فما حجم مجلد C:/program file/dotnet إذا قمت بترقية تطبيقك من .net core 2.0 إلى أحدث .net core 2.1؟ يوجد ملف GBs في مجلدي ، وهو ينمو عندما أقوم بتحديث وقت التشغيل الأساسي .net. لكن إطار .net سيحل محل الإصدار القديم فقط.

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

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

لذا معيار صافي هو مزحة؟ Hope mono سيقوم فريق aspnetcore بإعادة تسمية repos وإعادة تسميته إلى aspnetmono ، وإلا فقد أترك .net stack. stack

أعتقد أن هذا يعني أنه في عملي لن نستخدم ASP.NET Core أبدًا. سنبقى في ASP.NET إلى الأبد بغض النظر عن نقل تطبيق إلى Core لأن ذلك سيتضمن الآن المزيد من التغييرات.

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

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

تعال إلى .NET Core ، الماء الدافئ ...

لأي سبب من الأسباب ، هناك عملاء لا يمكنهم الانتقال إلى .NET Core بسبب الاعتماد على تبعيات .NET Framework فقط ...

والأكثر جدية ، يمكنك استخدام مكتبات .NET 4.x على .NET Core 2.0 منذ .NET Standard 2.0 ؛ على الرغم من وجود احتمال استخدام بعض الميزات التي لا تتوفر في .NET Core ؛ على الرغم من وجود حزمة توافق Windows لـ .NET Core التي تسد الكثير من هذه الثغرات ويتم دعم العديد من الميزات الأخرى في .NET Core 3.0 بما في ذلك COM interop ونماذج التطبيقات الأخرى مثل WinForms و WPF وما إلى ذلك.

من المحتمل أن يتم رفع أي أدوات حظر تمنع انتقال تطبيق ASP.NET Core إلى .NET Core من .NET Framework في dotnet / corefx .

ل Xamarin ؛ قد أكون مخطئًا ، لكنني أفترض أنه من غير المحتمل أن تستخدمه لتشغيل خادم ويب على iOS أو Android.

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

من أجل الوحدة الألعاب تفعل كل أنواع الأشياء الغريبة ، لذلك ربما لم يتم تناول هذا السيناريو ؛ إذا كانت اللعبة تستخدم خادم الويب في العميل ؛ بدلاً من الخادم أو خارج proc ؛ عندما يمكن لـ .NET Core تشغيل هذا الجزء.

خارج نموذج تطبيق ASP.NET Core ؛ على سبيل المثال ، بالنسبة للمكتبات ، يعد .NET Standard أكثر أهمية نظرًا لأن ASP.NET Core يحتوي على جميع أنواع الميزات المفيدة ، وتعتبر Razor مثالاً خاصًا.

لا تنتقل جميع المكتبات إلى .NET Core فقط (على سبيل المثال ، يبقى Microsoft.Extensions.* كـ .NET Standard) ومن المحتمل أن يكون من المفيد تقديم سيناريوهات محددة ستتأثر كما فعلت daveaglick في https: // github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416 بحيث يمكن أخذها بعين الاعتبار؛ فيما يتعلق بالمكتبات و / أو الميزات المحددة التي يمكن الاحتفاظ بها على .NET Standard بدلاً من مجرد "كل شيء" غامض.

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

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

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

gulbanana ماذا لو أن جوهر asp.net الخاص بك على إطار عمل .net باستخدام com؟ أو أن هناك حزمة nuget تدعم فقط إطار عمل .net؟

أعتقد أنها لم تكن أبدًا مسألة ما إذا كان يجب القيام بهذه الخطوة أم لا ، ولكن فقط متى.
في المرة الأخيرة التي تسبب فيها هذا في مناقشة ~ shitstorm ، لم يكن النظام البيئي جاهزًا للسماح بنقل التطبيقات الحالية.
الآن هناك حزم توافق Windows وتأتي WinForms و WPF إلى .NET Core.

أعتقد أن حزم 2.1 الموجودة في .NET Framework توفر مسارًا جيدًا للترحيل: انتقل إلى 2.1 على netfx ثم انتقل إلى .NET Core.

هذا مشابه لـ AngularJS vs Angular: قم بترحيل الكود الحالي إلى المكونات (الثابت) في الإصدار 1. * الأخير ، ثم الانتقال إلى أحدث إصدار من Angular. إنه صعب للغاية ولكنه ممكن.

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

لا تزال هناك بعض المواقع التي تستخدم ASP الكلاسيكية (ليس ASP.NET ، ولكن الأشياء القديمة حقًا). لا يزال يعمل ويشحن في Windows ، لن تقوم بإنشاء تطبيقات جديدة معه.
أعتقد أنه في أقل من 10 سنوات ، قد يكون هذا هو الوضع مع .NET Framework.

أوافق على الدعم الموسع المطلوب للإصدار 2.1 ، لكني أرغب في أن يراقب الفريق تنزيلات 2.1 حزمة لاتخاذ قرار خلال 2-3 سنوات إذا كانوا بحاجة إلى دعم (= إصلاح مشكلات الأمان المهمة) لفترة قصيرة أطول قليلا.

سيتم دعم @ John0King COM في .NET Core 3.0.

أيضًا: لدينا تطبيقات قديمة تستخدم أشياء مثل .NET Remoting.
لكن هذه إرث بالفعل.

يعمل العالم بشكل أساسي على رمز قديم وسيواصل القيام بذلك. إنه قرار تجاري يتعلق بنقل شيء ما إلى شيء "مدعوم" أو حتى "جديد" ، ولكن حتى ذلك الحين ، كما

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

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

إذا قمت بإجراء تحليل التكلفة / الفائدة ، فلست متأكدًا من أنه سيكون في صالح ASP.NET Core.

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

إذا قمت بإجراء تحليل التكلفة / الفائدة ، فلست متأكدًا من أنه سيكون في صالح ASP.NET Core.

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

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

يبدو أن هذا يزيل النقطة الوسيطة "ASP.NET Core on .NET Framework" التي من شأنها أن تجعل عمليات الترحيل أكثر تدريجيًا وأسهل. بعد ذلك ، يتم ترحيل ASP.NET MVC / WebAPI / إلخ. سيكون التطبيق على ASP.NET Core بمثابة تغيير كبير للغاية ، حيث يغير كل من إطار عمل الويب وأوقات التشغيل الأساسية مرة واحدة.

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

• لا يقوم EntityFrameworkCore بكل ما نطلبه ، والآن فقط مع .NET Core 3.0 يأتي EntityFramework نفسه إلى .NET Core. كم من ذلك وما هي الأنظمة الأساسية التي سيتم تشغيلها عليها ، لا أعتقد أنه تم توصيلها بوضوح ، وربما سأحتاج بالفعل إلى اختبار تصميم معاينة لمعرفة ذلك.

• يبدو أن قصة OData لا تزال في الهواء من حيث التطبيقات واسعة النطاق. هناك قدر كبير من (إعادة) العمل المطلوب للانتقال من OData 3 / System.Data.Services إلى OData 4 / WebAPI وما بعده. هذا شيء لم يتم حله منذ عدة سنوات ، وأنا بصراحة لست متأكدًا من أنه سيكون كذلك على الإطلاق.

بالإضافة إلى ذلك ، يتعين علينا الآن قطع جميع التقنيات الأخرى غير المدعومة (AppDomains ، Remote ، وما إلى ذلك) _first_ ، بدلاً من أن نكون قادرين على القيام بهذا العمل بالتوازي أو في مرحلة لاحقة.

بالإضافة إلى ذلك ، يتعين علينا الآن قطع جميع التقنيات الأخرى غير المدعومة (AppDomains ، Remote ، إلخ) أولاً ، بدلاً من أن نكون قادرين على القيام بهذا العمل بالتوازي أو في مرحلة لاحقة.

لماذا لا يمكنك الهجرة إلى 2.1 أولاً؟

davidfowl ربما يمكننا استخدام ذلك كوسيط ، إلا إذا صادفنا بعض الميزات الجديدة في 3.0 / 3.1 / إلخ. التي نحتاجها من أجل الهجرة. لم أقم بتحليل كامل حتى الآن ، لقد تم حظرنا في الغالب على EF و OData حتى الآن.

ميزة جديدة في ASP.NET Core 2.1 لازمة للترحيل؟ قصدت ASP.NET Core 2.1 على .NET Framework.

عندما ظهرت هذه المشكلة قبل عامين ، أتذكر الشكوى من صعوبة نقل كل شيء. هذا اقتباس من تعليق github القديم الذي أدليت به في ذلك الوقت:

تخيل تطبيقات الويب التي تستخدم Active Directory ، أو أتمتة Office COM ، أو التي تقوم بالتصوير المصغر باستخدام بعض النظام. رسم مكتبة قائمة ، أو مشاركة التعليمات البرمجية مع تطبيق WPF

الشيء الرائع هو أنه اعتبارًا من .NET Core 3.0 ، يتم دعم كل هذه السيناريوهات. تم إنجاز قدر كبير من العمل لتسهيل الأمر.

Davidfowl وكذلك فعلت أنا.

من الناحية الافتراضية ، قد تكون هناك بعض الميزات التي نستخدمها في ASP.NET/MVC/WebAPI والتي لم يتم تنفيذها في 2.1 ولكنها تصل في إصدار لاحق. في هذه الحالة ، لن يكون 2.1 نقطة انطلاق عملية.

يجب أن أقوم بتحليل أكثر شمولاً ، لمعرفة ما إذا كان هناك بالفعل أي شيء مهم نحتاجه ليس في 2.1.

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

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

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

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

ربما هذا أنا فقط ، لكنني لم أفهم أبدًا سبب عدم تحركها بسرعة netcoreapp (وهو أول من حصل على واجهات برمجة التطبيقات الجديدة ، حسب التعريف)

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

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

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

أعتقد أنه من المنطقي تمامًا أن تكون حزمة الويب لدينا قادرة على استغلال هذه القدرات ؛ والطريقة الوحيدة للقيام بذلك هي إزالة قيود ASP.NET Core للتشغيل على .NET Framework أيضًا. ضع في اعتبارك أن السبب الأصلي الذي جعلنا تشغيل ASP.NET Core يعمل على .NET Framework هو أن NET Core ببساطة لم يكن به واجهات برمجة تطبيقات كافية. في .NET Core 3.0 ، سيكون لدينا أكثر من 120 ألفًا من واجهات برمجة التطبيقات الحالية . هذا أكثر من نصف .NET Framework بأكمله ويتضمن أيضًا WinForms و WPF. نعم ، لا تزال هناك أعداد كبيرة من واجهات برمجة التطبيقات مفقودة ، لكننا حققنا تقدمًا كبيرًا في الذيل الطويل. على الرغم من أنه لن يكون لدينا تكافؤ بنسبة 100٪ ، إلا أنني أتوقع منا إغلاق هذه الفجوة بشكل أكبر للمضي قدمًا ، بناءً على بيانات العملاء.

@ yaakov-h سأكون مندهشا إذا كان هذا هو الحال. عندما تقوم بالتحليل ، أخبرني.

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

وأنت تتجه تمامًا نحو الاتجاه المعاكس: التخلي عن .NET Standard لـ ASP.NET Core لأنه لا يتحرك بالسرعة الكافية ، مما يجبر حزم NuGet التي تستهدف ASP.NET Core على التخلي عنها أيضًا. لا تجعلني أعتقد أنه تقارب ، فأنا لست جاهلاً : rofl:

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

إنه اختيار وليس مشكلة فنية: لا شيء يمنعك من تحديد ما إذا كان يجب تضمين واجهة برمجة تطبيقات معينة في إصدار جديد من .NET Standard عند مراجعتها لتضمينها في corefx / coreclr.

إذا كنت مهتمًا بما يبدو عليه هذا ، فأنا أدعوك لإلقاء نظرة على 35+ PRs التي دمجتها خلال الأسابيع الثلاثة الماضية بعد المراجعة من قبل جميع مالكي تطبيق .NET.

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

الحقيقة هي أن "التحرك بسرعة وكسر الأشياء" ليس شيئًا يقدره جمهورنا بالكامل.

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

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

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

هل لديك فرصة للترويج لـ Microsoft.AspNetCore.Razor.Language و Microsoft.AspNetCore.Razor خارج aspnet أو الاحتفاظ بها في موجة netstandard ؟ على الرغم من أن razor مخصص فقط لـ html ، إلا أن هناك العديد من المكتبات التي تستخدمه لقوالب البريد وسيكون من الرائع أن نستمر في استخدامه كما هو.

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

هل هذه خطوة يجب أن يتوقعها مطورو .NET الآن لجميع المكتبات الجديدة الأخرى التي طورتها Microsoft في العلن؟ هل يمكن للمجتمع الحصول على بيان رسمي أكثر حول مستقبل المعايير القياسية واعتمادها؟

terrajobst أفهم تمامًا وجهة نظرك فيما يتعلق بعدم الإضافة إلى .netstandard تلك واجهات برمجة التطبيقات التي لا يبدو أنها جاهزة لتغطي جميع الأنظمة الأساسية (ومن المحتمل ألا تكون كذلك أبدًا) ومع ذلك ، هذا لم يمنعك (MS) من تقديم netstandard2.0 عندما ، على سبيل المثال ، UWP لم يكن جاهزًا لدعمه. كما أفهم ، فقد استغرق الأمر جهدًا ملحوظًا لإضافة هذا الدعم في وقت لاحق ، لكنك فعلته. هل كانت تلك قصة مختلفة بطريقة ما؟

وأنت تتجه تمامًا نحو الاتجاه المعاكس: التخلي عن .NET Standard لـ ASP.NET Core لأنه لا يتحرك بالسرعة الكافية.

لا يكون ASP.NET Core منطقيًا إلا في .NET Framework و .NET Core ، ولكن يجب على الجميع تطبيق .NET Standard. ببساطة ، ليس من المنطقي ، على سبيل المثال ، جعل Xamarin / Unity يوفر واجهات برمجة التطبيقات (API) التي يتم استخدامها في الغالب بواسطة مكدس ويب آخر.

إنه اختيار وليس مشكلة فنية: لا شيء يمنعك من تحديد ما إذا كان يجب تضمين واجهة برمجة تطبيقات معينة في إصدار جديد من .NET Standard عند مراجعتها لتضمينها في corefx / coreclr.

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

إنها عملية مؤلمة لأنها تأتي مع الكثير من واجهات برمجة التطبيقات الجديدة في نفس الوقت.

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

ومع ذلك ، فهذه هي بالضبط الطريقة التي يعمل بها كل تكرار لـ ASP.NET Core: فهو يأتي مع تغييرات (هائلة في بعض الأحيان) تجعل الحزم المكتوبة لإصدار غير متوافقة مع الإصدارات التالية.

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

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

ما الذي يجعلك تعتقد أنها ليست مشكلة فنية؟ لا يعد شحن إصدارات .NET Framework جنبًا إلى جنب حلاً عمليًا. بادئ ذي بدء ، إنه مكلف إلى حد ما نظرًا لحقيقة أنه أحد مكونات نظام التشغيل وبالتالي يحتاج إلى الخدمة. ليس لديك أي فكرة عن مدى تعقيد إستراتيجية التفريع / الخدمة / التصحيح الخاصة بنا لـ .NET Framework 3.5 و 4.x. إضافة عنصر ثالث يكاد يكون غير عملي. ثانيًا ، يؤدي القيام بذلك أيضًا إلى مخاطر ، حيث نحتاج إلى إجراء تغييرات على التنشيط من أجل تحديد وقت التشغيل الصحيح لأشياء مثل المكونات المُدارة التي يتم تنشيطها بواسطة COM. وهذا يطرح السؤال عما إذا كنا ندعم عملية الشراء جنبًا إلى جنب أم لا وكم عدد التركيبات. إنها ليست مهمة بسيطة وليست خالية من المخاطر أيضًا.

لا تجعلني أعتقد أنه تقارب

PinpointTownes إنه تقارب ... على .NET Core 😉

ببساطة ، ليس من المنطقي ، على سبيل المثال ، جعل Xamarin / Unity يوفر واجهات برمجة التطبيقات (API) التي يتم استخدامها في الغالب بواسطة مكدس ويب آخر.

هناك أشخاص يرغبون في استخدام ASP.NET Core ليس فقط على .NET Core ، ولكن أيضًا على UWP ، فلماذا لا يستخدم Xamarin أيضًا؟ https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

هناك فرق بين شيء لا معنى له - بالنسبة لك - وشيء لا تريد دعمه.

CoreFx repo عبارة عن ريبو كبير الحجم. من الأسهل بكثير على Xamarin و Unity مراجعة الميزات المجمعة معًا بدلاً من الشرب من خرطوم الإطفاء والاشتراك في جميع مناقشات API على CoreFx.

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

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

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

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

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

بادئ ذي بدء ، إنه مكلف إلى حد ما نظرًا لحقيقة أنه أحد مكونات نظام التشغيل وبالتالي يحتاج إلى الخدمة. ليس لديك أي فكرة عن مدى تعقيد إستراتيجية التفريع / الخدمة / التصحيح الخاصة بنا لـ .NET Framework 3.5 و 4.x. إضافة عنصر ثالث يكاد يكون غير عملي.

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

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

بالتأكيد ، هذا ليس بالأمر السهل. وهذا محفوف بالمخاطر. ولكن هذا ما تشير إليه الإصدارات الرئيسية: هناك مخاطر قد تنكسر. الآن ، بين الاضطرار إلى البقاء إلى الأبد على ASP.NET Core 2.2 والمخاطرة للانتقال إلى .NET Framework 5 لاستخدام ASP.NET Core 3.0 ، ما الذي تعتقد أن الناس سيختارونه؟

ولكن هل أنا مخطئ تمامًا في اعتقادي أنك - Microsoft - لديك موارد للتعامل مع ذلك أكثر بكثير مما يتعين على الشركة العادية الانتقال إلى .NET Core؟

من واقع خبرتي ، يبالغ الناس باستمرار في تقدير عدد الموارد التي لدينا ومقدار العمل الذي يتعين علينا القيام به من أجل دعم الوضع الراهن بمفرده.

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

الآن ، بين الاضطرار إلى البقاء إلى الأبد على ASP.NET Core 2.2 والمخاطرة للانتقال إلى .NET Framework 5 لاستخدام ASP.NET Core 3.0 ، ما الذي تعتقد أن الناس سيختارونه؟

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

هل ينطبق هذا على جميع أجزاء ASP.NET Core ، أم أن بعض الأجزاء المفيدة والقابلة لإعادة الاستخدام بشكل عام (مثل Microsoft.AspNetCore.Http.Extensions ) ستبقى على .NET Standard؟

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

terrajobst أفهم تمامًا وجهة نظرك فيما يتعلق بعدم الإضافة إلى .netstandard تلك واجهات برمجة التطبيقات التي لا يبدو أنها جاهزة لتغطي جميع الأنظمة الأساسية (ومن المحتمل ألا تكون كذلك أبدًا) ومع ذلك ، هذا لم يمنعك (MS) من تقديم netstandard2.0 عندما ، على سبيل المثال ، UWP لم يكن جاهزًا لدعمه. كما أفهم ، فقد استغرق الأمر جهدًا ملحوظًا لإضافة هذا الدعم في وقت لاحق ، لكنك فعلته. هل كانت تلك قصة مختلفة بطريقة ما؟

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

لكننا نتحدث الآن عن إضافة قدرات ومفاهيم جديدة تمامًا وهذا شيء مختلف للقيادة.

من واقع خبرتي ، يبالغ الناس باستمرار في تقدير عدد الموارد التي لدينا ومقدار العمل الذي يتعين علينا القيام به من أجل دعم الوضع الراهن بمفرده.

من واقع خبرتي ، تبالغ Microsoft باستمرار في تقدير عدد الموارد التي لدينا ومقدار العمل الذي يتعين علينا القيام به لدعم الوضع الراهن بمفرده. حجتك تعمل حقًا في كلا الاتجاهين: sweat_smile:

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

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

أنا بالتأكيد أتفهم مخاوفك. ولكن في النهاية ، ما يجعل حياتك أسهل لديه فرصة لجعل حياتنا أكثر إيلامًا: عدم دعم .NET Framework سيكون بمثابة بيتا بالنسبة لنا.

أنا بالتأكيد أتفهم مخاوفك. ولكن في النهاية ، ما يجعل حياتك أسهل لديه فرصة لجعل حياتنا أكثر إيلامًا: عدم دعم .NET Framework سيكون بمثابة بيتا بالنسبة لنا.

هذا الجزء أفهمه. لكن البديل لن يكون المزيد من الميزات في .NET Framework ولكن ببساطة ASP.NET Core أقل قوة.

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

لن يعمل حتى يقوم .NET Core بإدراك معظم / جميع الميزات التي يمتلكها .NET Framework وتنفيذها

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

لكن البديل لن يكون المزيد من الميزات في .NET Framework ولكن ببساطة ASP.NET Core أقل قوة.

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

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

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

أنا آسف حقًا لكوني ذلك الرجل: sweat_smile:

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

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

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

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

حتى الآن على جبهة ASP.NET Core ، رأيت Razor تظهر كشيء ملموس يرغب الناس في أن يكون متاحًا خارج ASP.NET Core بشكل عام.

يمكنك إضافة حزمة Microsoft.Owin.Security.Interop backcompat ، ASP.NET Core Data Protection والتبعيات الأساسية إلى القائمة.

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

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

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

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

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

terrajobst استمر في ذكر الوحدة. هل لديهم تطبيق CLR الخاص بهم؟ كان لدي انطباع بأنهم يستخدمون Mono.

تمتلك الوحدة العديد من تطبيقات .NET ، بما في ذلك إصدار AOT غير الأحادي الخاص بها ، IL2CPP. تختلف أيضًا مكتبة الفصل وواجهات برمجة التطبيقات المدعومة عن Mono القياسي.

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

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

لا يوجد فرق كبير عندما يتعلق الأمر بالتطبيقات "القديمة" التي لا تزال قيد الصيانة والتطوير بشكل نشط. هناك فرق كبير بين ترقية إطار العمل مقابل الاضطرار إلى الترحيل إلى .NET Core.

على الرغم من أنه من المحتمل أن تكون ميزة .NET Core فقط هي التي تسمح لنا بتطوير NET Core مع الاستمرار في القدرة على استهلاك التعليمات البرمجية التي تم تجميعها مقابل .NET Framework.

الى أي نهاية؟ لن تنطبق أي من واجهات برمجة التطبيقات "المتطورة" في .NET Core على .NET Standard. ولن يلمسها أي كاتب مكتبة نظرًا لكيفية إنشاء تباعد غير متوافق في واجهات برمجة التطبيقات الخاصة بهم.

أتفق مع HaloFour. الأشخاص الوحيدون الذين سيكونون قادرين على الاستفادة من DIM هم مؤلفو المكتبات الذين يستهدفون .NET Core فقط ... لذلك في الأساس مجرد corefx و aspnetcore. لا أستطيع أن أتخيل أن أي شخص آخر سيقترب منه.

الأشخاص الوحيدون الذين سيكونون قادرين على الاستفادة من DIM هم مؤلفو المكتبات الذين يستهدفون .NET Core فقط ... لذلك في الأساس مجرد corefx و aspnetcore.

حسنًا ، هناك طريقة أخرى للصياغة تتمثل في أن النظام الأساسي الوحيد الذي لا يمكنك استخدامه هو .NET Framework بينما يمكنك استخدام .NET Core و Xamarin و Mono و Unity.

لا أستطيع أن أتخيل أن أي شخص آخر سيقترب منه.

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

@ yaakov- ح

هل هذا ينطبق على جميع أجزاء ASP.NET Core ...

القائمة المؤقتة لما يحدث للحزمة هنا: https://github.com/aspnet/AspNetCore/issues/3756

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

نقوم بتشغيل عدد قليل من أحمال عمل NET Core ولكن أيضًا ندير مشاريع متعددة السنوات. NET FX.

تعد الترقية إلى .NET Core (حتى على .NET Framework في البداية) بأمان مهمة كبيرة جدًا.

هل هناك أي خطط لشركة Microsoft لإصدار بعض الأدوات للمساعدة في "ترقية" المشاريع من ASP.NET على الأقل على .NET FX إلى ASP.NET Core إلى .NET FX؟

هناك مقالات MSDN حول إنشاء مشاريع VS جديدة واستيراد طرق العرض وإعادة تنظيم المشاريع ولكن هناك الكثير من الأشياء القديمة (asax عالمي ، والتوجيه ، ....) التي أتمنى أن يكون هناك مكان مركزي وثق الطريقة القديمة مقابل الجديدة للمساعدة نقل كل شيء.

ما الذي يمنعك من تقديم إصدار جديد من .NET Framework جنبًا إلى جنب (دعنا نقول .NET Framework 5) يتضمن تلك التغييرات "الخطرة"؟

في هذه المرحلة ، هل هناك أي ميزة لعدم كونه .NET Core 3.0؟ إنها بالفعل جنبًا إلى جنب ولديها التغييرات "الخطرة". هل ستحتاج المجموعة التالية من ميزات .NET Core بعد ذلك إلى .NET Framework 6 وما إلى ذلك؟

مع وجود واجهة برمجة تطبيقات موجودة بالفعل في .NET Core 2.0 ومجموعة الميزات الجديدة القادمة إلى .NET Core 3.0 ألا يفي .NET Core بـ ".NET Framework 5" مع كون Framework 4.x هو إصدار LTS الطويل للغاية ؟

في تخمين في هذه المرحلة ، سيكون تحديًا هندسيًا أصغر لتغطية أي ثغرات محددة محددة موجودة في .NET Core 3.0 من .NET Framework 4.x بدلاً من تغيير .NET Framework ليتصرف مثل NET Core.

اقتراح عملي: هل هناك أي احتمال أن يصبح ASP.NET Core 2.2 LTS بمدة دعم _ ممتدة_ تزيد عن الثلاث سنوات الشائعة؟

أنا متأكد من أن ذلك سيرضي أولئك الذين يتعين عليهم الالتزام بإطار العمل الكامل في الوقت الحالي ، مع منحهم أيضًا (1) وقتًا كافيًا للانتقال فعليًا إلى .NET Core و (2) دافعًا كافيًا للانتقال بعيدًا عن ASP.NET MVC إلى ASP NET Core (عندما لا يتمكنون من الانتقال إلى .NET Core _yet_).

ما زلت لا أعتقد أن هذا واضح ، هل يتبع ASP.NET Core على .NET Framework. NET Core 2.1 LTS أم أنه يتبع دورة دعم .NET Framework v4.6.1 + (أي منذ تشغيله على .NET FX) حيث هل يتم دعمه في المستقبل المنظور؟

mythz يتم تغطية ASP.NET Core ضمن دورة حياة دعم .NET Core ، بغض النظر عن النظام الأساسي الذي تقوم بتشغيله عليه.

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

هل لديكم عملاء بالفعل يدفعون مقابل دعم LTS اليوم؟ (مجرد سؤال تجريبي). كم من الوقت هو الوقت الكافي؟

terrajobst يبدو أن المشكلة الحقيقية هي أن netstandard متجانسة. يبدو أننا لسنا بحاجة إلى شبكة قياسية ولكن مجموعات API ذات إصدارات بدلاً من ذلك. ستكون هذه أيضًا TFM ، على سبيل المثال base2.0 + span ستكون مجموعتين من API.

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

مع وجود مجموعات API في مكانها ، سيتم إنشاء بناء منفصل من ASP.NET Core للأهداف الأقل دعمًا مثل الإطار الكامل.

Sebazzz هذا موضوع غريب للغاية. ألا يمكننا إخراج هذا الخيط عن مساره بمحاولات إعادة تصميم الشبكة القياسية؟ يمكنك تقديم مشكلة على dotnet / standard لذلك ولكن سأخبرك أن هذه الفكرة قد تم اقتراحها بالفعل وتم إسقاطها.

davidfowl لا أعتقد أن هذا "غريب" أو "خروج عن المسار" على الإطلاق. يبدو بالضبط مثل ما نحتاجه ، إذا كان أقل دقة قليلاً من الطريقة التي اقترحها. إذا كانت المشكلة في كل هذا هي أننا سنضطر في النهاية إلى وضع كل عناصر خادم الويب هذه في تطبيقات مثل Xamarin و Unity التي لا تهتم بخوادم الويب ، فحينئذٍ تقوم IMO بإنشاء مجموعة API ".NET Web Server Standard" منفصلة سيكون الحل الأمثل.

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

terrajobst يبدو أن المشكلة الحقيقية هي أن netstandard متجانسة. يبدو أننا لسنا بحاجة إلى شبكة قياسية ولكن مجموعات API ذات إصدارات بدلاً من ذلك. ستكون هذه أيضًا TFM ، على سبيل المثال base2.0 + span ستكون مجموعتين من API.

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

يسعدني مناقشة NET Standard بمزيد من التفاصيل ، لكنني أتفق مع davidfowl على أن هذا لا ينتمي هنا. إذا كنت ترغب في ذلك ، فقم بتقديم مشكلة في https://github.com/dotnet/standard.

تحرير لقد قمت بتمييز تعليقات .NET Standard على أنها خارج الموضوع.

@ شايان إلى

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

إنها ميزة تتطلب تغييرات اللغة وكذلك تغييرات وقت التشغيل. إنه مشابه للأدوية لأنه يغير قواعد نظام الكتابة. بشكل عام ، لا تعرف C # إطار العمل الذي تقوم بتجميعه (يتم تمرير مجموعة من التجميعات المرجعية التي تصف واجهات برمجة التطبيقات التي يقدمها إطار العمل). سيتم دعم أي ميزة C # لا تتطلب تغييرات في واجهة برمجة التطبيقات (على سبيل المثال ، عامل الاندماج الصفري ?. أو _ لتجاهل التعبيرات). من حيث أنه مماثل لكيفية عمل المترجم دائمًا عند استخدام أحدث إصدار للمترجم واللغة واستهدفت إصدارًا أقدم من .NET Framework الذي يفتقر إلى واجهات برمجة التطبيقات المقابلة. على سبيل المثال ، لن يعمل عدم التزامن / انتظار إذا كنت تستهدف .NET Framework 3.5 أو 4.0 - يجب أن تكون على 4.5 أو أعلى من أجل استخدام Task .

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

ومع ذلك ، سوف ينزعج الناس من هذا .. جزء كبير منه هو التواصل. عندما تم الإعلان عن إصدار 2.1 3 year LTS ، توقع الأشخاص الذين يستخدمون fullfx أن يكونوا قادرين على الانتقال إلى 3.0 مع الاستمرار في تشغيل fullfx ، فسيكونون قد باعوا asp.net core لأرباب العمل والعملاء الذين يضعون سمعتهم الخاصة على المحك ، و الآن سيشعرون وكأن السجادة قد تم سحبها تحتها. ما تم بيعه كحل طويل الأجل ، مستقبل asp.net ، أصبح الآن (بشكل مدرك) حدًا لمدة 3 سنوات من الدعم

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

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

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

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

ما هو الوقت المناسب لـ LTS؟

6 سنوات ربما؟ أعتقد أن المراسلة ستلعب دورًا كبيرًا في الاستقبال بالرغم من ذلك .. في النهاية ، سينزعج بعض الأشخاص مهما حدث: /

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

كمرجع ، Java LTS "Premier Support" هي 5 سنوات مع "Extended Support" (مدفوع) لثلاث سنوات إضافية. سيتم دعم Java 11 ، وهو إصدار LTS وتم إصداره الشهر الماضي ، حتى سبتمبر 2023 و سبتمبر 2026 على التوالي

نحن نحقق في عرض LTS "الدعم الموسع" وسنقدم المزيد من التفاصيل عندما يكون لدينا. من المحتمل أن يوفر هذا للعملاء الذين يحتاجون إلى ASP.NET Core مدعوم على إصدار .NET Framework (2.1.x) خيارًا أطول من فترة دعم LTS الحالية.

لمعلوماتك أيضًا ، تحدثت قليلاً حول الإعلانات اليوم على ASP.NET Community Standup: https://www.youtube.com/watch؟v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

الهدف معيار صافي ، من فضلك. يمكن لنواة asp.net أن تستهدف .netstandard2.1 أو 3.0 وتدع أحادي و netframework يلحق لاحقًا ، ولكن إذا كان هدف asp.net الأساسي netcoreapp ، إذن تحاول أي مكتبة الوصول إلى نوع من تلك المكتبات aspnetcore يجب أن تكون مكتبة .netcoreapp .

و. net core سيتم إطلاقه دائمًا بشكل أسرع من .net framework و mono ،
ستستهلك mono و. netframework في النهاية تجميعات .netcoreapp إذا بدأت Microsoft تستهدف المزيد من الأطر / المكتبات إلى netcoreapp (سيؤدي ذلك إلى المزيد من المكتبات على الهدف nuget .netcoreapp أيضًا).

إذا كان الأمر كذلك ، فإن .netstandard سيصبح .netcoreapp 😂

@ John0King يرجى إعطاء أمثلة للأنواع التي تحتاجها خارج ASP.NET Core.

1. الحلاقة كما ذكر poke
2. واجهات / سمات عامل التصفية MVC (لدي مكتبة فئة مساعدة تحتوي على بعض ActionFilters و TagHelpers وطريقة ثابتة / تمديد شائعة للسلسلة ، int ، long ، إلخ. أستخدم PrivateAssert="All" للإشارة إلى حزم MVC لذلك عندما أستخدم هذا مكتبة في أي مكان آخر ، لا يجب أن يشير هذا المشروع إلى تجميعات MVC ، أعتقد أنه يجب أن أقوم بفصل المكتبة إلى مجموعتين ، أحدهما .netstandard والآخر .netcoreapp )

سؤال آخر هو: هل ستكون مشكلة بالنسبة لنوع مكتبة الفصل التي يجب أن أقوم بإنشائها؟ ( .netstandard مقابل .netcoreapp ). اليوم بسيط جدًا في asp.net core 2.1. اختر .netstandard لمكتبة الفصل ، اختر .netcoreapp أو net461 لمشروع الويب.

ستستهلك mono و. netframework في النهاية تجميعات netcoreapp. إذا بدأت Microsoft في استهداف المزيد من الأطر / المكتبات إلى netcoreapp (سيؤدي ذلك إلى المزيد من المكتبات على nuget target .netcoreapp أيضًا)

سيحدث هذا إذا لم يحاول الأشخاص بجهد أكبر فصل ما يجب أن يأتي إلى مكتبة .netstandard وما يأتي إلى مكتبة .netcoreapp

واجهات / سمات عامل تصفية MVC (لدي مكتبة فئة مساعد تحتوي على بعض عوامل تصفية ActionFilters و TagHelpers وطريقة ثابتة / تمديد شائعة للسلسلة ، int ، long ، إلخ. أستخدم PrivateAssert = "All" للإشارة إلى حزم MVC ، لذلك عندما أستخدم هذه المكتبة في بعض الأماكن الأخرى ، لا يجب أن يشير هذا المشروع إلى تجميعات MVC ، أعتقد أنني يجب أن أقوم بفصل المكتبة إلى قسمين ، أحدهما. netstandard والآخر .netcoreapp)

هل يمكنك التفصيل؟ هذا غير منطقي. MVC هو إطار عمل ASP.NET Core ولا يمكن استخدامه بشكل مستقل.

davidfowl هذه المكتبة عبارة عن مكتبة فئة مساعدة ، يمكنني استخدام هذه المرشحات عندما أعمل في مشروع asp.net core MVC وأستخدم فقط طرق الامتداد الخاصة به في تطبيق وحدة التحكم.

davidfowl هذه المكتبة عبارة عن مكتبة فئة مساعدة ، يمكنني استخدام هذه المرشحات عندما أعمل في مشروع asp.net core MVC وأستخدم فقط طرق الامتداد الخاصة به في تطبيق وحدة التحكم.

ما زلت لا أفهم. هل تتحدث عن مكتبة بها أشياء MVC وأشياء عشوائية أخرى؟

لسوء الحظ ، هذا النوع من الأشياء شائع في برامج المؤسسات - "المكتبات المساعدة" التي لديها ، مثل ، أدوات الشركة المساعدة لـ MVC + أدوات الشركة الخاصة بـ WPF + أدوات الشركة للاتصال telerik ...
كان من المنطقي أكثر عندما كانت ".NET" عبارة عن نظام أساسي واحد موحد.

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

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

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

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

أود حقًا الحصول على رد من فريق .net على هذا.

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

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

أعتقد أن هذا سيكون أكثر قبولًا للمجتمع إذا قمت فقط بزيادة فترة LTS لـ ASP.NET Core 2.1 إلى 5-7 سنوات.

في تجربتنا ، يتحرك تطوير المؤسسات على مستوى الشركة بوتيرة جليدية مقارنة بتطوير الويب "الحديث" ، ومع ذلك فهم لا يزالون يرغبون في التأكد من أنهم لا يقومون باستثمارات جديدة على منصات أقدم بشكل ملحوظ. غالبًا ما تستغرق هذه التطبيقات أكثر من عام حتى يتم تشغيلها ، ناهيك عن القدرة على إجراء ترقية كبيرة في غضون 3 سنوات. غالبًا ما يتم دعم تطبيقات الويب الخاصة بالمؤسسات (عادةً ما تكون داخلية فقط) لمدة 7-10 سنوات ، على الرغم من أنني أعتقد أنه من غير المعقول أن يكون LTS لـ ASP.NET Core 2.1 10 سنوات. تبدو 5 سنوات كحل أفضل من 3 ، مع كون 7 سنوات شخصية ستجعل الجميع مرتاحين بالتأكيد.

وهذا ضروري فقط لأن ASP.NET Core 3.0 يتطلب تغيير فاصل رئيسي يزيل دعم .NET Framework. لا ينبغي أن تلتزم إصدارات LTS المستقبلية بهذا المعيار ، على افتراض أن التغييرات العاجلة ليست بهذا الحجم.

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

ماذا لو لم تتمكن المنصة من اللحاق بالركب؟ ثم سيكون لديك مكتبة تستهدف netstandard2.3 والتي تحتاج إلى الميزة A التي لا تتوفر إلا على .NET Core و Xamarin ، ولكنها مستحيلة مع .NET Framework.

ثم يخرج netstandard2.4 ، مع وجود عدد قليل من Apis الجديدة وبعض واجهات برمجة التطبيقات هذه يمكن نقلها إلى .NET Framework. ماذا الان؟

كيف تستهدف مكتبة تحتاج إلى ميزة من netstandad2.4 تعمل على .NET Framework ، ولكن netstandard2.4 لا يمكنها استهداف .NET Framework ، لأنها لا تستطيع تنفيذ netstandard2.2 .

ثم سيتعين عليك التحويل إلى ثلاث منصات:
netstandard2.2 للمنصات القديمة و net4x للمعيار الصافي فقط لدعم الميزة التي تمت إضافتها في netstandad2.4 و التي net4x can also implement but not support because of APIs that went into netstandard2.3`.

كيف سيسهل ذلك على مؤلفي الحزم كتابة حزم الكتلة الأصلية وشحنها؟

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

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

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

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

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

ماذا لو لم تتمكن المنصة من اللحاق بالركب؟ ثم سيكون لديك مكتبة تستهدف netstandard2.3 والتي تحتاج إلى الميزة A التي تتوفر فقط على .NET Core و Xamarin ، ولكنها مستحيلة مع .NET Framework.

إذا كان لا يمكن تنفيذ API بواسطة غالبية الأنظمة الأساسية التي تدعم .NET Standard ، فحينئذٍ تكون الاحتمالات كبيرة ألا تكون جزءًا من المعيار ، أليس كذلك؟ (من الناحية العملية ، من المحتمل جدًا أن يكون العكس ، نظرًا لأن الأنظمة الأساسية التي يعمل عليها Xamarin تكون مقيدة بشكل عام). أتوقع اكتشاف هذا النوع من المشكلات عند مراجعة واجهة برمجة التطبيقات للتضمين في .NET Standard ، ولكن قد أكون مخطئًا.

والأشخاص الذين يستخدمون بالفعل ASP.NET Core 2.1 على .NET Framework ، إذا كان يعمل فلماذا تريد الانتقال؟

• الدعم؟ (دعم لمدة 3 سنوات قصير للغاية)
• إصلاح الخلل موجود في 3.0 فقط؟ (لا تحصل إصدارات LTS إلا على إصلاحات للأخطاء ونقاط الضعف الحرجة)
• هل تحتاج إلى الرجوع إلى مكتبة متوافقة فقط مع أحدث إصدار من ASP.NET Core؟

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

نعم ، بالتأكيد ، من الناحية النظرية ، هذه هي الطريقة المثالية للتعامل مع ذلك. لكن:

• تعتمد بعض التطبيقات على مكتبات خارجية لا يمكنك التحكم فيها. إذا كانت المكتبة لا تعمل على .NET Core ولا يريد البائع (أو لا يمكنه) نقلها ، فأنت محظوظ.
• قد يكون الترحيل إلى .NET Core مكلفًا ويستغرق وقتًا طويلاً. إذا كانت حتى أفضل فرق Microsoft تكافح مع ذلك ، فهل تعتقد حقًا أنه سيكون بهذه السهولة لأي فريق متوسط؟ سيتعين علينا انتظار 3.0 لنرى أن Entity Framework 6 متوافق أخيرًا مع .NET Standard.

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

Microsoft ، هل سيكون طلب تمديد دعم 2.1 أكثر من اللازم؟ 2021 ليست طويلة بما يكفي بالنسبة لنا وليس لدينا ما يكفي من الموارد / الوقت لإجراء هذا التحويل. ربما حتى عام 2022 على الأقل؟ سنة إضافية ستمنحنا حقًا فرصة لإجراء التغييرات ، وإن كانت مؤلمة.

ضع في اعتبارك أن العديد من البائعين الخارجيين لم يقوموا بعد بترحيل مكتباتهم إلى توافق .Net Core ، وهو أكبر أسباب إنهاء المكالمة.

لمعلوماتك https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

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

عندما أعلنت MS عن EOL of Silverlight 5 في عام 2012 ، فإنها ما زالت تدعمها حتى أكتوبر 2021 (على الرغم من إسقاطها في Chrome في 2015 و Firefox في 2017). هذا يتعلق بالتكنولوجيا التي تم التخلي عنها تمامًا وهذا ليس هو الحال هنا ، إلى حد كبير نفس الكود الأساسي ونموذج البرمجة وفريق التطوير النشط لا يزالون يعملون عليها ، فهي تقوم فقط بتشغيل البرامج الموجودة على .NET Framework التي تم التخلي عنها.

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

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

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

لدى MS أيضًا الفرصة لوضع ASP.NET Core على FX كبيئة تطوير "مستقرة" (أي ثابتة في ASP.NET Core 2.1). لم يكن من السهل أن تكون مطور .NET في السنوات القليلة الماضية منذ أن بدأ .NET Core. لقد اضطررنا فعليًا إلى التخلي عن كل جهودنا لمحاولة النقل إلى .NET Core <1.x مع صعوبة مواكبة التدفق المستمر للتغييرات المتقطعة ، كان ذلك فقط حتى تمكنا من .NET Core 2.x لدعمها وترحيل التطبيقات الحالية عبر. على الجانب الآخر ، شهد مطورو ASP.NET Framework الحاليون ركودًا في النظام الأساسي الذي اختاروه ثم حل محله نموذج البرمجة الجديد ASP.NET Core ومن خلال توسيع نطاق مهاراتهم / معارفهم الحالية. يؤدي إنهاء الدعم لـ ASP.NET Core على FX إلى القضاء على إستراتيجية الترحيل المرحلية الشائعة نحو .NET Core حيث يخاطرون (بدون احتياطي طارئ) بالعمل على نظام أساسي مهجور ما لم يتمكنوا من ترقية نظامهم بالكامل إلى .NET Core (مخاطرة) التي يمكن أن تمنع محاولات الترحيل من الاعتبار) كما أنها تقضي على فرصتهم في المشاركة في نموذج مطور ASP.NET Core المستقبلي إذا لم يكونوا قادرين على ترحيل أنظمتهم الحالية التي يعملون عليها يوميًا ، مما يؤدي إلى يكون ممكنًا فقط إذا كان يتمتع بنفس الدعم مثل WebForms - والتي آمل أن تظل قيد الدراسة.

لم يذكر أحد: في تطبيقنا الأساسي asp.net ، نحتاج إلى استضافة خدمات WCF وهذه هي نقطة الألم الوحيدة للترحيل من إطار عمل .net. لا أرى أي أخبار حول دعم wcf من جانب الخادم على .net core 3 ، للأسف.

DamianEdwardsdavidfowlnatemcmaster نحن في قارب واحد. تمتلك شركتي عددًا من المنتجات التي تعمل على ASP.Net Core على إطار عمل .Net كامل ، ونحن ندعم هذه المنتجات لفترة أطول بكثير من 3 سنوات ، بسبب بطء الصناعات التي نبيعها في التحركات. إن توسيع LTS لـ .net core 2.2 سيكون بلا معنى في حالتنا لأنه سيتعين علينا نقل تطبيقات ASP.net الأساسية إلى ASP.Net. من المؤكد أن هذا يهزم نقطة الرجال! هل تقترح فقط طلبات الدعم لفترات زمنية أقصر؟ لسوء الحظ ، هذا أيضًا شيء لا نتحكم فيه. يمكن أن تستغرق الصناعات التي نعمل فيها عامًا لمجرد طرح برنامجنا الجديد.

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

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

أود حقًا الحصول على رد من فريق .net على هذا.

davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

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

أليست هذه الحجة تعمل في الاتجاه المعاكس؟

ما لا أستطيع فهمه هو ما يمنعك فعليًا من هندسة الطبقات المناسبة لـ ASP.NET Core؟
لذا ، نعم ، بعض ميزات وقت التشغيل غير متوفرة في .Net Framework ، مثل Span<T> ، لكن هذا لا يعني أنه غير متوفر على الإطلاق. إنه متوفر ، إنه ليس بنفس الأداء كما هو الحال في .Net core. يمكننا التعامل مع ذلك.

يمكن تنفيذ بعض التطبيقات منخفضة المستوى في أشكال مختلفة لـ .net الأساسية على وجه التحديد ومعيار صافي. وأشك في أن هناك متسعًا كبيرًا لذلك ، لأن واجهات برمجة التطبيقات عادة ما تكون متاحة كحزم NuGet.
يدعم العديد من مؤلفي المكتبات تطبيقات مختلفة لمنصات مختلفة ، وهذا ما كان دائمًا.

هل يمكنك توضيح ما الذي يمنعك بالضبط من دعم .Net Framework / .Net Standard. بعض الأمثلة البسيطة على ما لا يمكن استخراجه للحصول على تطبيقات خاصة بالمنصة؟

يمنعك من دعم .Net Framework / .Net Standard. بعض الأمثلة البسيطة على ما لا يمكن استخراجه للحصول على تطبيقات خاصة بالمنصة؟

خارج الجزء العلوي من رأسي ، العناصر التي تتطلب وقت التشغيل أو تغييرات الإطار

• مؤشرات GC الداخلية ؛ لذا فإن إنشاء امتداد آمن من مرجع فقط بدون كائن: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• تطبيقات الواجهة الافتراضية
• عناصر العمل المخصصة Threadpool
• تمتد الأحمال الزائدة على الأنواع الأساسية: تيار ، مآخذ ، TextReader / TextWriter ، WebSockets
• IAsyncDisposable الزائدة على الأنواع الأساسية: Stream ، Sockets ، TextReader / TextWriter ، WebSockets ، إلخ.
• IAsyncEnumeratorالأحمال الزائدة على الأنواع الأساسية: Stream ، Sockets ، TextReader / TextWriter ، WebSockets ، إلخ.

بنود المكافأة

• مكونات الأجهزة (x86 ، x64 ، ARM)
• تحليل الهروب (تخصيصات جديدة للمكدس)
• إصدارات وقت التشغيل جنبًا إلى جنب
• إصلاح عمليات إعادة توجيه الربط وتعيين الإصدار

لا أفهم لماذا لا يمكننا فقط الحصول على إصدار قياسي لم يعد يدعم netframework. تمامًا مثل هاتف windows لا يحتوي على دعم قياسي يتجاوز 1.2. لماذا لا يمكننا نقل المعيار إلى الأمام والسماح بالتطبيقات مثل netcore و mono و xamarin وما إلى ذلك في النهاية أو عدم مطابقتها أبدًا. ثم يعود الأمر إلى صانع المكتبة ليقرر أي إصدار قياسي يريد تنفيذه من أجل زيادة التغطية.

هذا التغيير يجعله بحيث لم يعد بإمكان xamarin و mono استخدام aspnetcore. إنها تجعلها مجبرة على إنشاء مكتبة لاستهداف كل من netcore و netstandard أو ما هو أسوأ من ذلك مع التخلي عن netstandard معًا واستهداف netcore فقط.

سيؤدي هذا في النهاية إلى وفاة معيار الشبكة.

يمنعك من دعم .Net Framework / .Net Standard. بعض الأمثلة البسيطة على ما لا يمكن استخراجه للحصول على تطبيقات خاصة بالمنصة؟

خارج الجزء العلوي من رأسي ، العناصر التي تتطلب وقت التشغيل أو تغييرات الإطار

• مؤشرات GC الداخلية ؛ لذا فإن إنشاء امتداد آمن من مرجع فقط بدون كائن: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• تطبيقات الواجهة الافتراضية
• عناصر العمل المخصصة Threadpool
• تمتد الأحمال الزائدة على الأنواع الأساسية: تيار ، مآخذ ، TextReader / TextWriter ، WebSockets
• IAsyncDisposable الزائدة على الأنواع الأساسية: Stream ، Sockets ، TextReader / TextWriter ، WebSockets ، إلخ.
• IAsyncEnumerator الزائد على الأنواع الأساسية: Stream ، Sockets ، TextReader / TextWriter ، WebSockets ، إلخ.

بنود المكافأة

• مكونات الأجهزة (x86 ، x64 ، ARM)
• تحليل الهروب (تخصيصات جديدة للمكدس)
• إصدارات وقت التشغيل جنبًا إلى جنب
• إصلاح عمليات إعادة توجيه الربط وتعيين الإصدار

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

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

في الوقت نفسه ، لا يبدو أن Microsoft ترغب في المضي قدمًا بإصدار .NET Standard غير متوافق إلى الأبد مع .NET Framework. وإلا فلن تكون هذه مشكلة - فقط ادفع للأمام باستخدام netstandard30 أو netstandard40 وقم بإسقاط دعم Framework ؛ وامتلاك .NET Core يستهدف أحد تلك المعايير الأحدث.

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

في الوقت نفسه ، لا يبدو أن Microsoft ترغب في المضي قدمًا بإصدار .NET Standard غير متوافق إلى الأبد مع .NET Framework.

هذا مخادع. يتم الانتهاء من .NET Standard 2.1 ولديه 3104 واجهة برمجة تطبيقات Span التحميلات الزائدة على أنواع إطار العمل الأساسي ؛ مما قد يجعله غير متوافق مع .NET Framework.

NET Standard لا يزال يتقدم.

وإلا فلن تكون هذه مشكلة حقًا - ما عليك سوى المضي قدمًا مع netstandard30 أو netstandard40 وإسقاط دعم Framework ؛ وامتلاك .NET Core يستهدف أحد تلك المعايير الأحدث.

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

هل ستدعم مجموعات الألعاب المتعددة في Mono و Unity المؤشرات الداخلية قريبًا؟ إذا لم تتم إضافتهم إلى .NET Standard ، فسيتم حظرهم من .NET Standard أي معيار .NET مستقبلي حتى يتم تغيير GCs للتعامل معهم. ومع ذلك؛ من الأفضل إضافة واجهات برمجة التطبيقات التي يمكنهم تنفيذها الآن وحفظ تلك التي لا يمكنهم استخدامها لمعيار مستقبلي.

هل يتم إضافة واجهات برمجة التطبيقات إلى Core وهي واجهة برمجة التطبيقات الصحيحة ليتم إصلاحها بشكل دائم إلى الأبد وإجبارها في كل وقت تشغيل ؛ التي تريد أن تكون متوافقة مع المعيار التالي ، لتنفيذ؟

تم تغيير بعض Core 2.1 apis بين المعاينة 1 والمعاينة 2 (بسبب ملاحظات الاستخدام) ؛ لذلك من الصعب معرفة ما هو Apis الجديد في Core X حتى يتم إصداره عند هذه النقطة. ثم أي منها هي المجموعة الصحيحة لإضافتها إلى المعيار لجميع أوقات التشغيل للتنفيذ (أو تركها في الخلف).

لا يزال نهج .NET Standard أكثر صرامة من معايير المتصفح عندما يجب أن يقوم مستعرضان بتنفيذ الميزة قبل قبول المعيار.

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

السؤال الأساسي هو هل يمكن لـ ASP.NET Core استخدام واجهات برمجة التطبيقات التي طلبها وشحنها في إصدار .NET Core المرفق معها (حيث يتم شحنها في نفس الوقت) ؛ أو هل يمكنه فقط استخدام واجهات برمجة التطبيقات التي تم شحنها في الإصدار السابق من .NET Core - والتي من المحتمل أن تكون في الإصدار .NET Standard لـ NET Core هذا؟ (نظرًا لأن إصدارات .NET القياسية تبدو متخلفة في إصدار apis 1 عن .NET Core حاليًا ؛ باستخدام حجم العينة 1)

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

لا أحد يريد تسريع CLR لإصدار جديد لإحضار تطبيقات الواجهة الافتراضية إلى .NET Framework.

NET Core من خلال دعم أحمال عمل .NET Framework التقليدية (بما في ذلك WinForms و WPF) هي في الأساس مراجعة لـ CLR ؛ ولكن بطريقة أكثر استدامة وإثباتًا في المستقبل؟

هذا مخادع. يتم الآن الانتهاء من .NET Standard 2.1 ولديه 3104 واجهة برمجة تطبيقات جديدة على .NET Standard 2.0 ، بما في ذلك التحميل الزائد Span على أنواع إطارات العمل الأساسية ؛ مما قد يجعله غير متوافق مع .NET Framework.

بما في ذلك .NET Framework 4.8 و .NET Framework 4.9؟

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

NET Core من خلال دعم أحمال عمل .NET Framework التقليدية (بما في ذلك WinForms و WPF) هي في الأساس مراجعة لـ CLR ؛ ولكن بطريقة أكثر استدامة وإثباتًا في المستقبل؟

وليس عكسيا. بقدر ما عرضت Microsoft أشياء مثل Paint.Net التي تعمل على .NET Core ، لا يمكنني تشغيل مشاريعي الحالية من جانب الخادم على .NET Core ، ولا يستطيع معظم الأشخاص تشغيلها.

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

قد لا يكون هذا عمليًا أيضًا ، لكنني أعتقد أن الناس سيكونون أكثر سعادة بشكل عام إذا كان هناك إصداران من ASP.NET Core:

• إصدار سريع الحركة مرتبط بـ .NET _Core_ ويمكنه استخدام أي واجهة برمجة تطبيقات جديدة يرغب فيها.
• إصدار LTS بطيء الحركة مرتبط بـ .NET _Standard_ ويعمل في أماكن أكثر ؛ والتي تلحق في النهاية ببنيات حافة النزيف القديمة ولكنها تتخلف دائمًا.

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

• إصدار سريع الحركة مرتبط بـ .NET Core ويمكنه استخدام أي واجهة برمجة تطبيقات جديدة يرغبها.
• إصدار LTS بطيء الحركة مرتبط بـ .NET Standard ويعمل في أماكن أكثر ؛ والتي تلحق في النهاية ببنيات حافة النزيف القديمة ولكنها تتخلف دائمًا.

لذلك إذا ظهر ASP.NET Core 3.0 كـ .NET Core 3.0 فقط ؛ ولكن في وقت لاحق عندما كان لديهم NET Standard يحتوي على apis ؛ تم إصدار حزم لـ ASP.NET Core 3.x والتي كانت .NET Standard أيضًا (حتى لو انتقل ASP.NET Core إلى 4.0) ؛ هل هذا يلبي متطلباتك؟

@ yaakov- ح

إصدار LTS بطيء الحركة مرتبط بـ .NET Standard ويعمل في أماكن أكثر ؛ والتي تلحق في النهاية ببنيات حافة النزيف القديمة ولكنها تتخلف دائمًا.

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

يمكنك دائمًا استخدام ASP.NET Core 2.1 مع الدعم الموسع الذي

لا تقسم المجتمع من فضلك !!
(على أساس التصويت) هل تتوقع بقاء 1/3 مطور في asp.net core 2.1؟ أو تتوقع 2/3 من المطورين الذين ينشئون حزم nuget التي يتعين عليها الحفاظ على نسختين من مكتبتهم؟

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

لذلك إذا ظهر ASP.NET Core 3.0 كـ .NET Core 3.0 فقط ؛ ولكن في وقت لاحق عندما كان لديهم NET Standard يحتوي على apis ؛ تم إصدار حزم لـ ASP.NET Core 3.x والتي كانت .NET Standard أيضًا (حتى لو انتقل ASP.NET Core إلى 4.0) ؛ هل هذا يلبي متطلباتك؟

على وجه التحديد.

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

يمكنك دائمًا استخدام ASP.NET Core 2.1 مع الدعم الموسع الذي ذكره DamianEdwards . أعتقد أنه حتى لو كان هذا الدعم لمدة 10 سنوات ، فإنه لن يرضي الأشخاص الذين يشتكون.

يبدو أن هناك رسائل متضاربة هنا:

1. لا بأس بالبقاء على الإصدار 2.1 ، إصدار LTS الأقدم
2. يتحرك ASP.NET Core بسرعة كبيرة بحيث لا يمكننا حتى انتظار دورة إصدار واحدة بين .NET Core و .NET Standard التالي.

أعتقد أن (2) يسبب الكثير من الارتباك والخوف من التخلف عن الركب.

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

(على أساس التصويت) هل تتوقع بقاء 1/3 مطور في asp.net core 2.1؟ أو تتوقع 2/3 من المطورين الذين ينشئون حزم nuget التي يتعين عليها الحفاظ على نسختين من مكتبتهم؟

أتوقع من مؤلفي المكتبة أن يقرروا ما هو الإصدار الأدنى من ASP.NET Core الذي يهتمون بدعمه ويستهدفونه. هذا ما يفعلونه بالفعل اليوم. تدعم بعض المكتبات ASP.NET Core 1.x و 2.x البعض يدعم 2.x. هذا لا يختلف.

@ yaakov- ح

لا أفهم تمامًا ما هي الرسائل المتضاربة. الإصدار 2.1 الحالي هو LTS ويعمل على .NET Core و .NET Framework وهو مدعوم لمدة 3 سنوات. هذه ليست رسالة جديدة ، إنها نفس الرسالة التي تلقيناها منذ البداية.

يتحرك ASP.NET Core بسرعة كبيرة بحيث لا يمكننا حتى انتظار دورة إصدار واحدة بين .NET Core و .NET Standard التالي.

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

أي رد على هذا من فريق ms؟

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

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

أود حقًا الحصول على رد من فريق .net على هذا.

لسوء الحظ ، هذا يعني أن أي شخص يعمل في عمليات النشر المحلية لا يزال ، لا يمكنه دعم برامجهم لمدة تزيد عن 3 سنوات

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

schmitch لست متأكدًا مما

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

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

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

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

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

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

تم تطوير ASP.NET Core 2.1 بالفعل ، والجهود المبذولة لتشغيل ASP.NET Core على FX / .NET Core هي تكلفة باهظة تم استثمارها بالفعل. لذلك يجب أن يتم تأطير القرار على أنه مسألة موارد MS للحفاظ على منصة مطورة بالفعل (بعد LTS) مقابل المبلغ التراكمي للتكلفة وسوء النية والقصور الذاتي الناتج عن التخلي عن منصة شائعة.

لست متأكدًا من فهمي لما يُطلب بعد ذلك. لم تتغير دورة حياة LTS منذ إصدار 2.1. إذا كتبت تطبيقًا على إصدار LTS سواء كان .NET Core أو .NET Framework ، فستستغرق 3 سنوات حتى تصبح "غير مدعوم". أنا لا أفهم تمامًا كيف يتم سحب البساط من تحتك من حيث الدعم ، فهذا لم يتغير. ستحتاج إلى الترقية للحصول على أي تحديثات للنظام الأساسي.

أدرك الآن أن 2.1 كونه آخر إصدار LTS مدعوم على .NET Framework يعني أنه لا يوجد مكان للترقية إليه ، ولكن هذا هو المكان الذي يأتي فيه دعم LTS الممتد. إذا كان التطبيق لا يمكنه الانتقال إلى .NET Core

لست متأكدًا من فهمي لما يُطلب بعد ذلك.

يتطلب هذا الخيط مستويات مختلفة من الالتزامات من MS تتراوح من: الاستمرار في تطويره جنبًا إلى جنب مع .NET Core ، وتطويره على "قطار بطيء" ، وعدم التخلي عن ASP.NET Core 2.1 والحفاظ على نفس مستوى الدعم مثل WebForms ، وتوسيع LTS . أفضل عدم التخلي عنه كخيار استضافة لـ ASP.NET Core (تحرير: obv أي شيء أعلاه سيكون أكثر تفضيلاً) والذي لن يعيق NET Core فقط v3 + مع توفير الكثير من المرافق لـ .NET الموجودة استثمارات العملات الأجنبية.

أدرك الآن أن 2.1 كونه آخر إصدار LTS مدعوم على .NET Framework يعني أنه لا يوجد مكان للترقية إليه

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

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

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

في عالم مثالي ، سيكون الجميع على .NET Core ولكن هناك قدرًا كبيرًا من الاستثمار في .NET FX والذي تم تخفيض قيمته بهذا القرار.

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

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

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

شكرًا لقتل NET Standard بهذا النوع من القرارات.

حتى الآن كنا نتجاهل NET Core لأن هناك الكثير من تجميعات الأطراف الثالثة التي لا تستهدف Core بعد.

العديد من البائعين الراغبين في دعم Core ، يفعلون ذلك في منتصف الطريق ، مثل Managed ODP.NET بدون واجهات برمجة التطبيقات الأصلية التي لا تتوفر إلا على .NET Framework.

ثم تأتي بهذا النوع من القرارات.

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

davidfowl يمكنني أن أعطيك مثالين لما يجعل من الصعب الترحيل إلى .NET Core - WCF (تستخدمه العديد من تطبيقات المؤسسات الحالية ، وأعتقد أن الآخرين أثاروا هذه المشكلة بالفعل) ، ونقص مكتبة Adomd في .NET Core / NET قياسي (للتواصل مع SSAS ، المستخدم أيضًا في تطبيقات المؤسسات ، والذي يتم تعقبه في SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). يجب إصلاح بعض (winforms) الأخرى باستخدام حزمة توافق .net core 3 (yay!) - علينا أن ننتظر ونرى كيف تعمل بالفعل.

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

يتطلب هذا الخيط مستويات مختلفة من الالتزامات من MS تتراوح من: الاستمرار في تطويره جنبًا إلى جنب مع .NET Core ، وتطويره على "قطار بطيء" ، وعدم التخلي عن ASP.NET Core 2.1 والحفاظ على نفس مستوى الدعم مثل WebForms ، وتوسيع LTS . أفضل عدم التخلي عنه كخيار استضافة لـ ASP.NET Core والذي لن يعيق NET Core فقط v3 + مع توفير الكثير من الفوائد لاستثمارات .NET FX الحالية.

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

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

هذا شائع جدًا (حتى داخل Microsoft) ولهذا أضفنا هذه القدرة على الرجوع إلى .NET Framework dlls في .NET Core 2.0 لأنه اتضح أن معظم التجميعات متوافقة حتى لو لم يتم تجميعها لـ .NET Core. الآن هناك بعض الأشياء التي لن تعمل أبدًا (مثل AppDomains ...) لكنني أتوقع مع إضافة المزيد من سطح API ، فإن مجموعة المكتبات التي لا تعمل فقط ستتقلص إلى عدد ضئيل.

pjmlp

لا أرى كيف يقتل هذا .NET Standard. يعد .NET Standard أكبر من ASP.NET Core. يتعلق الأمر بإنشاء مكتبات مشتركة قابلة لإعادة الاستخدام (مثل Microsoft.Extensions *) تعمل على أي نظام أساسي يدعم .NET.

حتى الآن كنا نتجاهل NET Core لأن هناك الكثير من تجميعات الأطراف الثالثة التي لا تستهدف Core بعد.

اي واحدة؟ هل يتوفر الدعم لمن هم في الطريق أم أن هذه التجميعات لن تدعم NET Core أبدًا؟

العديد من البائعين الراغبين في دعم Core ، يفعلون ذلك في منتصف الطريق ، مثل Managed ODP.NET بدون واجهات برمجة التطبيقات الأصلية التي لا تتوفر إلا على .NET Framework.

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

voltcode شكرا على ردود الفعل الملموسة! نتوقع أن تختفي بعض هذه الأنواع من مشكلات التوافق أو تكون في حدها الأدنى بمرور الوقت الذي ندعم فيه مشروعات .NET Core اليوم (3 سنوات أو نحو ذلك).

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

....

حتى الآن كنا نتجاهل NET Core لأن هناك الكثير من تجميعات الأطراف الثالثة التي لا تستهدف Core بعد.

اي واحدة؟ هل يتوفر الدعم لمن هم في الطريق أم أن هذه التجميعات لن تدعم NET Core أبدًا؟

في حالتنا ، فإن ODP.NET هو الأمر الواضح ، حيث أن Oracle لا تنقل 100٪ من ميزات برنامج التشغيل إلى Core.

العديد من البائعين الراغبين في دعم Core ، يفعلون ذلك في منتصف الطريق ، مثل Managed ODP.NET بدون واجهات برمجة التطبيقات الأصلية التي لا تتوفر إلا على .NET Framework.

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

هذا ليس عدد عملائنا الذين يرون ذلك بالرغم من ذلك.

فقط لكي تشعر كيف يؤثر هذا النوع من القرارات على مستقبل .NET ، في مشروع حديث ، دفع العميل جهود التطوير لنقل تطبيق من .NET Framework إلى Java لنشر UNIX ، لأنه لم يكن على استعداد لذلك راهن على .NET Core وتطبيق ODP.NET المعطل ، بينما يوفر برنامج تشغيل JDBC ميزة تكافؤ 1: 1 مع برنامج تشغيل .NET Framework ODP.NET.

قد يختار الآخرون مجموعات بديلة أخرى أيضًا.

هناك الكثير من التبعيات التي لا يمكن ولا يمكن نقلها في تطبيق مؤسستك العادي.

ظهرت هذه المشكلة على قمة HN. قد ترغبون يا رفاق (MSFT) في التحقق هناك أيضًا. ساعة واحدة فقط و بالفعل أكثر من 50 تعليقًا.

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

لا أرى كيف يقتل هذا .NET Standard. يعد .NET Standard أكبر من ASP.NET Core. يتعلق الأمر بإنشاء مكتبات مشتركة قابلة لإعادة الاستخدام (مثل Microsoft.Extensions *) تعمل على أي نظام أساسي يدعم .NET.

لا أفهم ما هو ASP.NET Core إذا لم يكن مكتبة مشتركة قابلة لإعادة الاستخدام؟ إذا كان اتجاه المكتبات إلى أن تكون حديثة وسريعة هو إسقاط دعم .NET Standard ، فهذه رسالة صعبة. هل يجب على Newtonsoft.Json التبديل إلى .NET Core 3 فقط ، إذا كان بإمكانه العمل بشكل أسرع كثيرًا؟ هل يجب استخدام Autofac؟

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

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

لقد كان AspNetCore مذهلاً بالنسبة لمكدسنا من حيث الاستضافة الذاتية (http.sys) لواجهة برمجة تطبيقات الويب ومحتوى الويب الثابت حول الخدمات المختلفة. لقد جئنا من نانسي والتي كانت قوية ، ولكن كان لدينا أيضًا العديد من العيوب من وجهة نظرنا ، لذلك انتقلنا إلى AspNetCore منذ حوالي عام. اليوم ، نقوم بتشغيل كل واحد من قواعدنا البرمجية على 2.x. في كثير من الحالات ، سنكون على ما يرام تمامًا بالانتقال إلى هدف .NET Core خالص. ولكن ، هناك أيضًا العديد من الخدمات التي أنشأناها للاستفادة من AspNetCore والتي تعتمد أيضًا على أشياء مثل System.DirectoryServices و System.Drawing . من منظور هذه الخدمات ، سنقوم بتغيير تقنية استضافة الويب قبل أن نخرج من .Net Framework. لسوء الحظ ، نظرًا لتعقيدات إدارة تقنيتين مختلفتين لاستضافة الويب في وقت واحد وحجم فريقنا ، فمن المحتمل أيضًا أن نفرض على AspNetCore من بقية خدماتنا تمامًا لصالح شيء أكثر توافقًا عبر كلا الهدفين

لوضعها قريبًا - هذا القرار سيجبرنا على الخروج تمامًا من AspNetCore في وقت ما في المستقبل (على الأرجح عندما تنتهي صلاحية LTS لـ 2.x) ، لما لا أعرفه الآن. إذا كان الأمر يتعلق بذلك ، فسنقوم على الأرجح بكتابة حل داخلي خاص بنا لاستبدال AspNetCore ، نظرًا لأن حالات الاستخدام الخاصة بنا من حيث العدد الفعلي لميزات AspNetCore المستخدمة ضيقة جدًا (ومع ذلك ، فإن الميزات التي نقدمها _توفرها _ قيمة مضافة ضخمة لنا اليوم).

قد يختار الآخرون مجموعات بديلة أخرى أيضًا.

هذا عادل ، لكن المداخن البديلة لها نفس سياسة الدعم. انتقلت Java إلى نموذج LTS مشابه (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

هناك الكثير من التبعيات التي لا يمكن ولا يمكن نقلها في تطبيق مؤسستك العادي.

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

إنه إطار عمل وليس مكتبة. إنه مكون من مجموعة كبيرة جدًا من المكتبات التي يتم تجميعها معًا.

لا أفهم ما هو ASP.NET Core إذا لم يكن مكتبة مشتركة قابلة لإعادة الاستخدام؟ إذا كان اتجاه المكتبات إلى أن تكون حديثة وسريعة هو إسقاط دعم .NET Standard ، فهذه رسالة صعبة. هل يجب على Newtonsoft.Json التبديل إلى .NET Core 3 فقط ، إذا كان بإمكانه العمل بشكل أسرع كثيرًا؟ هل يجب استخدام Autofac؟

لا أرى مدى صعوبة الأمر. أنا متأكد بنسبة 97٪ من أن هذه المكتبات لن تزيل الأطر لأن عملائها سيشتكون. يعتبر الشريط مرتفعًا للغاية لإزالة الإطارات وهو نفس السبب الذي جعلنا نحافظ على Microsoft.Extensions. * على .NET Standard 2.0. أوافق على أن الأمر سيكون غامضًا إذا نقلنا كل شيء إلى هناك ولكن هذا ليس ما يحدث هنا.

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

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

ولكن ، هناك أيضًا العديد من الخدمات التي أنشأناها للاستفادة من AspNetCore والتي تعتمد أيضًا على أشياء مثل System.DirectoryServices and System.

هذه موجودة في حزمة Windows المدمجة على .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

لوضعها قريبًا - هذا القرار سيجبرنا على الخروج تمامًا من AspNetCore في وقت ما في المستقبل (على الأرجح عندما تنتهي صلاحية LTS لـ 2.x) ، لما لا أعرفه الآن. إذا كان الأمر يتعلق بذلك ، فسنقوم على الأرجح بكتابة حل داخلي خاص بنا لاستبدال AspNetCore ، نظرًا لأن حالات الاستخدام الخاصة بنا من حيث العدد الفعلي لميزات AspNetCore المستخدمة ضيقة جدًا (ومع ذلك ، فإن الميزات التي نقدمها توفر الرافعة المالية قيمة مضافة ضخمة لنا اليوم).

هل سيكون هذا هو الحال أيضًا إذا تم تقديم الدعم؟

بالإضافة إلى ذلك ، يتعين علينا الآن قطع جميع التقنيات الأخرى غير المدعومة (AppDomains ، Remote ، إلخ) أولاً ، بدلاً من أن نكون قادرين على القيام بهذا العمل بالتوازي أو في مرحلة لاحقة.

لماذا لا يمكنك الهجرة إلى 2.1 أولاً؟

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

أكبر سبب للتردد هو أن حد الدعم لمدة 3 سنوات يعني أنه لا يمكنك البقاء.

بالتأكيد ، لهذا السبب نقدم دعمًا ممتدًا كما ذكر

فقط لإظهار مقدار العواقب التي يخلقها هذا القرار - ماذا عن Blazor؟ هل سيتوقف عن الاعتماد على معيار الشبكة؟ هل يجب أن نتوقع ذلك أيضًا؟ يتم الإعلان عن Blazor باعتباره الشيء الكبير التالي. ماذا أيضًا من github.com/aspnet الذي يعتمد حاليًا على netstandard ، هل سيتخلى عنه وينتقل إلى net core في الإصدار الرئيسي التالي؟ ما هي الخطط لأشياء أخرى ، في سيطرة MSFT ولكن خارج aspnet repo التي ستشارك في مصير aspnetcore؟

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

قد يختار الآخرون مجموعات بديلة أخرى أيضًا.

هذا عادل ، لكن المداخن البديلة لها نفس سياسة الدعم. انتقلت Java إلى نموذج LTS مشابه (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

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

لما يستحق ، أعمل حاليًا على نشر أول تطبيق أساسي لشركتي ASP.Net. لدينا استثمار ضخم حقًا في .NET Framework ، لذلك كان استخدام ASP.Net Core على .NET Framework بدلاً من .NET Core هو الأسلوب الواضح.

الآن أتساءل عما إذا كنت سأهيئنا للكثير من الألم لاحقًا.

هناك الكثير من المخاوف المترابطة هنا. أنت تقول أن ASP.Net core لم يكن المقصود منه تشغيله على .NET Framework فقط. فشلت رسائل Microsoft حول ASP.Net Core في الماضي في توضيح ذلك بشكل فائق.

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

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

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

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

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

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

لذلك أصبح هذا في الأساس صخبًا ، لكنني آمل أن يوضح هذا بشكل أفضل مخاوف العديد من المطورين.

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

ولكن ، هناك أيضًا العديد من الخدمات التي أنشأناها للاستفادة من AspNetCore والتي تعتمد أيضًا على أشياء مثل System.DirectoryServices and System.

هذه موجودة في حزمة Windows المدمجة على .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

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

هل سيكون هذا هو الحال أيضًا إذا تم تقديم الدعم؟

فيما يتعلق بالدعم - أشعر كما لو أن LTS من 2.x حتى عام 2021 معقول ، مع الأخذ في الاعتبار جميع القيود الأخرى المرتبطة بشيء بعيد المدى.

بناءً على ما أفهمه الآن ، من المحتمل أن نشعر بالراحة عند الترقية إلى AspNetCore 3.x بمجرد أن تتاح لنا فرصة مراجعة وتحويل مشاريع .NET Framework إلى مشاريع .NET Core (مع استخدام حزمة التوافق كما هو مطلوب).

شكرا لكم لمتابعة الخاص بك.

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

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

هناك نظام بيئي ضخم من المكتبات التجارية الناضجة للغاية والتي للأسف تبعيات على System.Drawing و GDI وأحيانًا التسجيل (!). إذا كان هؤلاء سيعملون الآن فقط مع 2.1 ويتم دعمهم لمدة ثلاث سنوات فقط ، فهذه مشكلة يمكن أن توقف اعتماد Core في بعض المؤسسات.

يقوم .NET Core بعمل دائرة كاملة للوصول إلى نقطة البداية.

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

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

لم يكن من المفترض أن يكون ASP.NET Core الذي يعمل على .NET Framework شيئًا دائمًا ، بل كان من المفترض دائمًا أن يكون نقطة انطلاق

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

تحتوي الصورة المعروفة جدًا "لا توجد خطط لإزالة الدعم لاستهداف .NET Framework في ASP.NET Core."

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

حتى أنه يسمى ASP.NET Core

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

وهنا يأتي دور دعم LTS الممتد. إذا كان التطبيق لا يمكنه الانتقال إلى .NET Core أبدًا حتى بعد هذه السنوات الست [...]

من أين جاء هذا من الآن؟ في المرة الأخيرة ، كانت الرسالة لا تزال "نحن نحقق في عرض LTS" للدعم الموسع " . هل هذا شيء حقيقي الآن ولدينا 6 سنوات؟

pjmlp

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

نقطة عادلة ، لكنني لا أفهم ما علاقة ذلك بدعم أفضل. تم الادعاء بأن التبديل إلى Java سيكون أفضل بسبب المكتبات الأقل تعطلًا (وهي نقطة في الوقت المناسب) ودعم المؤسسة (دورة دعم أطول).

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

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

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

راجع https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

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

نعم ، إنه متوافق مع النظام الثنائي.

هناك نظام بيئي ضخم من المكتبات التجارية الناضجة للغاية والتي للأسف تبعيات على System.Drawing و GDI وأحيانًا التسجيل (!). إذا كان هؤلاء سيعملون الآن فقط مع 2.1 ويتم دعمهم لمدة ثلاث سنوات فقط ، فهذه مشكلة يمكن أن توقف اعتماد Core في بعض المؤسسات

كما ذكرت عدة مرات في هذا الموضوع. أضفنا القدرة على الإشارة مباشرة إلى التبعيات المترجمة مقابل .NET Framework في مشاريع .NET Core.

poke أنت محق بشأن الرسائل ، لم تكن واضحة على الإطلاق ، خطأي.

من أين جاء هذا من الآن؟ آخر مرة ، كانت الرسالة لا تزال "نحن نحقق في عرض LTS" للدعم الموسع ". هل هذا شيء حقيقي الآن ولدينا 6 سنوات؟

لقد صنعت 6 ، لا أعرف كيف سيكون الدعم الممتد عندما نقدمه.

كان NET Core دائمًا يحل محل .NET Framework (في الأصل كان .NET Framework 5) ، لكن إعادة الكتابة كانت طموحة جدًا لدرجة أنها تستخدم الآن لدعم تطبيقات سطح المكتب.

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

تعليق

edandersen هل قمت بتشغيل ApiPort على dlls الخارجية هذه؟ سيُظهر لك ما إذا كانوا يستخدمون أي واجهات برمجة تطبيقات غير متوفرة على .NET Core. إذا كان يستخدم فقط واجهات برمجة التطبيقات المتاحة ، فلن تكون مشكلة ، وإلا فإن معرفة واجهات برمجة التطبيقات المفقودة يساعد في المناقشة وتحديد أولويات الميزات.
توفر حزمة توافق Windows بالفعل وظائف لـ system.drawing والتسجيل. هل حاولت تشغيل هذه الأشياء على .NET Core بالفعل؟ النظام: الرسم يعمل حتى على * لا شىء باستخدام mono libgdiplus. هذا يسمح لنا باستخدام ClosedXML على أنظمة غير Windows للعمل مع ملفات Excel.

أكبر اعتماد على .NET Framework للتطبيقات "الحديثة" في شركتنا هو وظيفة WCF.
يتم تحسين مكتبات العميل .NET Core WCF. لم أتحقق من الحالة الحالية لمدى جودة عملها مع بعض الخدمات التي نستهلكها ولكن في الماضي ، لم نتمكن من التحدث إلى بعض الخدمات. لكن الوظيفة المفقودة كانت موجودة بالفعل في قائمة المشكلات الخاصة بهم. من ناحية أخرى ، تعمل الخدمات البسيطة بشكل جيد!
من ناحية أخرى ، لا يوجد بديل "انخفاض" لاستضافة خدمات SOAP في .NET Core. سيؤدي ذلك إلى حظر ترحيل بعض التطبيقات إلى .NET Core (ولكن كما ذكرنا - ليست هناك حاجة لذلك).
بالنسبة لتطبيق ASP.NET Core حديث ، أنشأنا تطبيق ويب وكيل ASP.NET إضافيًا يستضيف فقط خدمة WCF ثم يعيد التوجيه إلى تطبيق ASP.NET Core عبر HTTP / JSON. ليست جميلة جدًا وتضيف تعقيدًا للنشر ولكنها تسمح ببعض نقاط التكامل.

أنا لا أقول أنني أريد حقًا إمكانية استضافة WCF في .NET Core ، نظرًا لأنني أصاب بالصداع في تكوينه. بعض الخيارات لاستضافة خدمات SOAP وإنشاء WSDL سيكون رائعًا. لقد رأيت بعض مكتبات OSS تحاول فعل ذلك بالفعل. ربما هذا سيكون كافيا

@ davidfowl

نقطة عادلة ، لكنني لا أفهم ما علاقة ذلك بدعم أفضل. تم الادعاء بأن التبديل إلى Java سيكون أفضل بسبب المكتبات الأقل تعطلًا (وهي نقطة في الوقت المناسب) ودعم المؤسسة (دورة دعم أطول).

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

بدأت العثرات الخاطئة في .NET Framework و .NET Core و Xamarin و .NET Standard تبدو وكأنها الأيام الخوالي لـ WinDev مقابل DevTools ، فقط داخل فرق .NET من أجل التغيير.

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

هذه القرارات لا توحي بالثقة.

هذا حقًا يبدو وكأنه خطأ من جانب فريق .NET ، لا سيما في سياق المناخ الحالي!

بالنسبة لأولئك الذين يذكرون Java ، هل نظرت بالفعل إلى ما يحدث هناك مؤخرًا؟ بين الدعوى القضائية المجنونة تمامًا ضد Google بشأن استخدامه في Android وأحدث خدع الترخيص الخاصة بهم ، يبدو أن سلوك Oracle دائمًا هو سلوك شركة تريد القضاء على منتج غير مرغوب فيه ، بدلاً من شركة تريده أن يزدهر!

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

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

نحن الذين نعمل في كلتا البيئتين نقدر بالفعل عمل Oracle
تم القيام به مع جافا.

هؤلاء هم الذين نادرًا ما يستخدمون Java في الإنتاج ، ويحتقرون Oracle ، هم من يحصلون عليها
خسر في حجج الكراهية ضدهم.

فيما يتعلق بنظام Android ، أؤيد تمامًا الدعوى القضائية ، مثل Google
تمكنت من تفرع منصة Java ، وبالتالي نجحت حيث فشلت Microsoft
مع J ++. ما زلت أتطلع إلى اليوم الذي يضمن فيه أي JAR عشوائي في Maven Central أن يعمل فعليًا على Android.

بالنسبة إلى .NET ، بدأت أشعر بالملل من عمليات إعادة التشغيل المستمرة لـ
كيف من المفترض أن نستهدف منصات Microsoft.

تركت WinRT و UAP و UWP و .NET Native إسقاط F # و XNA و Core 1.0 بالكامل
الكثير من العنب الحامض وهذا القرار الأخير لا يجعل الأمور أفضل
شاملة.

NET هو النظام الأساسي المفضل لدي ، لذا يرجى عدم إفساده أكثر من ذلك.

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

أدرك الآن أن 2.1 كونه آخر إصدار LTS مدعوم على .NET Framework يعني أنه لا يوجد مكان للترقية إليه

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

هذه إحدى النقاط التي لا أفهمها حقًا في المناقشة بأكملها. ما الذي تحصل عليه حقًا من دعم LTS بخلاف إصلاحات الأمان (التي يمكن تغطيتها بدعم LTS الممتد)؟

في دعم LTS السائد ، هناك شيئان فقط يمكن توقعهما:

• إصلاحات أمنية
• إصلاحات الأخطاء الحرجة

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

لنفترض أنه يعلم بالفعل أن الدعم ينتهي في 2018 ، ولا أتوقع أن يبدأ أي شخص مشاريع جديدة في عام 2020 ، لذلك من غير المحتمل أن تجد (imho) خطأً مهمًا في إيقاف العرض بعد عام 2021 (أو 2026 أو المدة التي يقصد بها الدعم الممتد ان نكون).

هذا يترك فقط أخطاء الأمان مفتوحة ، وهو أمر معقول تغطيته بـ LTS.

في الإجابات السابقة ، رأيت ذكر TLS 1.4 وما إلى ذلك ، لن يتم تغطيتها في LTS على أي حال لأن هذه ميزة جديدة على أي حال ، والتي هي نفسها حتى بالنسبة لـ Java (يحتوي Java 6 فقط على دعم TLS 1.0 - TLS 1.1 إذا كنت تحسب في التحديثات غير العامة متاحة فقط لمشتركي دعم Oracle الموسع).

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

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

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

هذا لا يتطلب من مؤلف المكتبة تحديث مكتباته لاستهداف netstandard / netcoreapp.

ربما يكون من المفيد أن تقوم Microsoft بتوسيع صفحة الويب / المكتبة الخاصة بـ NuGet عن طريق ميزة / رابط بجوار كل حزمة nuget على nuget.org والتي تعرض تقريرًا إذا كانت هذه المكتبة تستخدم أي واجهات برمجة تطبيقات غير متوافقة غير متوفرة في إصدارات معينة من .NET Core؟

فمثلا

سيظهر "Company.Example.MyLib"

• NET Core 2.1: دعم جزئي (تقرير مفصل) - حيث يُظهر التقرير التفصيلي أن Apis يعمل وأيها لا يعمل
• NET Core 3.0 :؛ بدعم كامل

يجب أن يكون هذا ممكنًا عن طريق تشغيل .NET Portability Analyzer؟ ستكون المكافأة ، إذا أضافت قائمة من واجهات برمجة التطبيقات العامة التي يمكن استدعاءها بأمان (عن طريق تحليل كود IL ومعرفة واجهات برمجة التطبيقات الأخرى التي تطلبها للتأكد من أنها آمنة أم لا)؟

هذا من شأنه على الأقل أن يسهل على المطورين تحديد ما إذا كانت مكتبة معينة يحتاجون إليها لمشروعهم يمكن تشغيلها على NET Core أم لا حتى إذا لم تستدعيها صراحة؟

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

davidfowlterrajobst من شأنه أن يكون إضافة الممكنة لNuGet؟ لجعل اكتشاف مكتبات .NET Framework المتوافقة مع -NET Core أسهل وأسرع؟

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

هذا بالكاد حجة مع أو ضد دعم .NET Framework أم لا. لن يتمكن الأشخاص العالقون في التبعيات القديمة ولا يمكنهم الترحيل إلى .NET Core (مع حزمة التوافق أو مع مكتبات .NET Framework) من القيام بأيٍّ منهما بعد ذلك. كيف سيغير ذلك أي شيء؟

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

• لا تريد أي منظمة أن تُجبر على الهجرة غير المخطط لها لأن التوجيه الذي اعتمدوا عليه في تحديد الميزانية والتخطيط وقرارات الاستثمار قد تغيرت.

إذا كانت الفوائد تفوق الاستثمارات ، فلماذا لا؟ على سبيل المثال ، إذا كانت هناك ميزات فريدة تمنحك قيمة كبيرة في المقابل أو زيادة هائلة في الأداء.

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

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

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

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

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

pjmlp

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

قد يختار الآخرون مجموعات بديلة أخرى أيضًا.

هذا عادل ، لكن المداخن البديلة لها نفس سياسة الدعم. انتقلت Java إلى نموذج LTS مشابه (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

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

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

على سبيل المثال ، بالنسبة للعديد من المكتبات التي تستخدم واجهات برمجة التطبيقات الداخلية من خلال بعض سحر الانعكاس ، يمكن

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

على الرغم من التغييرات الهائلة التي تم إدخالها في Java 9 ، فإن 100٪ من جميع أطر عمل Java ذات الصلة تعمل عبر Java 9 و 10 و 11 ، وهذا بالتأكيد ليس هو الحال عبر .NET Framework و UWP و Core.

تخيل أنه حتى هناك إطاران رسميان لواجهة المستخدم الرسومية عبر الأنظمة الأساسية ، بينما ما زلنا لا نحصل على خريطة طريق رسمية لـ Core!

pjmlp

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

على الرغم من التغييرات الهائلة التي تم إدخالها في Java 9 ، فإن 100٪ من جميع أطر عمل Java ذات الصلة تعمل عبر Java 9 و 10 و 11 ، وهذا بالتأكيد ليس هو الحال عبر .NET Framework و UWP و Core.

تخيل أنه حتى هناك إطاران رسميان لواجهة المستخدم الرسومية عبر الأنظمة الأساسية ، بينما ما زلنا لا نحصل على خريطة طريق رسمية لـ Core!

آسف ، هذا لا معنى له.

وحدات Java 9 الداخلية ، والتي تمنع الانعكاس في هذه الوحدات ما لم يتم استدعاء --add-opens (وكان من المفترض دائمًا أن يكون iirc حلاً مؤقتًا حتى يستمر الأشخاص في تشغيل تطبيقهم القديم وإزالة بعض الإصدارات لاحقًا).

في حال فاتتك الدراما والقصير عندما كان Java 9 على وشك أن يتم إطلاقه ، كان هذا هو الرد عليها:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

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

بخلاف ذلك ، تم إهمال Java EE 9 المهمل JAX-WS وستتم إزالته في Java EE 11. يمكن اعتبار ذلك تقريبًا على أنه مكافئ لـ WCF. أي استخدام قابل للتطبيق لا يمكن نقله إلى إصدار أحدث ولا بدون استبداله بشيء آخر ، وهي عملية ترحيل. لا يختلف أكثر أو أقل عن الترحيل من ASP.NET Core على .NET Framework إلى ASP.NET Core على .NET Core (أو من ASP.NET إلى ASP.NET Core @ .NET core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

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

أي تطبيق يستخدم واجهات برمجة التطبيقات الداخلية هذه (بما في ذلك كل ما في مساحة الاسم sun.* التي كانت تستخدمها بعض المكتبات القديمة - أو استخدمتها مرة أخرى عندما كان Java 9 على وشك الإصدار) أو يستخدم مكتبة تابعة لجهة خارجية تعتمد على واجهات برمجة التطبيقات هذه أو مكتبة أخرى قد تكون عرضة لهذا التغيير الفاصل. تكمن المشكلة في ذلك ، كما هو الحال في .NET Framework و .NET Core ، في أنك لا ترى من المكتبة وحدها ما يسمى بواجهات برمجة التطبيقات أم لا.

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

الوحدات الداخلية لـ Java 9 ، والتي تمنع الانعكاس في هذه الوحدات ما لم يتم استدعاء --add-opens (وكان من المفترض دائمًا أن يكون iirc حلاً مؤقتًا حتى يتمكن الأشخاص من الاستمرار في تشغيل تطبيقهم القديم وإزالة بعض الإصدارات لاحقًا).

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

بخلاف ذلك ، تم إهمال Java EE 9 المهمل JAX-WS وستتم إزالته في Java EE 11. يمكن اعتبار ذلك تقريبًا على أنه مكافئ لـ WCF.

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

أي تطبيق يستخدم واجهات برمجة التطبيقات الداخلية هذه (بما في ذلك جميع في sun. * مساحة الاسم التي كانت تستخدمها بعض المكتبات القديمة - أو استخدمتها مرة أخرى عندما كان Java 9 على وشك الإصدار) أو يستخدم مكتبة تابعة لجهة خارجية تعتمد على واجهات برمجة التطبيقات هذه أو قد تخضع مكتبة أخرى لهذا التغيير المفاجئ.

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

تم إهمال بعض واجهات برمجة التطبيقات ، لكننا نتحدث عن واجهات برمجة تطبيقات معينة وليس نظام JRE أو نظام Java البيئي بالكامل. إن العمل اللازم للانتقال من واجهات برمجة التطبيقات تلك إلى واجهات برمجة التطبيقات الأحدث والرسمية والموثقة ضئيل بشكل عام.

وكانت Java دائمًا أكثر استعدادًا لكسر التوافق مع الإصدارات السابقة من .NET. على سبيل المثال ، أصبح من غير القانوني الآن في Java التصريح عن نوع باسم var لأنه محجوز للاستدلال المحلي. في Java من غير القانوني تسمية متغير _ لأنه محجوز للاستخدام كحرف متجاهل / بدل. اتخذ C # القرار المعاكس تمامًا في كلتا الحالتين ، باسم الحفاظ على التوافق مع الإصدارات السابقة.

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

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

هذه إحدى النقاط التي لا أفهمها حقًا في المناقشة بأكملها. ما الذي تحصل عليه حقًا من دعم LTS بخلاف إصلاحات الأمان (التي يمكن تغطيتها بدعم LTS الممتد)؟

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

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

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

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

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

حاليًا ، لن يتمكن برنامج MS فقط من تصحيح وإصدار حزم ASP.Core NuGet المحدثة ، مع شجرة التبعيات المترابطة التي تكون OSS لن تساعد كثيرًا هنا ما لم تتم مراجعة 2.1 PR التي يتلقونها (بعد LTS) وقبولها و صدر.

في النهاية بعد مناقشة كل التفاصيل ، فإن السؤال النهائي الذي لا يزال مهمًا هو:

هل يمكننا الاستمرار في تشغيل أنظمتنا الحالية على ASP.Core / FX؟

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

إذا كان ASP.NET Core سيكون NET Core فقط ، فكيف يجب أن نشعر تجاه الشيء .NET Standard بأكمله؟

إذا كانت Microsoft نفسها لا تراهن عليها لأسباب (صحيحة بلا شك) ، فلماذا؟

هل سيكون هناك .NET Core من الدرجة الأولى وحافة متطورة فقط libs و .NET Standard libs "أبسط" وأقل تقدمًا؟

يبدو أن هذا يقتل محرك الأقراص لتحسين أي منصات غير .NET-Core.

آمل أن يظهر لي شخص ما أنني مخطئ وأن يخفف من مخاوفي.

مرحبا،
أرى قيمة المضي قدمًا وأحب ذلك ، لكني أرى 3 مشكلات رئيسية حول هذا القرار:
1) سيكون netstandard مواطنًا من الدرجة الثانية إذا لم يبني أي شخص داخل Microsoft شيئًا صعبًا به ، إذا لم تقم أنت يا رفاق بالتجربة ، كيف يمكنك أن تطلب من مطورين آخرين القيام بذلك؟ يتعين على مؤلفي المكتبات اليوم العمل بجد ، ولن يتحسن الدعم إذا لم يستخدم الأشخاص الداخليون المعيار.
2) هناك قيمة في تشغيل aspnet core في أوقات التشغيل الأخرى.
3) هناك قيمة في البرامج التي تعمل في أوقات التشغيل القديمة (مع التبعية التي لن يتم المساس بها أبدًا) والتي لا ينبغي تجاهلها بسهولة.

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

باستخدام netcore 3.0 ، تقوم بأمرين في وقت واحد: دعم أعباء عمل سطح المكتب و "إخبار ppl على الفور للبقاء على صلة". أعتقد أن هذا سيحتاج إلى قفزة إيمانية من المطورين وهو متفائل للغاية لأن الجميع يعلم أنه لن يتم ترحيل العديد من المشاريع بسبب بعض التبعيات المفقودة ، والتي من المحتمل أن تتم إضافتها في إصدارات 3.1 / 3.2 المستقبلية في 1-2 سنوات ( قريبة جدًا من 3 سنوات LTS من 2.1). في غضون ذلك ، يتم حظر المطورين الذين يريدون أن يكونوا ذوي صلة لاستخدام 3.0 بت بسبب التبعيات التي لا يتحكمون فيها.

هل سيكون من الممكن تأجيل هذا القرار بعد أن تختبره شركته تنوي ورؤية النتائج الحقيقية؟
هل من الممكن أن يتم تجميع نواة aspnet لكل من netstandard و netcoreapp كما تفعل مع مؤلفي المكتبة؟ لا بأس أن يكون لديك أداء متدهور يعمل على .net framework 😄

تعمل Roslyn الآن على .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

هذا بالتأكيد يعتبر شيئا صعبا!

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

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

على سبيل المثال ، انتقل Identity Server بالفعل إلى ASP.Net Core ، وذكر المنشور الأخير حول

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

هل هناك أي فرصة لتغيير سياسة LTS؟ شيء مثل استراتيجية Ubuntu لإصدار LTS كل عامين مع دعم لمدة 5 سنوات - على الرغم من أنني سأطلب 6 للسماح للإصدار الحالي بالحصول على 3+ سنوات من الدعم أثناء العمل على الانتقال إلى الإصدار الجديد.

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

أيضا ، من الغريب كيفية التعامل مع مكتبة .netstandard في. netcore 3.0 مرات.
شعار .netstandard هو "مكتبة واحدة تحكم كل منهم".
قبل هذا ، يبدو أنه يعني كل شيء.
بعد هذا يبدو أنه يعني القليل.

فقط لإظهار مقدار العواقب التي يخلقها هذا القرار - ماذا عن Blazor؟ هل سيتوقف عن الاعتماد على معيار الشبكة؟ هل يجب أن نتوقع ذلك أيضًا؟

يمكن لأي شخص توضيح هذا؟

فهل التوصية للمكتبات مثل Newtonsoft.Json (التي يمكن أن تستفيد من الأداء العالي) للتبديل إلى .NET Core بدلاً من .NET Standard؟ لا أرى الكثير من التمييز بين هذا النوع من المكتبات و ASP.NET Core. لقد قمنا بتضمين خدمات REST في تطبيقات أكبر - يمكن نقل بعضها بسهولة إلى .NET Core والبعض الآخر لا يمكنه ذلك.

حسب فهمي ، فإن التوصية للمكتبات هي استهداف كل من .NET Core 3 و .NET Standard 2.x إذا كنت ترغب في اكتساب مزايا واجهات برمجة التطبيقات الجديدة ولكن لا تريد أن تفقد الجماهير.

حسب فهمي ، فإن التوصية للمكتبات هي استهداف كل من .NET Core 3 و .NET Standard 2.x إذا كنت ترغب في اكتساب مزايا واجهات برمجة التطبيقات الجديدة ولكن لا تريد أن تفقد الجماهير.

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

NET Framework و .NET Core يملآن نفس الدور ، لذلك أعتقد أنه من المتوقع جدًا ألا يعمل ASP.NET Core على .NET Framework يومًا ما ، سواء الآن أو لاحقًا.

ومع ذلك ، أرى مشكلة كبيرة في عدم التشغيل على .NET Standard X . لأكون صادقًا ، لا أحتاج إلى asp.net الأساسية للعمل على xamarin أو الوحدة ، ولكن من الجيد أن تكون قادرًا على القول إنه يمكن - إنها مجرد مجموعة أخرى من المكتبات التي تعمل على منصة .NET. من خلال الانقطاع ، نحصل على تكامل أكثر إحكامًا بين .NET Core و ASP.NET Core وأنا خائف من .NET Core 4.5 ، فإننا ندين Microsoft.AspNetCore و davidfowl ببدء DNX 2.0.

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

يمكننا أيضًا أن ننظر إلى هذا بالطريقة التي ربما تنويها:

• NET Core لوحدة التحكم / الويب / سطح مكتب الطرف الثالث (قياسي + واجهة برمجة تطبيقات خاصة بالويب)
• الوحدة مخصصة للألعاب (واجهة برمجة تطبيقات قياسية + خاصة باللعبة)
• Xamarin مخصص للأجهزة / سطح المكتب (قياسي + واجهة برمجة تطبيقات خاصة بالجهاز / سطح المكتب)

ولكن من دفع .NET Standard إلى الأمام؟ كما قلت من قبل ، فإن الموارد محدودة ، لذلك بدون الحاجة إلى دفع الأمور إلى الداخل (والتي ستقع في اقتراحي على الفريق الأساسي .net core / asp.net بالحاجة إلى تغييرات لإصدار LTS) أخشى. ستصبح NET Standard قديمة بسرعة.

بالنسبة لأولئك الذين لا ينتبهون ، يبدو أن .NET Standard 2.1 أسقط دعم NET Framework.

نظرًا لأن العديد من إضافات واجهة برمجة التطبيقات في .NET Standard 2.1 تتطلب تغييرات في وقت التشغيل حتى تكون ذات مغزى ، فإن .NET Framework 4.8 سيظل على .NET Standard 2.0 بدلاً من تطبيق .NET Standard 2.1. سيتم تحديث NET Core 3.0 بالإضافة إلى الإصدارات القادمة من Xamarin و Mono و Unity لتطبيق .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

بقدر ما يؤلمني رؤية NET Framework . يحصل على Silverlight-ed ، فإن ما يهمني فيما يتعلق بـ ASP.NET Core هو أنه يجب أن يستهدف .NET Standard .

نظرًا لأنه من المحتمل أن يكون أحد أكبر التطبيقات المرجعية في النظام البيئي الأساسي / القياسي ، أعتقد أن ASP.NET Core تتحمل مسؤولية أن تكون بطلًا لـ .Net Standard وجميع الأشياء الجيدة التي يمثلها.

أعتقد أنه من المعقول أن يطلب ASP.NET Core تغييرات على المعيار الذي يتم تنفيذه بعد ذلك في .NET Core.

بنفس الطريقة التي يتوفر بها Span etc _is_ في .Net Framework من خلال حزمة nuget ، أعتقد أنه من المعقول أنه إذا احتاج ASP.NET Core / يريد الاعتماد على شيء لم يتم تضمينه بعد في .Net Standard ، فيجب تضمين هذه التبعية في عبر حزمة nuget.

أخيرًا ، آمل (رغم كل الأدلة التي تشير إلى عكس ذلك) ، أن يكون هناك .Net Framework 5.0 الذي سيستهدف .Net Standard 3.0+ وسيكون تثبيتًا جنبًا إلى جنب مع 4.x.

أخيرًا ، آمل (رغم كل الأدلة التي تشير إلى عكس ذلك) ، أن يكون هناك .Net Framework 5.0 الذي سيستهدف .Net Standard 3.0+ وسيكون تثبيتًا جنبًا إلى جنب مع 4.x.

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

هذا هو بالضبط .NET Core ، وهذا الخيط هو الألم المؤقت الذي تعاني منه.

terrajobst قال إن ذلك لن يحدث: انظر الموضوع: https://twitter.com/terrajobst/status/1059525279431815168؟s=19

تضمين التغريدة
نعم ، باستثناء شيئين.

1. Core ليس ترقية من Framework ؛ إنه مفهوم مواز. هناك الكثير من الأشياء الأساسية التي لا تستطيع فعلها ، وكثير منها ، مثل AppDomains ، قيل لنا إنه من غير المرجح أن يحدث على الإطلاق. من أجل الجنة ، ما زلنا لا نملك حتى Reflection.Emit ! بالنظر إلى مدى شيوع ذلك في أدوات إنشاء البرامج والمجمعات البرمجية ، قد تعتقد أن ذلك كان من شأنه أن يكون حرفيًا إحدى الأولويات الأولى ، ومع ذلك ها نحن بعد 4 سنوات ولم ينجح الأمر! هذا يجعل من الصعب للغاية التعامل مع فكرة "Core كبديل / ترقية لـ .Net Framework" على محمل الجد.
2. لا يقوم Core بترقية وقت التشغيل بشكل جذري ، نمط CLR 2.0. انتهى عند "ما هي مقترحات اللغة التي ستستفيد من تغييرات CLR؟" لدينا قائمة رائعة من المجتمع بالميزات المفقودة التي يعتبرها الأشخاص مهمة ، والتي لا يمكن لـ CLR دعمها ، (أو على الأقل لا يمكن دعمها بدون أخطاء ضخمة وقبيحة للتغلب على قيود CLR) بشكل عام بسبب الميزات المفقودة في نظام الكتابة. كم عدد المقترحات في هذا الموضوع التي تم أخذها على محمل الجد من قبل الفريق الأساسي؟ وكم من الباقين تم استبعادهم من أيديهم لأن الأشخاص الذين يديرون المشروع لا يريدون ترقية وقت التشغيل؟ نحصل على DIMs و ... أي شيء آخر؟ أي شيء على الإطلاق؟

لذا لا ، فإن .NET Core ليس .NET Framework تمت ترقيته يقوم بإجراء تحديثات CLR التي تشتد الحاجة إليها ، لأنه ليس .NET Framework تمت ترقيته ويفعل فريق المشروع كل ما في وسعه لتجنب تحديث CLR حيثما أمكن ذلك. إنه عكس ذلك تمامًا.

بحق السماء ، ما زلنا لا نملك حتى انعكاس عملي. بالنظر إلى مدى شيوع ذلك في أدوات إنشاء المجمّعين والتعليمات البرمجية ، قد تعتقد أن ذلك كان من شأنه أن يكون حرفيًا إحدى الأولويات الأولى ، ومع ذلك ها نحن بعد 4 سنوات ولم ينجح الأمر! هذا يجعل من الصعب للغاية التعامل مع فكرة "Core كبديل / ترقية لـ .Net Framework" على محمل الجد.

سيكون من الرائع فهم ما لا يعمل. يستخدم ASP.NET Core و EF انعكاسًا انبعاثًا في مكانين لذا فأنا لست على دراية بالفجوات الكبيرة. هل يمكنك التفصيل هنا؟

لقد كان موجودًا منذ 2.0 على الأقل .. حتى أن الإصدار 1.0 من iirc يحتوي على DefineDynamicAssembly ، على الرغم من أنه ربما لا يكون المجموعة الكاملة من العناصر المنبعثة.

كما أنني أجد صعوبة في التعامل بجدية مع فكرة أنهم يتجنبون تحديث CLR. هل رأيت الحجم الهائل للعمل المنجز؟ https://github.com/dotnet/coreclr/commits/master
هناك ميزات لغة محددة لـ C # 8 والتي ستعمل فقط على .NET Core بسبب تغييرات CLR أيضًا. يبدو أن الكثير من هذه الاعتراضات مجرد معلومات قديمة (وهو أمر عادل بما فيه الكفاية ، نظرًا لأن خطط Microsoft قد تغيرت بسرعة في بعض الأحيان ...)

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

سيكون من الرائع فهم ما لا يعمل. يستخدم ASP.NET Core و EF انعكاسًا انبعاثًا في مكانين لذا فأنا لست على دراية بالفجوات الكبيرة. هل يمكنك التفصيل هنا؟

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

هل تم إصلاح هذا؟ يسعدني أن أسمع أن لديها ...

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

كما أنني أجد صعوبة في التعامل بجدية مع فكرة أنهم يتجنبون تحديث CLR

ما قلته هو أنهم يتجنبون ترقية CLR جذريًا بنفس طريقة التحديث 2.0 (الأدوية العامة.)

على وجه التحديد ، يبدو أنهم يتجنبون بنشاط أي تغييرات من شأنها أن تضيف أنواعًا أساسية جديدة من الأنواع إلى نظام النوع ، (الأشكال ، الفئات الوصفية ، DUs ، إلخ) أو تعليمات IL جديدة لمجموعة التعليمات.

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

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

بالنظر إلى https://github.com/dotnet/corefx/issues/4491 (حيث قمت بالتعليق في الماضي) ، أعتقد أن الوضع لا يزال كما هو. على الرغم من أنني أعتقد أن عدم وجود ميزة واحدة محددة (حتى لو كانت مهمة) يختلف تمامًا عن "ما زلنا لا نملك حتى Reflection.Emit ".

مما يجعل Core عديم الفائدة لمشرفي المترجم مثلي مثلي

كيف يكون Reflection.Emit مفيدًا لكاتب المترجم؟ اعتقدت أنه يقتصر على إنتاج تجميعات للإطار الحالي ، لذلك لا يمكن استخدامه لإنشاء تجميعات Net Standard على سبيل المثال ، والتي أعتقد أنها ستكون قيدًا كبيرًا لأي مترجم.

ما قلته هو أنهم يتجنبون ترقية CLR جذريًا بنفس طريقة التحديث 2.0 (الأدوية العامة.)

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

أعتقد أن DIM هي علامة على أن هذا قد يتغير ، لكنني ما زلت لا أتوقع تعليمات IL جديدة عندما تعمل مكونات JIT بشكل جيد في كثير من الأحيان ، أو أنواع جديدة من الأنواع عندما يمكن تشفيرها بشكل معقول في نظام الكتابة الحالي.

svick

على الرغم من أنني أعتقد أن عدم وجود ميزة معينة (حتى لو كانت مهمة) يختلف تمامًا عن "ما زلنا لا نملك حتى انعكاس عملي. إميت".

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

كيف يكون Reflection.Emit مفيدًا لكاتب المترجم؟

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

ما زلت لا تتوقع تعليمات IL جديدة عندما يمكن أن تعمل مكونات JIT بشكل جيد في كثير من الأحيان

بالتأكيد ، ولكن ماذا عن الحالات التي لا يفعلون فيها؟

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

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

نحتاج إلى CLR محدث لتطوير ميزات عالية المستوى بأي نوع من الطرق الفعالة ، ولا أحد يعمل بالفعل على تحقيق ذلك في Core.

هل يمكن لشخص ما من فريق .net توضيح ما هي توصياتهم لعمليات النشر في مقر الشركة؟ هل هو مجرد "استخدام asp.net العادية"؟ أنا أتحدث تحديدًا إلى تعليقات @ Edward84

هل يؤثر هذا على مكتبات الدعم Microsoft.Extensions.* ؟ على وجه التحديد Microsoft.Extensions.Logging و Microsoft.Extensions.Configuration .

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

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

لذلك أتساءل ما إذا كانت هذه آمنة للاستخدام في .NET Standard API المشار إليها بواسطة .NET Core و .NET Framework (4.7.2+) أم أنها قد تبدأ أيضًا في استخدام ميزات .NET Core فقط؟

mvestergaard كما هو مذكور في الإعلان نفسه :

ستستمر حزم Microsoft.Extensions (مثل التسجيل وإدخال التبعية والتكوين) في دعم .NET Standard

وفي تعليق benaadams في هذا الموضوع :

لا تنتقل جميع المكتبات إلى .NET Core فقط (على سبيل المثال ، يبقى Microsoft.Extensions.* كـ .NET Standard)

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

أكبر مشكلة لدي مع هذا هي عدم القدرة على استخدام الحزم الناضجة التي لا يمكن استخدامها إلا عند استهداف .NET Framework أو تلك التي لم تكن متوفرة خارج .NET Framework مثل تلك التي تحتاج إلى System.Drawing و GDI +.

يبدو أن السيناريو الأخير سيتم دعمه في .NET Core 3.0 ، ولكن AFAICT ، ما زلنا نفتقد استخدام المكتبات المستقرة والناضجة التي لا يمكن استخدامها إلا على .NET Framework.

مثال على ذلك هو Entity Framework . سيتعين علينا التحول إلى EF Core غير الناضجة والذي يبدو أنه بعيد جدًا عن التعامل مع جميع السيناريوهات المعقدة التي يمكن لـ EF الكاملة أن تعود إلى تقييم العميل في الذاكرة خلف ظهرك لإخفاء تلك المشكلة التي تسبب الأداء مشاكل .

مثال على ذلك هو Entity Framework. سيتعين علينا التحول إلى EF Core غير الناضجة والذي يبدو أنه بعيد جدًا عن التعامل مع جميع السيناريوهات المعقدة التي يمكن لـ EF الكاملة ...

سيتم دعم EF6 في .NET Core 3.0 كما أوضحه DamianEdwards في هذا الأسبوع ASP.NET Community Standup - 6 نوفمبر 2018 - ميزات ASP.NET Core 3.0 في الساعة 19:06

benaadams هذه أخبار رائعة! غامضة جدا لمثل هذه الصفقة الكبيرة! :) عمل جيد في إيجاد ذلك. وجدت ذكرًا آخر لها هنا .

SaebAmini : يمكنك استخدام النظام. بالاعتماد على .NET Core. انظر System.Drawing.Common and Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ،

وقبل ذلك ، كان هناك CoreCompat.System.Drawing ، System.Drawing .

هل هناك أي ميزة مفقودة لحالة الاستخدام الخاصة بك عند التشغيل على .NET Core؟

TsengSR كان السيناريو الخاص بي الذي جعلنا نستهدف .NET Framework هو:

1. الحاجة إلى استخدام حزمة Microsoft Solver Foundation ، المتوفرة فقط في .NET Framework.
2. حزمة إنشاء صورة الباركود التي تستخدم رسم النظام.
3. الحاجة إلى استخدام EF6.

كان هذا قبل نحو سنة.

SaebAmini : كما ذكرنا سابقًا ، يأتي دعم EF6 في .NET Core 3.0 ، System.Drawing موجود بالفعل (وقبل ذلك كانت حزمة CoreCompat موجودة وربما عملت في حالتك) ولحزمة Microsoft Solver Foundation ، بعد تشغيل أداة تحليل قابلية النقل:

راجع كيفية استخدام محلل قابلية النقل

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (قم بتنزيله وافتح HTML ، ولم تجد مكانًا آخر لوضعه فيه).

يظهر توافق 97.93٪ مع .NET Core 2.0 + Platform Extensions (الذي تم إصداره منذ حوالي عام) ويسرد واجهات برمجة التطبيقات غير المتوافقة ، والتي ترتبط في الغالب بـ System.Web الذي تم إهماله و System.ServiceModel / System.Data.Linq .

الآن ، لم أستخدم هذه الحزمة من قبل ، ولست متأكدًا من سبب احتياج المحلل إلى الوصول إلى System.Web و HttpContext أو System.ServiceModel ، لكن إذا لم تفعل لا تحتاج إلى أي من هذه الأطروحات (وأنت تعلم أن حالة الاستخدام الخاصة بك لا تستدعي واجهات برمجة التطبيقات هذه) ، فالاحتمالات عالية جدًا ، حيث يمكنك استخدامها على .NET Core 2.0 / 2.1 + ملحقات النظام الأساسي أو على .NET Core 3.0 ، حتى إذا لم يكن يستهدف على وجه التحديد اللقب الهدف netstandard أو netcoreapp20 الهدف.

لذلك ، من الناحية الفنية ، كانت الفرص جيدة حيث كان من الممكن أن تقوم بترحيل تطبيقك إلى .NET Core 2.0 + Platform Extensions قبل عام ، إذا كان من الممكن أن تغطي EF Core 2.0 احتياجات تطبيقاتك (بالطبع تتطلب بعض أعمال الترحيل والتحديثات للعمل مع EF Core 2.0).

نعم ، يتطلب الأمر مزيدًا من العمل لتحليل المكتبات المعنية أو ميزة إطار العمل البديل (EF6 -> EF Core 2.0 / 2.1) ، لكنها أبعد ما تكون عن المستحيل. لا أعتقد أن الأشخاص يمكنهم أو يجب أن يتوقعوا نقل جميع التعليمات البرمجية الخاصة بهم 1: 1 إلى ASP.NET Core بدون إجراء أي تغييرات على الإطلاق (خارج ASP.NET Core نفسها).

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

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

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

أتفق مع gulbanana @. NET Core الآن أكثر توافقًا مع .NET Framework. في الواقع ، تمكنت من تشغيل تطبيقات .NET Framework كبيرة جدًا فقط عن طريق إعادة تسمية .exe إلى .dll وإضافة بعض .DLLs المفقودة إلى مسار الفحص.

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

تجميع AOT مع crossgen رائع. يمكنني أن أذهب وعلى.

tl / dr. NET Core مثير للإعجاب في الوقت الحاضر.

ما المفقود:

• استراتيجية الاتصال مع العملاء الحالية تفتقر. يشعر العملاء بخيبة أمل كبيرة عندما يسمعون أن نظام .NET الأساسي المفضل لديهم يتم تجزئة بواسطة Microsoft. يجب أن تكون أكثر وضوحا هنا. على سبيل المثال ، سيكون أسلوبًا أفضل بكثير للإعلان المباشر عن تطبيق NET المفرد والمتوافق للغاية والسريع والمقاوم للمستقبل للناس. مثل NET Core ، فإن مستقبل NET ، سوف يحل معظم مشاكلك ، وإنتاجية صاروخ السماء ، والإبداع ، وفتح مجالات سوق جديدة ، إلخ.
• المزيد من استراتيجيات التوافق خارج الصندوق
• واجهة المستخدم الرسومية. أعني أن أدوات سطر الأوامر dotnet رائعة ، ولكن يتعين علينا حاليًا استخدام برامج تحرير نصوص إضافية ووحدة تحكم للعمل على كل مشروع تقريبًا بتنسيق .NET SDK. واجهة مستخدم Visual Studio غير متوفرة في هذا الصدد. هذا يضع حواجز كبيرة أمام العديد من الأشخاص الذين لديهم عادة مجرد التأشير والنقر. يجب تحسين هذا أيضًا
• دعم LTS

@ TsengSR شكرًا لك على ردك التفصيلي يا

لا تهتم بالجهد حقًا إذا كان ذلك معقولًا. كان قلقي الرئيسي هو أن أترك عالياً وجافًا مع عدم وجود خيار مع كون EF هي المانع الرئيسي وهذا على ما يبدو لن يحدث. من الرائع أن نرى أنه تم التفكير فيه جيدًا. على الرغم من أنني أتفق مع gulbanana @ على أنه يمكن الإعلان عنها بشكل أفضل.

هناك الكثير من القضايا المختلطة هنا. سنتان الشخصي لديّ هو أن ترك .NET Framework خلفك ليس بالأمر المهم. لكن ما يثير القلق هو النقص التام في أي دعم واضح لجهود التقييس (.NET Standard). بالتأكيد ، ربما لا ترغب في تشغيل ASP.NET Core ، على سبيل المثال Unity اليوم ، لكن الأمر ليس موجودًا اليوم. ولكن عن سنة أو سنتين على الطريق، عندما وقت التشغيل .NET آخر يمكن أن يأتي حولها، وأود أن تكون قادرة على القول "نعم، في أقرب وقت يدعم SuperNetRuntime. NET ستاندرد 2.2 يمكننا تشغيل ASP.NET كور 3 على أنه" ...

هل هناك أي فرصة "لجمع" كل التغييرات المطلوبة على الأقل في .NET Core 3 لـ ASP.NET Core 3 وإعادة توجيهها إلى مجموعة عمل .NET Standard كاقتراحات؟

مرحبًا ، هل ستواصل الحزم المنشورة لـ .NetStandard 2.0 أو .NetCore 2.0 العمل مع .NetCore 3.0. على سبيل المثال: Oracle.ManagedDataAccess.Core target .NetCore 2.0

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

.NetFramework لديه تاريخ من التوافق حتى يمكنك استخدام .NetFramework 2.0 في أحدث الإصدارات ، لذلك يجب الحفاظ على شيء ما لـ .NetCore أيضًا على الأقل 2.0 إلى 3.0 وما إلى ذلك.

شكر

مرحبًا ، هل ستواصل الحزم المنشورة لـ .NetStandard 2.0 أو .NetCore 2.0 العمل مع .NetCore 3.0. على سبيل المثال: Oracle.ManagedDataAccess.Core target .NetCore 2.0

نعم ، يحافظ .NET Core 3.0 على التوافق مع الإصدارات السابقة لذلك يمكن استخدام .NetStandard 1.0 -> .NetStandard 2.1 و .NetCore 1.0 -> .NetCore 2.2

benaadams ثم هذا جيد. كما سيعمل .net framework dll إذا لم يستخدموا أي واجهة برمجة تطبيقات مفقودة؟

شكر

كما سيعمل .net framework dll إذا لم يستخدموا أي واجهة برمجة تطبيقات مفقودة؟

نعم ، على الرغم من أنه من الأكثر أمانًا استخدام مكتبة .NET Standard كما تعلم ، فإنها ستعمل على .NET Core (وعلى Mono و Xamarin و Unity و UWP)

بالإضافة إلى ذلك ، فإن استخدام حزمة توافق Windows يضيف 20000 واجهة برمجة تطبيقات أخرى إلى جانب .NET Standard 2.0 لتقريب NET Core من .NET Framework (وهو ما يمكنك القيام به باستخدام .NET Core 2.1) ؛ و .NET Core 3.0 هو الأكثر توافقًا حتى الآن مع EF6 (cross-plat) ، وعلى نظام Windows: WinForms و WPF و COM Interop إلخ

مرحبا يا رفاق،
من أجل منح العملاء نقطة انطلاق معقولة في طريقهم لترحيل التطبيقات إلى ASP.NET Core على .NET Core ، سنقوم بتوسيع الدعم والخدمة لـ ASP.NET Core 2.1.x على .NET Framework لمطابقة الدعم الحالي سياسة أطر عمل ASP.NET الأخرى

أخبارممتازه. شكرا لك على الاستماع إلى عملائك.

سوف يستغرق الأمر منا وقتًا طويلاً جدًا لنقل تطبيق MVC القديم الخاص بنا كما كنا على MVC منذ CTP3 ولدينا كل نقطة تمديد مستخدمة. هذا يغطي مخاوفنا.

DamianEdwards هذه أخبار رائعة! أتساءل فقط ، هل تم إصلاح هذا إلى 2.1.x أم سيتم تحديثه إلى 2.2.x إذا انتهى الأمر ليصبح إصدار LTS؟ كان هناك الكثير من الجهد المبذول في 2.2 ولم يتم إصداره بعد. ونظرًا لأنه يستمر في التوافق مع معايير الشبكة ويعمل بشكل جيد في إطار العمل الكامل ، فسيكون من الضياع تخطي هذا تمامًا للحصول على الدعم الموسع.

poke بينما

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

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

الميزات الجديدة لا تأتي إلى LTS لأنها تتعلق بالاستقرار.

هذا لا يتطابق حقًا مع قرارات LTS السابقة.

@نكز

هذا لا يتطابق حقًا مع قرارات LTS السابقة.

هذا حيرني. في أي طريق؟ هل تشير إلى حقيقة أنه تمت إضافة 1.1 إلى قطار 1.x LTS؟ إذا كان الأمر كذلك ، فقد كان هذا شذوذًا في أول قطار إطلاق لدينا لن يتكرر. من الآن فصاعدًا ، نهدف إلى الحصول على مزيد من الاتساق مع الإصدارات التي تصبح LTS مقابل الحالية (أي أين أحصل على الاستقرار مقابل الميزات).

DamianEdwards كنت أشير في الغالب إلى حقيقة أن كل إصدار حتى الآن كان

poke موافق. حسنًا ، حتى الآن لدينا 4 إصدارات (1.0 ، 1.1 ، 2.0 ، 2.1) مع الإصدار الخامس قريبًا (2.2). من بين هؤلاء ، تم تصميم 1.0 و 2.0 فقط في البداية ليكونا LTS ، ولكن نظرًا لعدد من العوامل (تتعلق في الغالب بكوننا جديدًا حقًا في القيام بالهندسة بهذه الطريقة we) انتهى بنا الأمر مع 1.0 و 1.1 و 2.1 على أنها قطارات LTS. الإصداران 2.0 و 2.2 (كانا ، وسوف) الإصدارات الحالية. في هذه المرحلة ، من المؤكد أن الإصدار 3.0 سيكون حاليًا أيضًا (مما يتسبب في دخول 2.2 إلى فترة "السماح" الحالية البالغة 3 أشهر) قبل أن يصبح الإصدار 3.1 هو 3.x قطار LTS. أملنا بعد ذلك ، سيكون النمط والإيقاع أكثر اتساقًا (نحب ذلك) ولكن حتى الآن الكرة البلورية لدينا قد خذلتنا.

DamianEdwards شكرا على الأفكار! 😄 (راجع للشغل. لم أكن أحاول الجدال حول هذا ، كنت مجرد فضول ؛))

المشكلة الأكبر بالنسبة لنا هي واجهات برمجة تطبيقات REST الجديدة التي تستضيفها التطبيقات القديمة والتي من غير المحتمل أن تنتقل من .NET Framework في أي وقت قريب. على الأقل نحن نعلم عدم التقدم إلى ما بعد .NET Standard 2 والمكتبات الداعمة و ASP.NET Core 2.1 الآن! من الجيد أن يتم تمديد فترة LTS

مرحبًا بالجميع ، سؤال سريع: ماذا عن أولئك منا الذين يستهلكون حزم أصلية في شكل C ++ / CLI؟ هل سيتم دعم ذلك في .Net Core في أي وقت قريب ، أم أننا أصبحنا يتامى ما لم نقم بإعادة صياغة ضخمة لاستخدام P / Invoke؟

lokitoth - سيكون هذا سؤالًا جيدًا لـ https://github.com/dotnet/core folks لأنه أكثر عمومية من مجرد ASP.NET Core.

lokitoth نعم ، سيتم دعم ذلك ، راجع https://github.com/dotnet/coreclr/issues/18013

oO كيف فاتني ذلك؟

حسنًا ، ليس لدي أي مشاكل مع هذا.

@ danroth27 هل يمكنك إخبارنا بتأثير هذه المشكلة على Client-Side-Blazor؟

Slkebe لا أتوقع أي تأثير. تطبيقات Blazor من جانب العميل مستقلة عن أي وقت تشغيل أو نظام أساسي تقرر تشغيله على الخادم.

@ danroth27 من وجهة نظري ، يمكن تشغيل Blazor من جانب العميل على أحادية لأن حزم Microsoft.AspNetCore.* تعتمد على الشبكة القياسية.
هل فاتني شيء؟ يجب أن تستمر Blazor في استهداف Microsoft.AspNetCore.* 2.1.X؟

Slkebe تعتمد مكتبات Blazor من جانب العميل فقط على المكونات التي ستستمر في استهداف .NET Standard (مثل Microsoft.Extensions. * والأصدقاء). ستستهدف أجزاء من جانب الخادم من Blazor والتي تعتمد على ASP.NET Core NET Core كما هو موضح في هذه المشكلة.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

ما هو القرار الان؟ الهدف على .net القياسي 2.1؟

@ John0King ليس هناك قرار جديد.

هذا موز! موز

أنا متعاطف مع وجهة نظرك.

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

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

أنا أستخدم ASP.NET Core نظرًا لإمكانياتها متعددة المصادقة.

FlorianGrimm ماذا على وجه التحديد؟ قدم Microsoft.Owin وظيفة مصادقة مماثلة لـ ASP.NET 4.

إنه تطبيق هجين كود مصدر واحد (.exe) يعمل في أماكن العمل و azure ، ويستخدم حاليًا مصادقة windows و aad والمصادقة الأساسية والمجهول.

FlorianGrimm ما هي تبعيات المكتبة التي تمنعك من استخدام .NET Core؟

Microsoft.Office.Project.Schema و Microsoft.SqlServer.TransactSql.ScriptDom و Microsoft.SharePointOnline.CSOM.

آمل أن ينتهي فريق SharePoint
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
وأجد خيارات أخرى غير ilspy.

بأي طريقة أحب ASP.NET Core وآمل أن توفر فرق Microsoft الأخرى المزيد من تجميعات .NET Core.

نقوم بشكل دوري بإغلاق قضايا "المناقشة" التي لم يتم تحديثها منذ فترة طويلة من الزمن.

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