Aspnetcore: [مناقشة] تبعية المشروع بعد التخلص التدريجي من project.json

تم إنشاؤها على ١١ مايو ٢٠١٦  ·  338تعليقات  ·  مصدر: dotnet/aspnetcore

بعد وقوف المجتمع الأخير ، كان هناك إعلان حول الإلغاء التدريجي لـ project.json .

فيما يلي بعض المشكلات التي أراها مع ذلك وأود بعض التوضيحات.

  • [x] سيتم دمج معظم الأشياء غير التابعة لـ NuGet في csproj. ماذا سيحدث لأشياء NuGet إذا لم يكن هناك project.json (nuget.json؟)؟
  • [x] هل سنحتفظ بالتحسس الذكي لإدارة التبعية؟ هذه في الأساس واحدة من أفضل الميزات التجريبية التي نوفرها مقابل project.json .
  • [x] هل نحتفظ بتنسيق JSON لإدارة التبعية؟ XML أمر مروع لهذه الأنواع من الأشياء (انظر Maven). JSON أسهل في تمثيل تلك التبعيات.

هل من الممكن الحصول على بعض الردود الواضحة على هذه الأسئلة؟

شكرا لك،

التعليق الأكثر فائدة

+1 على أسوأ أخبار الأسبوع. أين كان النقاش حول هذا؟ لا أجد أي شيء ، مجرد قرار أحادي الجانب.

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

هل هذه هي الطريقة التي نؤدي بها الأشياء في .NET Core؟ المساومة على الجودة خلف الأبواب المغلقة لأننا نريد دعم قائمة غير معلنة للتكنولوجيا القديمة؟

بكل الوسائل ، لنقم بامتداد VS الذي ينشئ ملف csproj. من مشروع json يمكن للأشخاص الذين يستخدمون تلك التقنيات القديمة الاستفادة منه.

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

ال 338 كومينتر

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

وأنا لا أوافق على أن "JSON أبسط لتمثيل تلك التبعيات". هناك حسنات وسيئات. انظر هذا https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

أوافق على تغيير _if_ الذي تم نقله إلى nuget.json. هذا هو الجزء الوحيد من المشروع. Json الذي اعتقدت أنه يجب أن يكون قابلاً للتعديل على أي حال.

darrelmiller Yaml هو على الأرجح بديل أفضل من حيث الإسهاب. وأنت غششت بسلسلة مفصولة بفاصلة بدلاً من المصفوفات ؛).

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

نعم وهذا هو أسوأ خبر هذا الأسبوع. يبدو الأمر وكأنك تعود بالزمن إلى الوراء ... :( في الواقع ، Xml ليس سيئًا ، ولكن msbuild ... ومشروع قاعدة msbuild xml لن يكون سلسًا كما وصفته.

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

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

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

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

+1 على أسوأ أخبار الأسبوع. أين كان النقاش حول هذا؟ لا أجد أي شيء ، مجرد قرار أحادي الجانب.

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

هل هذه هي الطريقة التي نؤدي بها الأشياء في .NET Core؟ المساومة على الجودة خلف الأبواب المغلقة لأننا نريد دعم قائمة غير معلنة للتكنولوجيا القديمة؟

بكل الوسائل ، لنقم بامتداد VS الذي ينشئ ملف csproj. من مشروع json يمكن للأشخاص الذين يستخدمون تلك التقنيات القديمة الاستفادة منه.

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

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

في رأيي أن ذلك سيكون:

  • عدم الاضطرار إلى تحديد كل ملف CS
  • القدرة على تعديل الملف دون الحاجة إلى تفريغ المشروع
  • القدرة على تعديل تبعيات nuget مباشرة في الملف (مع IntelliSense)
  • القدرة على استبدال حزم nuget بمصدر محلي من خلال global.json

فيما يتعلق بالتجميع ، أعتقد أنه من الممكن تجميعه دون تثبيت Visual Studio. بالنسبة لي ، لا يهم إذا كان الأمر الفعلي هو "بناء dotnet" أو "msbuild". الشيء المهم هو أنه يجب أن تكون هناك طريقة لتجميع الحل بالكامل ، والذي - بالمناسبة - غير موجود بعد في "dotnet cli" (على الأقل ليس بقدر ما أعرف).

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

تحرير: أعتقد أن هذا لا يغير أيًا من الأفكار الأساسية (والعظيمة) لـ .NET Core وما إلى ذلك.

IMHO ، المشكلة الرئيسية هي أن هذه الأنواع من التغييرات الجذرية قبل RTM ليست جيدة. إذا حدث هذا في أوقات بيتا ، فقد لا يفاجأ المطورون / الفرق كثيرًا. فكر في الاستثمارات التي يقوم بها الأشخاص منذ العامين الماضيين . فكر في المنتجات / المكتبات / إطار العمل الحالي اعتمادًا على نظام project.json . Asp.Net في RC وليس في المعاينة / alpha / beta ، هذا النوع من التغييرات يكسر ثقة المطورين / الفرق :(.

IMHO ، المشكلة الرئيسية هي أن هذه الأنواع من التغييرات الجذرية قبل RTM ليست جيدة.

اعتقدت ذلك أيضًا في البداية ولكن بقدر ما أفهم ذلك ، لن يؤدي ذلك إلى أي تغييرات في رمز التطبيق الخاص بك. سيؤثر ذلك فقط على ملفات project.json / xproj / csproj وقالوا إن التغيير قد يكون تلقائيًا - لذلك سيكون هذا مشابهًا لخطوات ترحيل المشروع القديمة الجيدة التي حدثت بالفعل عدة مرات عند ترقية Visual Studio.

راجع للشغل اعتقدت دائمًا أن وجود ملف project.json وملف xproj (الذي يحتوي على مساحة الاسم الافتراضية لقوالب Visual Studio وبعض مسارات الإخراج ، لذلك عليك تعديله أيضًا في بعض الأحيان) كان غريبًا.

راجع للشغل اعتقدت دائمًا أن وجود ملف project.json وملف xproj (الذي يحتوي على مساحة الاسم الافتراضية لقوالب Visual Studio وبعض مسارات الإخراج ، لذلك عليك تعديله أيضًا في بعض الأحيان) كان غريبًا.

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

لقد كنت أستخدم هذه الأشياء على جهاز Mac في VS Code لفترة طويلة لقد نسيت كل شيء عن xproj. OTOH ، لقد فاتني حقًا تصحيح الأخطاء والمزيد من Visual Studio!

أعتقد أنك متشائم للغاية - وأعتقد أن هذا يرجع أساسًا إلى أننا فوجئنا جميعًا بهذا

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

http://c2.com/cgi/wiki؟XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

الآن ، يتم إنشاء .NET Core عندما يعتقد الجميع أن JSON ستحل كل شيء. لا أعتقد أن JSON يعد حلاً طويل المدى أكثر من XML ، لكنني أعلم أنه من الأسهل دمج تعارضات JSON من تلك الموجودة في XML.

لقد وجدت أنفاسًا منعشة لا أتعامل مع مهملات XML لملفات المشروع ، ووجدت أنه من الأسهل قراءة ملفات JSON ، ووجدت أن ملفات JSON أسهل في العمل خارج Visual Studio ، وأنا لا تريد العودة إلى XML / MSBuild.

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

قال DamianEdwards بوضوح إنهم يريدون الاحتفاظ بالأجزاء الجيدة من نموذج project.json.

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

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

سيكون عليك الانتقال إلى YAML ، وما إلى ذلك إذا كنت تريد تجنب ذلك.

IMO مشكلة csproj ليست مع XML ولكن في كيفية تعامل Visual Studio معها وأنها تحتوي على كل ملف cs. إذا تم إصلاح ذلك وإذا لم تغير الأدوات الأشياء بشكل عشوائي في الملف ، فلن يكون الدمج مشكلة بعد الآن.

ومع ذلك ، من حيث قابلية القراءة ، أفضل أيضًا JSON. تمكنت من كتابة project.json من البداية - أعتقد أنني لن أكون قادرًا على القيام بذلك باستخدام csproj (يتطلب csproj دليل ProjectGuid عشوائيًا ، إلخ). لذلك سنحتاج بالتأكيد إلى دعم سطر الأدوات / الأوامر لهذا الغرض.

قلقي الرئيسي بشأن هذا الأمر برمته الذي لم أسمع عنه كثيرًا هو أن project.json أكثر وضوحًا عندما يتعلق الأمر بالمراجع أكثر من ملفات المشروع .csproj . إن جمال التبعيات في ملف project.json ولماذا كنت أتطلع إلى ترحيل قاعدة الرموز الخاصة بنا إليه هو أنك تقول فقط "أنا بحاجة إلى هذه التبعية" ولا يهم ما إذا كان هذا مشروعًا محليًا أو حزمة NuGet. في حالتنا ، سيوفر لنا هذا الكثير من المرونة وخيارات جديدة رائعة. في المقابل ، فإن المرجع حاليًا في ملف .csproj هو مسار صعب نسبي لملف .dll على القرص. في الوقت الحالي ، لا تؤدي إضافة إدخال إلى bund.config في مشروع تقليدي إلى فعل أي شيء ، تحتاج أيضًا إلى إضافة مرجع إلى .dll من تلك الحزمة إلى ملف .csproj . يتم ذلك من أجلك بواسطة أدوات NuGet داخل Visual Studio ، لكنني لا أريد استخدام هذه الأدوات عند إضافة سطر من النص إلى ملف project.json هو أبسط كثيرًا.

أدرك أن الفريق يريد الاحتفاظ بجميع الوظائف التي يوفرها الملف project.json وتوسيع ميزات تنسيق .csproj ، لكنهم تحدثوا أيضًا عن الاحتفاظ بـ project.json كملف لتحديد حزم NuGet الخاصة بك في. لا أرى ما قد يضيفه ذلك مقارنة بالوضع الحالي مع packages.config حيث لا يكفي مجرد إضافة إدخال إليه لأنك ما زلت بحاجة إلى إضافة مرجع إلى .dll في .csproj أيضًا. إذا كان الملف .csproj هو المستقبل ، فأنا أفضل أن أرى الفريق الأساسي يسير على طول الطريق ويسقط project.json أو nuget.json أو على أي حال ينتهي الأمر باستدعاء _entirely_ وإضافة طريقة أكثر وضوحًا لإضافة مراجع إلى تنسيق .csproj . يمكنني العيش على ما يرام مع الاضطرار إلى تحرير ملف XML بدلاً من ملف JSON (على الرغم من أنني أفضل بالتأكيد JSON) ولكن سيكون من العار حقًا أن أفقد الطبيعة التصريحية لـ project.json ولست بحاجة إلى اثنين أماكن مختلفة حيث أحتاج إلى تحديد التبعيات الخاصة بي.

يرجى إبداء الملاحظات على https://www.surveymonkey.com/r/H6Q88PP

فقط للتوضيح ، في قراءة ملاحظات Standup ، يذكر أن أحد الخيارات هو تثبيت nuget - حفظ نوعًا من الخيار (انظر https://blogs.msdn.microsoft.com/webdev/2016/05/11/ مذكرات من-the-asp-net-community-standup-May-10-2016 /). بينما أعتقد أن هذه فكرة جيدة ، فإن استبدال "تحرير ملف .json بـ intellisense" أعتقد أنه فكرة سيئة. أعتقد أن البقاء في المحرر فكرة جيدة للبعض منا الذين لا يريدون التحول إلى الصدفة لفعل كل شيء. أفضّل شخصيًا أن يكون لدي كلتا التجربتين. سطر الأوامر + واجهة المستخدم لإضافة التبعيات ليست جيدة بما فيه الكفاية.

أنا مبرمج ، لا أريد ترك المحرر.

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

اقتباس المفضل لدي على ملفات MSBUILD؟

اضطررت مؤخرًا إلى قضاء الكثير من الوقت مع ملفات csproj. إنهم يشبهون ويتصرفون إلى حد ما مثل Ant / Maven. هذه ليست نقطة لصالحهم.
كان Ant / Maven محبوبًا ثم كره الكثير من مطوري جافا. XML هو بناء جملة مطول للغاية يجب التعامل معه.
لكن القاتل الحقيقي هو لوكين. نعم ، يمكنك استخدام msbuild للقيام بأشياء معهم ولكن بناء الجملة مصمم حقًا ليس للمطور لقراءتها / تحريرها ولكن لـ IDE لتسلسل الحالة إلى. لا يعني وجود عداء لسطر الأوامر أن التنسيق صديق للمطورين. طالما بقيت في VS ، فلن تلاحظ ذلك حقًا. بمجرد المغادرة على الرغم من أنه لم يعد مريحًا. ملفات csproj هي أحد الأشياء التي أتمنى أن أتخذها. سلكت الشبكة مسارًا مختلفًا عن java في.

مصدر

أعتقد أنه من المهم التمييز بين MSBuild والطريقة التي يستخدم بها Visual Studio حاليًا MSBuild. لقد قمت بتحرير ملفات MSBuild يدويًا لسنوات واستخدامها في جميع مشاريعي. على سبيل المثال https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

ملفات csproj التي ينشئها Visual Studio سيئة للغاية ، ولكن إلقاء اللوم على MSBuild يشبه القول C # هو حماقة لأنك رأيت منشئ رمز ينشئ رمزًا قبيحًا به مرة واحدة.

darrelmiller أوافق.

دعنا ننتقل إلى الأمام 6 أشهر ونرى ما إذا كانت لحظة "أخبرك ذلك" أو أكثر من لحظة "تهرب من رصاصة".

بعد استدعاء shawnwildermuth على مدونته ، سأضع سنتي 2:

لا أفهم لماذا هذه صفقة كبيرة. يسعدني العودة إلى csproj المستند إلى XML ، للأسباب التالية:

  • تحرير JSON يدويًا ليس أكثر طبيعية / أسهل من XML. هو في الواقع IMHO المعاكس. يعطيني كل محرر غبي إكمال علامة XML ، كما أن اكتشاف خطأ في التنسيق يدويًا أسهل وما إلى ذلك. JSON ليس أسهل إذا كان علي كتابته يدويًا. قولي هذا يقودني إلى النقطة 2 ...
  • لماذا هناك الكثير من الجلبة حول تحرير ملف مشروع باستخدام محرر في المقام الأول؟ تحرير ملف مشروع ليس حيث أريد أن أقضي وقتي كمطور. يجب أن يكون هذا شيئًا لمرة واحدة في بداية مشروع جديد ، ولكن بعد ذلك لا ينبغي أن يحدث في كثير من الأحيان IMHO. إذا كان عليّ تعديله باستخدام JSON أو XML أو YAML أو TOML أو أيًا كان ما يتخيله أي شخص في ذلك الوقت ، فهذا غير ذي صلة بي تمامًا.
  • الشيء الوحيد الذي أود تجنبه هو ربط NuGet مع ASP.NET . NuGet رائع ، أنا أحبه وأريد أن يعمل ASP.NET الخاص بي بشكل جيد للغاية ، لكن ليس مطلوبًا لتشغيل ASP.NET. نعم ، قد أحتاج إلى سحب الثنائيات من موجز NuGet للحصول على ميزات MVC ، وما إلى ذلك ، ولكن ما إذا كنت أفعل ذلك عبر موجز NuGet الرسمي ، أو إذا قمت بسحب المصادر ، فقم بتجميعها محليًا ونسخها ولصقها في يجب أن يكون مجلد المرونة التي تظل متاحة لي. لا أريد أن يكون ASP.NET أو csproj أو أي شيء آخر مقترنًا بإحكام بأنظمة الطرف الثالث "الداعمة". أريدهم أن يسمحوا بتكامل رائع ، لكن أبقوا الباب مفتوحًا للتخصيص ! لذلك آمل ألا يتم الإعلان عن حزم NuGet في ملف .csproj وألا يتم دمج nuget.json بإحكام في MSBuild.
    تكامل محكم خلف واجهة محددة جيدًا == عظيم.
    اقتران ضيق ، على افتراض أن هذا هو المعيار للجميع == BAD.
  • أخيرًا ، أود أن أقول إن project.json له علاقة قليلة جدًا بـ .NET Core و ASP.NET Core. لدى Core الكثير لتقدمه أكثر من ملف project.json. لم يكن Project.json ميزة جديدة ، لقد كانت محاولة لإعادة تصميم شيء كان موجودًا بالفعل بتنسيق مختلف. لا أهتم بهذا كثيرًا ، لأنني بصفتي مطورًا أركز على الميزات والإمكانيات الجديدة التي توفرها .NET Core لتطوير تطبيق رائع في السحابة بدلاً من التكوين الممل الذي يجب أن أقوم به من حين لآخر.

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

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

نتائج الاستطلاع النهائية: 100 إجابة ، لـ 9 ملايين من مطوري .NET بنسبة ± 10٪ مع ثقة 95٪.

هل أعجبك الانتقال إلى project.json؟
نعم ، لقد كانت واحدة من أكثر الميزات التي توقعتها بنسبة 19.19٪
نعم 39.39٪
لا 13.13٪
لا ، لقد كان اتجاهاً سيئاً لأخذ 16.16٪.

هل أنت سعيد بالعودة إلى MSBuild؟
نعم ، يمكنني الآن التفكير في اعتماده 9.09٪
نعم 16.16٪
لا 30.30٪
لا ، هذا يجعلني أتساءل عن الاتجاه الذي يتخذه .NET Core بنسبة 29.29٪
لا تهتم 15.15٪

هل تعتقد أنه سيتم تحسين MSBuild
تحسن؟ إنها بالفعل مثالية. 1.01٪
نعم 63.64٪
لا 12.12٪
إنه معطل بشكل أساسي ، كيف يمكن تحسينه؟ 20.20٪
لا تهتم 3.03٪

هل تعتقد أن هذا القرار اتخذ بشكل صحيح؟
نعم ، أخذ الفريق الملاحظات على متن الطائرة وغيّر الاتجاه عندما اضطروا إلى 20.41٪
نعم 6.12٪
لا 24.49٪
لا ، اتخذ الفريق قرارات غير خاضعة للمساءلة وباب مغلق ودون إشراك المجتمع 39.80٪
لا تهتم 9.18٪

كيف يؤثر هذا القرار على إدراكك لـ .NET Core؟
يحسنها ، لقد اقتربوا أخيرًا إلى العقل 13.00٪
يحسن 11.00٪
يزداد سوءًا 42.00٪
يفاقم الأمر ، يجعلني أتساءل عن الأمر برمته 18.00٪
لا تهتم 16٪

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

في الواقع ، كما هو موضح ، يمنحك 100 شخص هامش خطأ بنسبة ± 10٪ مع ثقة بنسبة 95٪. ما هو مستوى الثقة الذي تحتاجه لترى أنك ترى انعكاسًا حقيقيًا؟ هل يجب علينا مسح جميع المطورين البالغ عددهم 9 ملايين؟

هل الـ 800 صوت في UserVoice لتوسيع project.json إلى بقية VS لا تُظهر الاتجاه أيضًا؟

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

سيكون لديهم وصول أفضل بكثير من إجراء مسح خاص لي. سأحتاج إلى ترقية خطة SurveyMonkey الخاصة بي للوصول إلى أكثر من 100 نتيجة ، بتكلفة بالنسبة لي ، حتى أتمكن من إجراء استطلاع كان يجب على Microsoft إجراؤه بنفسها!

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

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

في الواقع ، ليس لدي أي متابعين على Twitter تقريبًا ، هؤلاء هم في الغالب من أتباع .NET Core devs الذين قمت بنشر تدفقات Twitter الخاصة بهم.

ومرة أخرى ، من المؤكد أن الأشخاص المناسبين للقيام بمثل هذا الاستطلاع هم Microsoft؟ لماذا يُترك لي أن أكون الشخص الوحيد الذي يسأل الناس عما يريدون؟

لماذا لا يأبه مرض التصلب العصبي المتعدد بما يعتقده الناس؟

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

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

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

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

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

shederman بينما أتفق مع نتائج الاستطلاع الخاص بك ، من الواضح أن أسئلته مائلة في الاتجاه المفضل للبقاء بتنسيق w / json ، وهذا لا يجعله مسحًا جيدًا حقًا. لقد تناولته من أجل المتعة ، ولن آخذ نتائجه على محمل الجد (آسف). أتساءل لماذا لا يمكننا الحصول على كليهما - اجعله اختياريًا بطريقة أو بأخرى ، لأنني لست من محبي msbuild أو تلك الأشياء الأخرى. أنا أحب Json ، إنه صديقي.

أتفق معك في أنه ليس مسحًا مثاليًا. لقد قمت بإنشائه في غضون 5 دقائق. النقطة هي: لماذا أقوم بإنشائها؟

لماذا لا تهتم Microsoft بمعرفة ما يعتقده الناس؟

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

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

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

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

أطلب من Microsoft المدافع والمتعاطف (MVPs أو أعضاء المجتمع) ، يرجى التحلي بالواقعية في هذا الوقت.

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

لو أنهوا واجباتهم المدرسية لعلموا أن 60٪ من المطورين كانوا ضد هذه الخطوة ،

سوف يفاجئني إذا كان أكثر من 20٪ من المطورين في النظام البيئي .net يعرفون بوجود project.json. ننسى أحيانًا أننا نعيش قليلاً في فقاعة مطور ، نركب في طليعة التطورات التقنية الجديدة.

أعتقد أن الكثير من جاذبية project.json تكمن في بساطته. ومع ذلك ، إذا كنت تتابع تطوره منذ تقديمه لأول مرة في يوم ASP Net Insiders قبل 3 سنوات ، فقد بدأ في تراكم المزيد من التعقيد حيث يحاول دعم المزيد من حالات الاستخدام. من أجل دعم النظام البيئي .net بأكمله ، أخشى أن يتم فقد الكثير من البساطة المحبوبة.

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

سوف يفاجئني إذا كان أكثر من 20٪ من المطورين في النظام البيئي .net يعرفون بوجود project.json.

أراهن أن أقل من 20٪ من المطورين في .net eco يعرفون عن MVC و Web Api. أكثر من 70 شخصًا يستخدمون WebForms و WCF و WebService. مرة أخرى ، أطلب من مدافع Microsoft ومتعاطفًا أن يكون واقعياً

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

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

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

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

لماذا تفعل هذا بعد RC2؟ أين جاء هذا من؟ هل كان لاقتناء Xamarin علاقة بهذا؟ هل كان التكامل هو dotnet-cli ؟ هل كان عميلاً كبيرًا؟ من تعرف...

يمكنني أن أشرح للجماهير أن RC1 -> RC2 كان الأفضل. موحد مع dotnet cli. لكن مشروع json التغيير؟ ليس لدي ما أقوله لشرح ذلك. فقط لا أعرف. الناس مرتبكون وليس لدي حجج مقنعة لهم.

لماذا تفعل هذا بعد RC2؟ أين جاء هذا من؟ هل كان لاقتناء Xamarin علاقة بهذا؟ هل كان التكامل dotnet-cli؟ هل كان عميلاً كبيرًا؟ من تعرف...

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

darrelmiller آسف ، عندما أقول 60٪ ، أعني 60٪ ممن ردوا على الاستطلاع.

GuardRex أنت على حق تماما. المنظمة الوحيدة التي يمكنها أن تقدم لنا نتائج مناسبة هي مرض التصلب العصبي المتعدد ، ولا يبدو أنهم يهتمون.

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

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

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

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

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

نتائج الاستطلاع النهائية: 100 إجابة ، لـ 9 ملايين من مطوري .NET بنسبة ± 10٪ مع ثقة 95٪.

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

abcplex : لا يعني المصدر المفتوح أن عليك القفز في كل مرة يفتح فيها 16 شخصًا مشكلة على GitHub ويصرخ القفز.

MaximRouiller تقوم ملاحظات Standup بعمل جيد جدًا في شرح الدافع وراء التغييرات. والواقع ، كما قرأته ، هو أنه يتم استبدال xproj بـ csproj ومن المرجح أن يتم إعادة تسمية project.json باسم nuget.json وسيتم نقل بعض العناصر من project.json.

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

بالنسبة لي ، تبدو هذه العملية الأكثر شمولاً وشفافية التي يمكن أن تحدث.

darrelmiller هذا ، علي أن أتفق معك. شفافة جدا.

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

فقط الوقت سيخبرنا الآن.

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

هذا يؤثر على المتبنين الأوائل أكثر من أي شخص آخر.

قراءة JSON لطيفة ، ولكن فقط عندما تكون بسيطة. </system> أسهل في الفهم من ]} في رأيي.

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

هل يجب أن تكون مناقشة حول JSON مقابل XML؟ لا يهم حقا IMHO
(بالتأكيد ، أنا شخصياً أحب JSON أكثر من XML ولكن هذا ليس مهمًا)

ما يعجبني حقًا في ASP.NET Core هو أنه مفتوح جدًا ومستقل عن Visual Studio وأي IDE آخر. إذا استمر تقديم هذا ، فلا مشكلة لدي في هذا القرار.

هناك الكثير من المناقشات السامة التي تدور حول هذه القضية ، والتي أشعر أنها تسبب في إغفال الكثير من الناس. يبدو أن الحجة العامة هي "MSBuild سيئة!" ولكن لم يتم التوصل إلى فهم كافٍ لما هو جيد / سيئ في كلا النهجين.

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

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

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

ونعم ، نقوم بتحرير ملفات المشروع مباشرة وكنا نقوم بذلك بشكل مؤلم قبل project.json. يدور برنامج Msbuild حول المعرفة القبلية ويجعل إتقانها صعبًا بعض الشيء.

و "سيسهل الترحيل من .net 4.5 إلى .net core" يبدو غير أمين بعض الشيء. هذه بالتأكيد ليست نقطة الألم ...

لن تكون هي نفسها ملفات csproj التي كانت لدينا لسنوات.

هل ستكون XML؟ نعم ، اعتقدت ذلك.

تعود الفائدة الرئيسية والسبب الرئيسي وراء إعجاب معظم الأشخاص بتنسيق project.json إلى عدم وجود قائمة الملفات هذه.

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

ألق نظرة على xproj اليوم وستكون لديك فكرة إلى حد كبير عما يمكن توقعه من csproj "الجديد"

ليس لدي xproj اليوم. لماذا احتاج مثل هذا الشيء؟

المناقشة الحقيقية ليست ولا ينبغي أن تدور حول "مدى سوء MSBuild"

لماذا لا ينبغي أن يكون هذا هو النقاش؟ كان Turfing MSBuild نقطة إضافية رئيسية لاعتمادي لـ .NET Core. وافق 20٪ من المستطلعين (على ما يبدو) في استبيان غرفة الصدى المنحاز وغير العلمي (على ما يبدو) على أنه معطل بشكل أساسي.

shederman ردك هو بالضبط نوع المناقشة السامة التي أشير إليها. أنت تقدم ادعاءات عامة فقط (مثل "MSBuild سيئ!") لكنك لا تدعمها بأي نوع من المناقشة البناءة.

هل ستكون XML؟ نعم ، اعتقدت ذلك.

نعم. و؟ إذا كانت مشكلتك هي أنك لا تحب _XML_ ، فهذا عادل بما فيه الكفاية. إذا كنت تعتقد أن JSON يتفوق على XML ، فاستمر في البحث عن أسباب ذلك ولكن هذا لا علاقة له بـ _ بنية المشروع _ وكل ما يتعلق بالصياغة. لسوء الحظ ، لكل من XML و JSON مكانهما في العالم ، وهناك إيجابيات وسلبيات مميزة لكليهما ولن تكون هناك إجابة "صحيحة" نهائية لأيهما أفضل. مرة أخرى ، إذا كنت مكانك ، فسأركز على الاختلافات في _ هيكل المشروع_ مع هذه الخطوة.

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

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

ليس لدي xproj اليوم. لماذا احتاج مثل هذا الشيء؟

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

لماذا لا يكون هذا هو النقاش؟ كان Turfing MSBuild نقطة إضافية رئيسية لاعتمادي لـ .NET Core. وافق 20٪ من المستطلعين (على ما يبدو) في استبيان غرفة الصدى المنحاز وغير العلمي (على ما يبدو) على أنه معطل بشكل أساسي.

نظرًا لأنك لا تناقش في الواقع _MSBuild_ ، فأنت تناقش الطريقة التي تعامل بها Visual Studio تاريخيًا مع مشاريع MSBuild - والتي اعترفت Microsoft نفسها بأنها ضعيفة. يدعم MSBuild في الواقع كل ما هو مطلوب بالفعل - بما في ذلك عدم الاضطرار إلى سرد كل ملف في المشروع.

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

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

abcplex هل ستساهم بأي شيء في المحادثة بخلاف الشتائم وتوجيه أصابع الاتهام؟

حتى الآن لم تفعل شيئًا سوى الشكوى من التغيير دون ذكر سبب واحد لمشكلتك الفعلية فيه.

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

abcplex التغيير لا يحدث في RTM. سيكون تغييرًا تدريجيًا بعد RTM . كل ما يحدث في RTM هو إعادة تسمية xproj الخاص بك إلى csproj - حرفيًا لا شيء آخر يتغير وسيتم إجراء التغييرات على مراحل ، مع ترحيل الأدوات لتغييراتك نيابةً عنك.

توافق على أن JSON vs XML (مقابل XAML ، كما هو الحال في Standup Blog Post ، يطلب بعض الأشخاص ذلك) هو صرف الانتباه عما ينبغي أن يكون من مزايا أي نوع من التوافق العكسي مع الأدوات السابقة.

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

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

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

  • يجب أن يكون قابلاً للتحرير / القراءة
  • يجب أن تسمح للتعليقات
  • يجب أن يكون تصريحي
  • يجب أن تكون قائمة بذاتها
  • يجب تصميمه لتقليل تعارضات الدمج / تبسيط الدمج ، إن أمكن
  • يجب أن تكون قابلة للتوثيق بالكامل (مع تطبيق مبدأ الاحتواء الذاتي على الوثائق)
  • يجب أن تكون مستقلة عن الأداة

و "سيسهل الترحيل من .net 4.5 إلى .net core" يبدو غير أمين بعض الشيء. هذه بالتأكيد ليست نقطة الألم ...

متفق عليه 100٪. اسمحوا لي أن أوضح التحديات التي واجهتنا: الصعوبات الوحيدة حتى الآن مع ترحيل قواعد الرموز كانت فقدان بعض مكتبات فئة .NET (بالنظر إليك System.Drawing) ، تحفظ فرق Microsoft في دعم .NET core (بالنظر إليك DocumentDB) والتغييرات القياسية التي يمكن توقعها بين الإصدارات الرئيسية.

لم يكن project.json مشكلة في أي وقت. في الواقع ، كان هذا من الفوائد. كما سبق أن تكون قادرًا على تفريغ MSBuild إلى تفاصيل غير مرئية تحدث بطريقة سحرية عند Ctrl + Shift + B.

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

  1. أنا لا أحب XML. إنه تنسيق سيء لملفات المشروع والتكوين. لقد كانت فكرة سيئة عندما تم تقديمها خلال مرحلة "XML لكل شيء" ، وهي فكرة سيئة الآن.
  2. أجد أن ملفات JSON تدمج أفضل بكثير من ملفات XML. أقبل أن هذا رأي ، لكنه رأيي ، وهو قائم على تجربتي.
  3. أنا أستخدم vscode الذي لا يحتاج ولا يستخدم ملفات xproj. _That_ هو المشهد الحالي الخاص بي ، وأنا لا أريد أو أحتاج إلى ملف xproj الذي لا يعني شيئًا بالنسبة لي.
  4. لا ، أنا أناقش MSBuild. لقد فعلت الكثير من الأشياء مع MSBuild و Team Build. لم يكونوا ولم يكونوا سهلين
  5. يجعل MSBuild حتى المهام البسيطة صعبة. أقترح عليك أن تنظر إلى البدائل ، ولا تتأرجح من قبل MSBuild. بشكل خاص ، انظر إلى طريقة عمل البلع و sbt.

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

أنا لا أحب XML. إنه تنسيق سيء لملفات المشروع والتكوين. لقد كانت فكرة سيئة عندما تم تقديمها خلال مرحلة "XML لكل شيء" ، وهي فكرة سيئة الآن.

لا شيء من هذا يفسر لماذا هي فكرة سيئة.

أجد أن ملفات JSON تدمج أفضل بكثير من ملفات XML. أقبل أن هذا رأي ، لكنه رأيي ، وهو قائم على تجربتي.

لقد مررت بدمج json. وكابوس. في تجربتي ، تزداد فرص حدوث دمج إشكالي مع _size_ الملف ، بغض النظر عن التنسيق.

أنا أستخدم vscode الذي لا يحتاج ولا يستخدم ملفات xproj. هذا هو المشهد الحالي الخاص بي ، ولا أريد أو أحتاج إلى ملف xproj لا يعني شيئًا بالنسبة لي.

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

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

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

لا ، أنا أناقش MSBuild. لقد فعلت الكثير من الأشياء مع MSBuild و Team Build. لم يكونوا أبدًا ممتعين ، ولم يكونوا سهلين أبدًا ، وقد شاركوا دائمًا في المصارعة مع الخنزير في الوحل. أكره MSBuild ، وأنا بالتأكيد لست وحدي.

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

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

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

تخيل مستقبلاً حيث يتعين عليك التعامل مع ملف مشروع قائم على XML

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

ماذا عن:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

أو ربما

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

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

أقترح عليك التوقف عن رمي ألعابك من عربة الأطفال

لا اريد :-)

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

[تم تعديله لإزالة الرذيلة]

shederman : تظهر هنا إنشاء ملفات تعريف ؛ أريد الابتعاد عن بناء التعريفات كتعريف للمشروع. هناك مساحة لتحديد التفاصيل الثابتة حول مشروع / قطعة أثرية سيتم إنشاؤها بشكل مستقل عن التعليمات الخاصة بكيفية إنشائها. إن الدمج بين الاثنين هو أحد المشاكل الرئيسية في استخدام ملفات MSBuild كملفات مشروع.

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

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

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

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

أعتقد أن ما لا أفهمه هو هذا: أظهر لي بعض حالات الاستخدام التي تم تحسينها باستخدام MSBuild كنظام مشروع بدلاً من مجرد عمل project.json. لا اراه. ربما تكون حالات الاستخدام الخاصة بي بسيطة للغاية ، لذا أرني بعضًا منها.

shederman تشير ملاحظات الوقوف إلى الحاجة إلى التمكن من مشاركة ملفات المصدر عبر المشاريع

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

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

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

رأيي فقط

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

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

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

لذلك ، إما أننا نبذل الجهد ونفصل نظام بناء المشروع json ، أو ننتقل إلى نظام بناء آخر (FAKE؟) ، أو أن نتخلى عنه ، أو تستخدم نظامًا أساسيًا آخر. أعتقد أنني عدّدت جميع الخيارات هناك.

shederman MSBuild كان مفتوح المصدر منذ أوائل عام 2015 ،

يا للهول. أنا قلق بشأن ما إذا كان يجب أن نفعل هذا ، وقد ذهبوا وفعلوه ...

تشعر وكأنك شخص يشاهد فرانكنشتاين الوحش وهو يندفع بعيدًا. مهتم ، مفتون ، مهتم ، وأكثر من مجرد اشمئزاز :-)

darrelmiller تذكر ملاحظات الوقوف الحاجة إلى القدرة على مشاركة الملفات المصدر عبر المشاريع

هل حقا؟ لا يزال الناس يفعلون ذلك؟ أعني أنني اعتدت القيام بذلك من أجل AssemblyInfo.cs ، وبالعودة إلى العصور المظلمة ، كنا نضع مفتاح الاسم القوي في ملف مصدر مشترك.

حسنا، هذا هو حال الاستخدام، ولكن الآن أنا حقا لا أريد أن أسمع حالة استخدام لحالة الاستخدام. مفتون.

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

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

كل ما عليك فعله هو قبول XML بدلاً من JSON ، لمعرفة الفوائد التي يمكن أن تكون ، لكنك لا ترغب في لعب هذه اللعبة لأن كل ما تريد فعله هو التحدث عن مدى سوء لغة XML دون توضيح السبب في الواقع.

يا للهول. أنا قلق بشأن ما إذا كان ينبغي علينا القيام بذلك ، وقد ذهبوا وفعلوه ...

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

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

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

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

مشكلة الدمج هي قضية واحدة فقط. الابتعاد عن MSBuild هو شيء آخر.

لماذا هذا حتى مشكلة؟ أنت تكره MSBuild ، لقد فهمنا ذلك ، ولكن ما الذي تكرهه في MSBuild بصرف النظر عن حقيقة أنه _ يجرؤ على استخدام XML؟

إحدى النتائج المجنونة لهذا السيناريو هي أنهم سيقضون الوقت والجهد في نقل MSBuild إلى Linux و OSX! تخيل ذلك.

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

أحصل على أسبابهم ، لكن أسبابهم لا تعمل معي على الإطلاق ، ولا تعمل مع الكثير من الناس.

لكن ربما يعملون لصالح أشخاص أكثر منك؟

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

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

إنهم يتخذون قرارًا بشأن project.json استنادًا إلى الحالات المتطورة التي يدعمها MSBuild

هذا يتجاوز بكثير حالات _edge_ ، من السخف أن نقترح أن Project.json يكاد يكون مثاليًا.

بالتأكيد لا يحتاج أي شخص يقوم بمشاريع ASP.NET إلى تلك الحالات المتطورة.

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

الحقيقة هي أن هذا ليس مشروعًا مفتوح المصدر حقًا

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

نظرًا لمدى كبر كل شيء وتكامله ، فمن الصعب التفكير في تعلم الشفرة ذات الصلة.

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

لذلك ، إما أننا نبذل الجهد ونفصل نظام بناء المشروع json ، أو ننتقل إلى نظام بناء آخر (FAKE؟) ، أو أن نتخلى عنه ، أو تستخدم نظامًا أساسيًا آخر. أعتقد أنني عدّدت جميع الخيارات هناك.

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

العودة إلى الموضوع ....

لقد أعطيته مزيدًا من التفكير وأنا الآن أميل إلى أن يصبح project.json nuget.json ، مع الحفاظ على إدارة التبعية كما هي الآن. إنه يعمل جيدًا الآن ، التحسس موجود بالفعل ويتوافق مع أشياء مثل gulp و npm.

دع csproj يحدد ببساطة الأجزاء الثابتة.

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

Project.json ليس مجرد ملف json.
csproj ليس مجرد ملف XML.

IMHO كثير من الناس ، مثلي ، كانوا متحمسين لرؤية Microsoft ، وعلى وجه التحديد فريق Asp.Net ،
تحرير أنفسهم من التعليمات البرمجية القديمة / المفاهيم / الأنظمة / الأدوات / المظاهر / ...

هذا أعطانا "الأمل"!

لقد قمت بتطوير Asp.Net منذ أول معاينة بتات. أنا في الغالب أحب العمل معها. لكن بعد 15 عامًا ،
تبدو الأشياء "القديمة" ، مثل XML ، ثقيلة حقًا وعفا عليها الزمن. الإدراك مهم.

بدون XML وعلى الأقل استخدام JSON بدلاً من ذلك ، تكون "سعادة المطور" أكبر بكثير.
يمكنني العمل مع الأشياء ، قرر بقية العالم استخدامها. يوجه IDE الخاص بي هذه الأشياء على التنسيقات القديمة.
لم يعد يتعين علي دفع ضريبة "The Angle Bracket Tax".

لا تعد إزالة project.json مشكلة كبيرة ، لكن القيام بذلك خلف أبواب مغلقة في اللحظة الأخيرة تقريبًا يقتل هذا `` الأمل '' على الفور.

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

لمعلوماتك: يتمتع "Asp.Net Core" بالعديد من الميزات الرائعة. أنا أحبه في الغالب.
فريق Asp.Net رائع ولا يمكنني أن أكون أكثر فخراً لكوني مطور Asp.Net.

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

فقط سنتان.

أعتقد أننا يمكن أن نتفق جميعًا إلى حد كبير على أن msbuild (خاصة كيفية استخدام VS له) ليس مثاليًا ، وبينما كنت متحمسًا لـ project.json ، كان الأمر يتعلق أكثر بإصلاح MS للكثير من نقاط الألم الخاصة بي ولأكون صادقًا طالما إنهم يفعلون ذلك ، ربما لن أهتم كثيرًا بالطريقة التي فعلوها بها.

  • لا تعمل عمليات دمج csproj بشكل جيد ، أجد نفسي بحاجة إلى إصلاح عملية دمج معطلة يدويًا كل أسبوعين. ستساعد إزالة قائمة الملفات من csproj كثيرًا هنا.
  • لا تتوافق مراجع NuGet ومراجع Project دائمًا ، مرة أخرى قد يكون ذلك بسبب عمليات الدمج المعطلة. في كلتا الحالتين يكون التشخيص والتصحيح أمرًا مزعجًا.
  • في بعض الأحيان ، أحتاج إلى الدخول في عملية الإنشاء (لست متأكدًا من كيفية عمل ذلك في project.json) ولكن الحاجة بأكملها إلى التفريغ / التحميل تجعل تصحيح أخطاء البرنامج النصي عملية مؤلمة.

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

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

كل ما تريد فعله هو التحدث عن مدى سوء لغة XML دون توضيح السبب

ليس عادلاً تمامًا ، أريد أيضًا أن أتحدث عن مدى ضرر MSBuild :-)

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

أسوأ من ذلك - لا توجد تعليقات

أعتقد أن العديد من الأشخاص قد عرضوا بدائل هنا. HJson هو خيار واحد فقط. ياي! لا يتعين علينا إعادة التفكير في الأمر بعد كل شيء ؛-)

أنت مستاء جدًا من هذا التغيير

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

لا تفهموني خطأ ، لا تحب XML ، لا تحب MSBuild. لكن أكره أن يُقال لي أن أتبنى شيئًا أحبه حقًا ثم قيل لي في اللحظة الأخيرة إنه يتم إبعاده. لا تحرك الجبن!

أظن أن غالبية الأشخاص المستاءين من التغيير جميعهم من مطوري الويب

أم ، نعم ، قد يكون ذلك لأنهم المطورون الوحيدون الذين قدمت لهم project.json. في أخبار أخرى ، لم ينزعج مطورو Swift أيضًا من القرار. أعني أعتقد ما تقوله هنا:

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

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

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

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

ما الذي تكرهه في MSBuild بصرف النظر عن حقيقة أنه يجرؤ على استخدام XML

إنها معقدة للغاية
إنه عدم تطابق المعاوقة ، ويدفع المنطق القائم على الاستدلال في المواقف التي يتعامل فيها الناس بشكل أساسي مع منطق حتمي أو تصريحي.
يا إلهي ، هل نظرت بالفعل إلى ملفات MSBuild؟ حسنًا ، آسف ، قلت بصرف النظر عن استخدام XML ؛-)
تعتبر الطريقة التي يتم بها الإعلان عن الخصائص والعناصر غير بديهية لأي شخص لا يستخدمها بانتظام
يتم استخدامه كحجم واحد يناسب جميع الأدوات التي تحاول القيام بالمهام التي يجب القيام بها في البرامج النصية. المسامير مطرقة.
في عدد كبير من الحالات ، يمكن التعبير عن كل ما يفعله في ملف كبير في ثلاثة أسطر من النص على الأكثر
قمامة VS التي تتساقط فيها. سمعت أنه سيتم إصلاح ذلك. الانتظار مع بعض الخوف لمعرفة ما إذا كان سيتم قطع ذلك أيضًا. كما ذكرنا سابقًا ، أنا مجنون قليلاً بشأن الوعود الآن.

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

ما الاتجاه الذي تشير إليه

project.json هو أساس نهج مشروعنا الجديد وهو ما تم إبلاغه. لقد استثمرنا أموالًا حقيقية ووقتًا وألمًا على أساس هذا الالتزام.

لكن ربما يعملون لصالح أشخاص أكثر منك؟

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

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

أنت لا تهتم بأي شخص آخر غير نفسك ، مطور asp.net

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

لم أقل مطلقًا "تخلص من MSBuild تمامًا ، وفرض عملية الإنشاء الخاصة بي على جميع المطورين الآخرين". أنت الشخص الذي يقول "تخلص من project.json تمامًا ، وفرض MSBuild على جميع المطورين". كان لدينا نظامان للبناء في جميع المعاينات ، وكنا سعداء. كان مطورو الويب سعداء والمطورون الذين لا يستخدمون الويب كانوا سعداء.

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

أنت حقًا تحب حجة الوسط المستبعد.

يقبلون طلبات السحب

هل حقا؟ إذا أصدرنا طلب سحب ترك أداة إنشاء غير قائمة على MSBuild في وظيفة الأدوات الرئيسية ، والتي تقرأ فقط project.json ، فهل ستقوم بتضمينها في إطار العمل؟ هل حقا؟

حسنًا ، أنا أقرأ هذا أساسًا كـ ...

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

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

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

يمكنك محاولة المساهمة بشيء بناء في المحادثة.

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

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

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

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

واو ، بجدية. هل يمكننا إنهاء هذا؟

سؤال بسيط: هل ستأخذ المعارضة في الاعتبار وتعيد النظر في القرار بناءً على المعلومات الجديدة؟

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

اقتراح: Microsoft fork لدعم عملاء MSbuild csproj القدامى. # كاريوناسنورمال

أنا أيضًا مطور .Net منذ فترة طويلة ، كنت أعمل بمعاينات 1.0 قبل أن يخترع التسويق اسم .Net. دون الضياع في الأعشاب ، ها هو سنتي.

يمكنني أن أمضي بقية حياتي دون أن أرى ملف تكوين xml آخر وأن أكون سعيدًا تمامًا.

لا أريد تهيئة xml. في أى مكان. أبدا.

لا يهمني إذا قام الفريق بإصلاح كل نقطة ألم في csproj ؛ إذا كان لا يزال ملف تهيئة xml عند الانتهاء ، فأنا لست مهتمًا. يمكنك أيضًا الاحتفاظ بنظام المشروع .net 4.5.

أما بالنسبة لـ MSBuild ... يمكن أن يموت MSBuild في حريق جديد.

لقد فهمت أنها قوية ، وهناك الكثير من الأدوات حولها ، ولكن خارج MS ، فقط الخبراء العميقون في MSBuild يعرفون بالفعل ما يفعله أو كيف يعمل. في كل مرة أضطر فيها إلى إدخال أي تخصيص في عملية الإنشاء ، ينتهي بي الأمر بخسارة 3 إلى 5 أيام من حياتي المهنية. نادرًا ما يمكنني الحصول على أي شيء ، حتى الأشياء التافهة مثل تضمين مجلد فارغ في الإخراج ، للعمل بشكل صحيح في نشر VS و VS وخادم CI الخاص بي في نفس الوقت.

لقد فهمت ... إذا لم يكن لديك الوقت لبناء بديل جيد لـ MSBuild للإطار الزمني asp.net core 1.0 ، فتأكد من ... ابتكار طريقة لمواصلة الاستفادة من MSBuild حتى asp.net core 2.0 دورة؛ ولكن على الأقل استمر في العمل في اتجاه استبدال هذا الغائط بشيء قد يتمكن بقيتنا من العمل معه.

في غضون ذلك ، حاول الاحتفاظ بأكبر قدر ممكن من التكوين في json. لا أهتم على وجه التحديد إذا كان من project.json ، أو شيء جديد وأفضل. إذا لزم الأمر ، اجعل الأدوات تنشئ ملفات MSBuild قديمة بسرعة عند / إذا لزم الأمر - قم بلصقها في مجلد فرعي في مكان ما أو شيء ما.

ما لا أريده هو أن نظام الملفات الخاص بي يبدو كالتالي:

  • bower.json
  • package.json
  • nuget.json
  • كل شيء آخر
  • microsoft-old-ass.xml.csproj

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

ملاحظة. إذا كنت تسير على الاستمرار في تجاهل المعارضة، يمكنك يرجى تقديم ما يلي:

  • كيف يمكننا الوصول إلى قنوات Slack لمطوري أدوات البناء
  • عرض عالي المستوى للبنية والكود الحاليين ، وحيث سيتم إجراء التغييرات للانتقال إلى MSBuild / xproj حتى نتمكن من تخطيط نهجنا للحفاظ على البتات التي نريدها ودمجها جيدًا.
  • ضمان سحب طلبات الخبز في الأدوات المستندة إلى project.json سيتم قبولها إذا استوفت معايير الجودة
  • التأكد من أنه إذا تم استيفاء معايير الجودة ، فيمكننا تضمين دعم "dotnet build" لمشروع كامل ، بالإضافة إلى قوالب ASP.NET البسيطة ، وربما بعض القوالب لأنواع المشاريع القياسية أيضًا.

"كن بناء" ، "لا تساهم ، لا تحصل على صوت". حسنًا ، تحصل على ما تطلبه ...

@ Mike-EEE ، هل تريد إجراء تسلسلات Xaml لـ SimpleUseCaseBuild؟

بعد قراءة كل هذا توصلت إلى هذه الاستنتاجات:

  • جلبت project.json الكثير من التحسينات. لم يكن أي من هذا ممكنًا إذا تم ربط نواة .net و asp.net بالتعليمات البرمجية والأدوات القديمة
  • json (و json) ليست مثالية
  • xml vs json vs anyserializationlanguage عقيمة. ستكون المناقشات حول كيفية الاستفادة منها للإجابة على التحديات الأساسية .net أكثر إثارة للاهتمام
  • العودة إلى msbuild تعيد الإرث وربما يعني ذلك أننا لن نرى المزيد من التحسينات على نظام المشروع ، لأن فرق .net من المحتمل أن تفقد بعض حريتهم

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

ههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههههه : ابتسامة: ويا لها من مناقشة! حقا مدهش.

xml vs json vs anyserializationlanguage عقيمة. ستكون المناقشات حول كيفية الاستفادة منها للإجابة على التحديات الأساسية .net أكثر إثارة للاهتمام

نعم ، المهم بالنسبة لي هو نموذج الدعم المستخدم لوصف المشاريع و / أو ما تفعله ، وقد تطرق جزء من هذه المحادثة إلى ذلك. أرغب في رؤية نموذج مشروع / واجهة برمجة تطبيقات محسّن يسهل وصفه والعمل به (بغض النظر عن التنسيق الموصوف به - على الرغم من نعم أفعل: القلب: Xaml الخاص بي!). لدي مناقشة مفتوحة حول مستودع MSBuild هنا (https://github.com/Microsoft/msbuild/issues/613) فيما يتعلق بهذا وأيضًا في نظام مشروع Roslyn (https://github.com/dotnet/roslyn-project -النظام / القضايا / 37) كذلك إذا كانت مهتمة.

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

2 سنتي:

أعتقد أن هناك نوعين من الأشخاص يناقشان هذا التغيير:

  • المطورين الذين استخدموا VS & .NET لبناء أنواع مختلفة من المشاريع وعليهم دعم هذه المشاريع لفترة طويلة
  • المطورين الذين ليس لديهم مثل هذه الأمتعة ويريدون إطار عمل ASP.NET Core جديد ونظيف ورائع ومتعدد المنصات

أنا شخصياً في الفئة الأولى ، لذا أريد أن يكون ASP.NET Core الجديد متوافقًا مع أنواع مشاريع VS الأخرى قدر الإمكان ، والانتقال إلى حل csproj / msbuild "القديم" يعد فوزًا بالنسبة لي (+ my فريق وربما العديد من المطورين الآخرين). بهذه الطريقة سيكون الانتقال أكثر سلاسة ووضوحًا. ربما لا يتفق معي الأشخاص من الفئة الثانية (أو أنهم لا يهتمون).

المشكلة الرئيسية الوحيدة التي أراها الآن هي كيفية تعريف حزم NuGet والإشارة إليها. إنه لأمر مؤلم أن تضطر إلى الحفاظ على كل من ملفي package.config و csproj (كما ذكر JulianRooze بالفعل في https://github.com/aspnet/Home/issues/1433#issuecomment-218606377). هذا يجب أن يعاد تشكيله. من الناحية المثالية ، يجب أن يتم ذلك مثل @ cwe1ss المقترح في https://github.com/aspnet/Home/issues/1433#issuecomment-218519705). لقد كانت واحدة من أكثر التعليقات البناءة في هذا الموضوع راجع للشغل ...

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

Funbit محاولة تصنيف الناس لن تساعد. وأنا لا أنسب في أي من الفئات الخاصة بك. أنا مطور asp.net منذ الإصدار الأول بيتا. لقد توقفت تقريبًا عن أن أكون واحدًا منذ عامين ولكن. net core أعادني لأنه كان قائمة نظيفة وأفضل ما في عالم الشبكات والعقد.

أريد أن يكون .net الأساسي ناجحًا وليس تقنيًا مؤسسيًا قديمًا بدون اعتماد وبدون مجتمع.

من ناحيتي ، لا أهتم حقًا بهذا القرار ، فأنا لا أهتم كثيرًا بـ XML ، ولسرق الاقتباس: "الأقواس المتعرجة أفضل من الأقواس ذات الزوايا" ، لكنها لا تزعجني حقًا بالعودة إلى csproj / msbuild - أنا مرن يمكنني التعامل معها.

أرغب في ترديد بعض تعليقات shederman على الرغم من:

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

و

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

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

لكي نكون منصفين لشركة Microsoft ، فهم ليسوا الوحيدين الذين يقومون بهذا النوع من الأشياء بمشروع ترعاه الشركة ؛ هل تتذكر الانقسام في مجتمع nodejs (الذي تسبب في تفرع io.js)؟ لكنني أعتقد أنه عندما يتعلق الأمر بـ Microsoft ، يكون الوضع أسوأ كثيرًا.

فجر هذا الطريق غير متناسب مما كان مقصودًا في البداية.

1ajq1

فجر هذا الطريق غير متناسب مما كان مقصودًا في البداية

MaximRouiller هل أنت مطور ، يا

@ مايك- EEE أفعل. كنت أتوقع بعض الجدل المحتدم لكني رأيت الكثير من الهجمات الشخصية. :خائب الامل:

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

darrelmiller يبدو هذا مخيفًا بالنسبة لي ، لأنه يبدو أن هذا يعني أن إدراج الملفات في ملف csproj.

lokitoth ربما لا يوجد سبب يمنع الملفات المرتبطة من استخدام أحرف البدل الكرات أيضًا.

MaximRouiller أنا ، أيضًا ، مذنب @ shederman يعرف كيف shederman يمثل حيوان الترميز الداخلي الخاص بي ، ولكن كان ذلك قبل أن أعرف أن هناكCodingGorilla. : يضحك:

أعتقد أننا بحاجة إلى أن نذكر أنفسنا بأن ما نقوم به هو حقا العمل الشاق حقا، وأنه عندما يعمل ذلك! بل إن الوصول إلى هناك أكثر صعوبة. في تجربتي مع Silverlight (نعم ، لقد أحرقت baaaaaaad بذلك ، لذلك أعرف من أين يأتي shederman ) ، لقد ساعدني ذلك في رؤية أنني ربما لا أعرف _ كل شيء _ (أو حتى _ أي شيء _ في بعض الأحيان ، أشعر!) ولكي تبقى متفتح الذهن بشأن الأشياء. ما زلت أفشل. حتى عندما رأيت مبادرة project.json ، بذلت قصارى جهدي للإشارة إلى الفجوة التي كانت تخلقها ، ولكن ربما كانت قاسية جدًا مع الأشخاص الموجودين هنا في الريبو عند القيام بذلك.

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

حسناً ... كفى من الوعظ والرحمة لليوم. : stuck_out_tongue: العودة إلى slugfest المجدولة بانتظام!

هذا يبدو مخيفًا بالنسبة لي ، لأنه يبدو أن هذا يعني أن إدراج الملفات في ملف csproj.

بالإضافة إلى ذلك ، هل أنا الشخص الوحيد على هذا الكوكب الذي يقدر هذه الميزة؟ : stuck_out_tongue:

هذا يبدو مخيفًا بالنسبة لي ، لأنه يبدو أن هذا يعني أن إدراج الملفات في ملف csproj.

بالإضافة إلى ذلك ، هل أعتقد أن الشخص الوحيد على هذا الكوكب هو الذي يقدر هذه الميزة؟ : stuck_out_tongue:

@ Mike-EEE نعم ، أعتقد أنك كذلك. :غمزة:

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

shederman يعرف كيف يرمي!
😆

أنا لا أحاول. أتمنى ألا أهين أحداً رغم ذلك. حاولت جاهدًا أن أطارد الحجج فقط.

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

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

هل الغرض الرئيسي هو أن الأشخاص يريدون تحرير ملفات csproj لإضافة خطوات BeforeBuild و AfterBuild التي يريدون تنفيذها عند تصحيح الأخطاء في Visual Studio؟

@ مايك- EEE ربما ؛ أتذكر غالبًا أنه كان بمثابة ألم كبير في المؤخرة عند التعامل مع المشاريع التي تحتوي على عدد كبير جدًا من الملفات (مثل Expression Blend و Visual Studio XAML Designer وما إلى ذلك) لدرجة أننا قمنا بتبديلها لاختيار حرف البدل - وهو ما يفعله VS لا أعرف كيفية العمل بشكل صحيح ، مما يعني أنه في كل مرة أقوم فيها بإضافة ملف ، يتعين علي إعادة تحميل المشروع (أو تشغيل الخطأ "تمت إضافة هذا الملف بالفعل" عند الإنشاء)

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

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

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

لدي فضول حول حالات الاستخدام لتحرير ملفات csproj

بالنسبة إلى .csproj (كل ما قمت به ، وللغالبية ، عدة مرات)

  • إذا كنت بحاجة إلى الإشارة إلى أنواع UWP من تطبيق سطح المكتب
  • إذا كنت بحاجة إلى إصلاح VS كسر الأشياء باستخدام NuGet (خاصة حول إضافة ملفات a.targets و .proj / .props)
  • إذا كنت بحاجة إلى تغيير تخطيط الإخراج الذي تم إنشاؤه
  • إذا كنت تقوم بإعادة هيكلة المشاريع وإعادة تسمية التجميعات
  • إذا كنت تقوم بإعادة بناء ديون كبيرة مما يؤثر على الكثير من الملفات
  • إذا كان لديك تعارض دمج لأن عدة أشخاص يعملون في نفس المشروع ولا تستخدم أحرف البدل
  • إذا كنت بحاجة إلى فهم سبب عدم عمل الإصدار فجأة (تعديل: كان يجب أن أحدد - هذا أكثر من "لماذا أحتاج إلى أن يكون قابلاً للقراءة ، و" قائم بذاته "")
  • إذا كنت بحاجة إلى تصحيح تعارضات إصدار التجميع بسبب التبعيات المزعجة
  • إذا كنت تحاول إضافة ملف "مرتبط" (مشترك)

بالنسبة إلى project.json

  • إنشاء الملف من البداية يدويًا (مهم للغاية)
  • إضافة / إزالة حزم NuGet
  • تغيير الإطار الهدف
  • تغيير إصدار حزمة الإخراج

shederman أدرك أنك محبط ، لكن عندما ترد ب

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

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

@ Mike-EEE ألا يمكنك إنجاز نفس الشيء (بدون سرد كل ملف) باستخدام السمة / النمط Exclude ؟ للتسجيل ، غالبًا ما أفعل الشيء نفسه ، يكون مفيدًا جدًا عندما تريد فقط إزالة شيء ما بسرعة دون الحاجة إلى القيام بدورة الالتزام / التراجع.

للتسجيل ، أنا في الواقع أحب اقتراح @ Mike-EEE الذي كتب باستخدام Roslyn وأن يكون ملف المشروع AST متسلسلًا. ولكن فقط إذا تمكنا من تسهيل العمل باستخدام المفكرة فقط. (نعم ، أعني المفكرة ، وليس notepad ++ أو أي شيء آخر أكثر تقدمًا: هذا هو "اختبار الدخان" لإمكانية استخدام تنسيق ملف قابل للتحرير بواسطة الإنسان)

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

لذلك ، بشكل أساسي ، النظر إلى نموذج "إلغاء الاشتراك" بدلاً من "الاشتراك".

للراغبين في تحرير ملفات المشروع دون تفريغ .... https://twitter.com/migueldeicaza/status/730978470734401536

للراغبين في تحرير ملفات المشروع دون تفريغ ....

darrelmiller ما الذي

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

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

@ Mike-EEE كان الرد على تعليق ميغيل من ديفيد كين الذي يعمل على نظام المشروع الجديد. يعرف الفريق أن VS يجب أن يكون قادرًا على القيام بذلك أيضًا.

@ Mike-EEE أعتقد أن الشيء الخاص بي هو أنني أستطيع التعامل مع كل ما توصلوا إليه. يعد نظام مشروع MSBuild قويًا بما يكفي للقيام بأي شيء تقريبًا (ما لم يكن كما يقول shederman ، لا يمكن أن يكون XML فقط). أعتقد أن بعض الناس يخاطرون فقط بـ "يجب أن تكون طريقي أو أنها فاشلة" ، وكما قال شخص آخر (آسف نسيت من ، هذا الموضوع هو YUUUUUUGE!) "أحاول أن أكون متفتحًا ..." و فقط تكيف.

وإلى جانب ذلك ، قد تتعلم شيئًا جديدًا ، وهذا أمر جيد دائمًا. : ابتسامة عريضة:

neoKushan لقد

CodingGorilla في الواقع لحم بقري الرئيسي مع MSBuild. تعد XML مشكلة ، ولكنها ليست سيئة مثل MSBuild.

لقد عرضت القيام بالعمل بنفسي للحفاظ على دعم project.json جنبًا إلى جنب مع xproj. من يهتم أكثر هل العمل صحيح؟

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

ثم ، إذا كنت تحب MSBuild وتريد أن تتمتع بالطاقة ، فأنت تستخدم xproj.

وإذا كنت تحب الأدوات التي تم تصميمها من أجل ASP.NET الأساسي ، فيمكنك الاستمرار في استخدامها.

يستخدمون نفس المترجم الأساسي.

ولا ينبغي أن يكون هناك الكثير من العمل على أي حال. كل ما علي فعله هو إعادة صياغة التعليمات البرمجية التي يتم إهمالها في أمر آخر.

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

sandorfr أوافق على أن كتابة ملفات MSBuild الكاملة التي تحدد _entire_ عملية البناء ليست أقل من الألم الهائل ، ولكن إذا لم أكن مخطئًا ، فهذا ليس ما نتحدث عنه بالفعل هنا - نحن نتحدث عن _ just_ المشروع بنية.

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

لا يزال هناك شيء يمنعك من استخدام نظام البناء الذي تختاره ، سواء كان CAKE أو TFS Team Services أو أيًا كان.

مرة أخرى ، هذا ينص على أن يقوم الفريق بذلك "بشكل صحيح".

VS ليس أفضل مثال وأعتقد أن التجربة التي يمنحك إياها VS هي ما يكرهه الكثير من الناس بشأن نظام مشروع MSBuild.

neoKushan هذا ما أشعر به حيال TFS Build و Xaml. Xaml رائع بشكل يبعث على السخرية (وسيظل يحب رؤيته يستخدم كتنسيق محتمل لـ "البرامج النصية" MSBuild) ، ولكن استخدامه في TFS Build منحه اسمًا سيئًا.

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

نظام مشروع MSBuild قوي بما يكفي للقيام بأي شيء

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

(تحرير: مضاف)

لا يزال هناك شيء يمنعك من استخدام نظام البناء الذي تختاره ، سواء كان CAKE أو TFS Team Services أو أيًا كان.

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

Haha yeah @ cwe1ss (بالحديث عن تحسينات الأدوات!) كنت أفكر فقط في أن GitHub مروع عندما تندلع الأمور في المحادثة. لدينا مثل 3 مواضيع هنا. وبدأت للتو واحدة أخرى. :خائب الامل:

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

هل أقترح أن ننتقل جميعًا إلى مواجهة المجتمع التالية يوم الأربعاء؟

فقط إذا كان shederman يمثل. أريد أن أراه يحطم المطورين وأفكارهم في الوقت الفعلي. مثل حدث WWE PPV!

أعتقد أن ميزة project.json على [اسم المشروع] .csproj لا تتعلق بالتنسيق. يتعلق الأمر بعدم الحاجة إلى التوافق مع الإصدارات السابقة مع جميع العناصر القديمة. سمح لها أن تكون بسيطة جدا. بافتراض أن داميان إدوارد وفريقه يمكنهم تحقيق جميع أهدافه المحددة ، فأنا لا أهتم حقًا بـ XML مقابل JSON مقابل YML مقابل ... ما يهمني هو البساطة وعدم الاضطرار إلى رؤية الأشياء الموجودة لنظام التشغيل Windows عندما أستخدم Linux .

glennsills لا أعتقد أن هناك الكثير من أي شيء في ملف مشروع MSBuild خاص بـ _windows_ ، فهو أكثر من كونه خاصًا بـ MS Build نفسه ، أو أنواع المشاريع الأخرى التي لا تهتم بها. ليست هناك حاجة حقًا إلى وجود مجموعة من العناصر الفارغة فقط لإبقاء MSBuild سعيدًا. آمل أن يخطط الفريق لقطع أكبر قدر ممكن من ذلك ، لكننا سنرى.

@ Mike-EEE فقط إذا كان shederman يمثل. أريد أن أراه يحطم المطورين وأفكارهم في الوقت الفعلي. مثل حدث WWE PPV!

سأحاول تحقيق ذلك. أحذرك من أنني أتحدث أبطأ مما أكتب ، لذا لا ترفع آمالك 😄

image

لذلك ، في خطر فتح علبة من الديدان ، بالنظر إلى https://github.com/dotnet/roslyn-project-system/issues/40 كيف سيشعر الناس حيال ملف csproj مختزل حقًا والذي يحتوي فقط (افتراضيًا ) الأساسيات الأساسية للمشروع؟

(من فضلك لا تحول هذا إلى خطبة "أنا أكره XML!").

ماذا عن "أنا أكره MSBuild الخطبة"؟

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

ماذا لو جعلنا MSBuild يقبل ملفات JSON؟ : يضحك: (لم أستطع المقاومة)

shederman من الصعب التعامل مع أي نوع من الخطابات على محمل الجد وأنا أفضل أن تأخذ Microsoft هذا _المناقشة_ على محمل الجد.

بالطريقة التي سيجري بها هذا في 5 سنوات ، ستتم برمجة Swift أو Java (!!) أو Node.JS أو Elixir. ؛)

هناك نوعان من التقنيات السيئة هذه الأيام في مشاريع .NET / الحلول / أيا كان. ملفات Nuget و .csproj. إذا كنت تعمل في فريق 5+ باستخدام Git (مثل GitFlow) فهذا كابوس كامل. "يا حماقة إذا نسيت تضمين الملف في .csproj" يصبح مملًا. يجب أن تعمل الأدوات على إصلاح ذلك ، كما يجب أن تحذرني الأدوات من وجود إصدارات DLL متضاربة ، ويجب أن تساعدني الأدوات في الدمج.

قطع الفضلات. بدا Project.json لطيفًا في البداية ، ولكن بعد ذلك حدثت السياسة والمشاعر.

يجب أن يطلق عليه MS Team اسم beta وليس RC.
يبدو أنني لا أستطيع الوثوق حتى عندما يتم إصدار RTM ، "إذا كان من الممكن أن يقرر MS Team شحن RTM2 الذي كسر كل شيء مرة أخرى.
أنا لست متشائمًا ولكن هذه الحركة حول .NET Core غريبة جدًا.

neoKushan سأحاول أن أكون

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

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

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

بالكاد طلب ثوري.

2 سنتي:

أعتقد أن هناك نوعين من الأشخاص يناقشان هذا التغيير:

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

المشكلة الرئيسية الوحيدة التي أراها الآن هي كيفية تعريف حزم NuGet والإشارة إليها. إنه لأمر مؤلم أن تضطر إلى الحفاظ على كل من ملفي package.config و csproj (كما ذكر JulianRooze بالفعل في # 1433 (تعليق)). هذا يجب أن يعاد تشكيله. من الناحية المثالية ، يجب أن يتم ذلك مثل @ cwe1ss المقترح في # 1433 (تعليق)). لقد كانت واحدة من أكثر التعليقات البناءة في هذا الموضوع راجع للشغل ...

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

أنا أيضًا أتوافق مع الفئة الأولى (المطورين الذين طوروا مشاريع / أنواعًا متعددة ويحتاجون إلى دعمهم لفترة طويلة). لدى صاحب العمل ملايين الأسطر من التعليمات البرمجية للمشاريع بتنسيق csproj ولدينا أيضًا منتجات أحدث تعمل على فرع ASP.NET RC1 و RC2 dev. تحذير عادل ، نحن أيضًا نستخدم MSBuild بشكل متقدم مع تجميعات مهام MSBuild المخصصة ، إلخ.

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

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

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

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

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

shederman لقد جعلت رأيك في MSBuild معروفًا جيدًا ، ولكن ما لم توضحه هو _ مشكلتك الفعلية مع MSBuild. هذا ما أجده محبطًا للغاية ، أريد فقط معرفة المشكلات الفعلية التي واجهتها مع MSBuild لأنني أشعر حقًا أنه يمكن معالجتها.

حسنًا ، أنت لا تحب XML ، حسنًا - النقاش بين JSON و XML ليس بالأمر الجديد ولن نحل هذا أبدًا هنا. ومع ذلك ، لا يمكن أن يكون هذا هو السبب الوحيد الذي يجعلك تكره MSBuild كثيرًا. ما هي المشاكل الفعلية التي واجهتها؟

السبب الذي أطرحه - والسبب الذي أواصل طرحه هو أن هذه هي المشكلات التي تريد Microsoft إصلاحها بالضبط وما لم نوضح ما هي المشكلات ، فلن يتم إصلاحها. تم بالفعل إصلاح العديد من الأشياء التي كرهناها بشأن MSBuild والتي نعرفها:

  1. إدراج كل ملف في المشروع - يتم إزالته / إصلاحه (في الواقع مشكلة VS)
  2. دمج الجحيم - تم إصلاحه بنسبة 1. في معظم الحالات
  3. التعقيد / الإسهاب غير الضروري - نأمل أن يتم حلها عن طريق https://github.com/dotnet/roslyn-project-system/issues/40
  4. لا يمكن تعديله يدويًا بسهولة - مرة أخرى ، تم التثبيت بـ 1. و 3.

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

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

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

laskoviymishka التغيير لا يحدث قبل RTM.

ستظل RTM تستخدم project.json كما هو مستخدم اليوم (أعتقد أن المخطط يتغير لـ RC2 ولكن هذا كان يحدث بغض النظر). من المقرر أن يتم الانتقال إلى برنامج csproj "جديد" بعد RTM وسيتم تنفيذه تدريجيًا. لا شيء يتغير في RTM (باستثناء إعادة تسمية xproj).

CodingGorilla هذا هو RC2 ، والذي سيتم نقله إلى إصدار 1.0 في شهر. في العالم الحقيقي ، هذا يعني أنك تتوقف عن تطوير كل شيء وتركز على الاستقرار. هذا التغيير ليس في الحقيقة استقرار أي شيء.

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

IMHO هذا الانتقال من project.json إلى project.csproj يجب تفكيكه قبل اعتماده. في الوقت الحالي ، هذا ليس قرارًا جيدًا ، على الأقل بالنسبة لي.

laskoviymishka من ملاحظات المجتمع الوقوف : (التشديد مضاف)

في RC2 / Preview 1 ، لن يكون هناك تغيير . في RTM / Preview 2 ، التغيير الوحيد الذي سترى ما إذا كان سيتم إعادة تسمية ملفات xproj بواسطة Visual Studio إلى csproj_. من تلك النقطة فصاعدًا ، سيعيش project.json بجوار csproj. سيبدأ الفريق بعد ذلك في ترحيل الميزات من project.json إلى ملف csproj. من الممكن أن يبقى ملف project.json ، ويحتوي على جميع مراجع الحزمة الخاصة بـ NuGet وإعادة تسميته إلى nuget.json. لقد اختبر الفريق بالفعل بعض الأعمال التي توضح أنك لن تحتاج إلى سرد كافة الملفات في ملف مشروعك ، وهي إحدى الفوائد الرئيسية لنموذج project.json.

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

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

طلبت Microsoft ، أو على الأقل فريق asp.net ، إبداء ملاحظات حول هذا الأمر ولا شك في أنهم يقرؤون هذه المواضيع ، ولكن ربما ما نفتقده هو نشرة أو مشاركة نهائية من Microsoft تقول "إذا كنت تريد مناقشتها ، افعلها _هنا_ ". ومع ذلك ، أعتقد أن الانتقال أقدم بكثير مما يعتقده الناس. حتى الآن الشيء الوحيد الذي يعرفون أنهم يفعلونه بالتأكيد هو إعادة تسمية xproj إلى csproj.

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

neoKushan هذه نقطة جيدة ، آمل أن يراها MS. سيكون من الرائع حقًا رؤية أي تعليقات من الفريق الأساسي.

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

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

دعونا في الواقع نناقش المشاكل مع MSBuild

أواجه صعوبة في العثور على معلومات كافية لتكوين رأي. كان هناك الكثير من التغييرات _seem_ ليتم تمكينها بواسطة project.json وإفلات ملفات .csproj. لا أريد أن تختفي هذه التحسينات ، لكني لا أعرف كيف سيؤدي الانتقال إلى msbuild "جديد ومحسّن" إلى تغيير سير العمل:

  • حاليًا ، نستخدم gulp لكل مهمة بناء. هل يتغير ذلك؟ بلدي gulpfile execs إلى dnu أو dotnet-cli لتحويل مجموعة من ملفات .cs إلى تجميع. يمكنني الاحتفاظ بذلك ، أليس كذلك؟
  • هل سيستمر VS في دعم مستكشف المهام ، والمشغلات afterbuild / prebuild / إلخ لمهام gulp الخاصة بي ، بحيث يمكن لمستخدمي VS تشغيل F5؟ أو هل يجب أن أجعل msbuild يبدأ gulp مما يعني أن جميع مهام gulp الخاصة بي تحتاج إلى مهام MSbuild المجمعة المحددة؟ (أوتش)
  • هل msbuild في تثبيت منفصل؟ هل سيتم إصداره بشكل منفصل عن dotnet cli أو وقت التشغيل؟ كيف يغير هذا الحد الأدنى المطلوب توفيره على خادم إنشاء CI الخاص بي؟ الحد الأدنى للتثبيت على بيئة تطوير؟
  • إذا كنت أستخدم محرر نصوص لإضافة تبعيات nuget أو ملفات .cs ، فما الخطوات الإضافية التي يتعين علي إضافتها الآن ، إن وجدت؟
  • عندما أقوم بمراجعة مجموعة التغييرات حيث أضاف مستخدم VS تبعية nuget وملف .cs ، هل ستكون تغييرات csproj بسيطة وسهلة القراءة؟ (للمقارنة ، مع .net 4.6 و VS2015 ، رأيي هو أن التغييرات في csproj _لا يمكن قراءتها بسهولة.)

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

ستفيدك هذه الأدوات بشكل أو بآخر

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

"مرحبًا بك في RTM. هذا تذكير بأن ملف مشروعك سيتغير في وقت ما في المستقبل القريب جدًا. لقد قررنا هذا بالفعل. الأسباب ، ولكن في الغالب أننا نحب الزوايا بشكل أفضل من curlies ، وننشئ أدوات ، نعم ، الأدوات. لم نحدد المخطط النهائي (ولكنه سيكون مستندًا إلى xml ، انظر أعلاه) ، وسيتم بالتأكيد إنهاء اسم الملف بـ .csproj لإلقاء أقصى قدر من الارتباك في أي أدوات قديمة. Agile. (ps إذا كنت أحد موردي الأدوات:: o) "

Oceanswave مثال جميل كيف يجب ألا تدير تطوير برامجك

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

ولكن ما لم توضحه هو مشكلتك الفعلية مع MSBuild

ربما ينبغي عليك قراءة إجابتي السابقة على نفس السؤال الذي طرحته بالضبط؟ https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

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

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

بدون مناقشة ، بدون مراجعة ، بدون أي نوع من المشاركة على الإطلاق.

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

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

في فريقي ، نتعامل مع مطوري C #. إنهم تحت ضغط ، مواعيد نهائية ضيقة ، ضغط شديد. إنهم لا يريدون أي شيء يعترض طريقهم أو يؤخرهم.

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

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

لكن ماذا في ذلك؟ من وجهة نظري بصفتي رئيس هندسة البرمجيات ، أحتاج إلى أدوات تنتج النتائج التي أريدها. لا أحصل على هذه النتائج مع MSBuild. أحصل على هذه النتائج من project.json + gulp.js + بوويرشيل.

_Can_ MSBuild تحصل علي هذه النتائج؟ بالتأكيد يمكن ذلك ، ولكن فقط إذا قام المطورون بالعمل في MSBuild للحصول على هذه النتائج. وهم فقط لا يفعلون ذلك. عندما نجبرهم ، يفعلون ذلك ، ثم لا يحافظون عليه.

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

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

حسنًا ، ما الذي يمكن عمله؟

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

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

إذن ، هل تريد إجراء عمليات الدمج بشكل أفضل؟ بعد 10 سنوات. بعد الأداة هي شتيمة في كثير من الجهات؟

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

هذه هي المناقشة التي أريد أن أجريها.

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

هل يمكنني مشاركة شيء حزين؟ من بين شركائي في العمل ، الذين لديهم أطوال خبرة مماثلة لي (أكثر في الواقع) ، كنت الأكثر تأييدًا لـ MSBuild في اليوم. أنا في الواقع _ used_ ذلك. تعلمتها. لقد بنيت خطوط أنابيب كبيرة. ولكن كان ذلك قبل أكثر من 5 سنوات ، وذهب الكثير من المياه تحت الجسر منذ ذلك الحين.

يا رجل أجد نفسي أومئ برأسه بغزارة أثناء قراءة تعليقات

فكر في: ملحقات Visual Studio (.vsix). لا أحد يريد أن يلمس هؤلاء بسبب مدى تراثهم / قديمهم / اختلافهم مقارنة بكل شيء آخر موجود هذه الأيام. حسنًا ، لديك بعض المطورين الذين يرغبون في ذلك ، لأنهم دفعوا مستحقاتهم في تعلم نظامه الغامض - تمامًا مثل MSBuild.

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

إذا كانت "أكثر تشابهًا مع .NET" (وكان لديها تكامل أفضل مع / VS) ، فأعتقد أننا نتفق جميعًا على أنه سيكون منتجًا أفضل للعمل به وعرضًا جذابًا للنظر فيه.

@ Mike-EEE & shederman إلى وجهة نظر مايك ، يجب على shederman ، حتى أنني أتفق في الغالب مع منطقه (أتفق مع

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

أنا فقط أحب الحصول على ردود أفعال رائعة وسماع نفسي أتحدث (مع جانب من الاهتمام الفكري الفعلي بالمحادثة: الضحك:)

سررت بالمساعدة! :ابتسامة:

لكن هل هو غير قابل للإصلاح؟ هل يمكن إصلاحه؟

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

PhilipRieck أنت

حاليًا ، نستخدم gulp لكل مهمة بناء. هل يتغير ذلك؟ بلدي gulpfile execs إلى dnu أو dotnet-cli لتحويل مجموعة من ملفات .cs إلى تجميع. يمكنني الاحتفاظ بذلك ، أليس كذلك؟

لا أعتقد أن هذا سيتغير ، أنا واثق بنسبة 95٪ من أن ما نتحدث عنه هنا يؤثر فقط على تعريف المشروع ، وليس كيفية بناء المشروع بالفعل (على الأقل ما يتجاوز استدعاء dotnet build). قد يستدعي dotnet CLI MSbuild في مرحلة ما ولكن في هذه المرحلة يكون نوعًا ما تحت الغطاء.

هل msbuild في تثبيت منفصل؟ هل سيتم إصداره بشكل منفصل عن dotnet cli أو وقت التشغيل؟ كيف يغير هذا الحد الأدنى المطلوب توفيره على خادم إنشاء CI الخاص بي؟ الحد الأدنى للتثبيت على بيئة تطوير؟

ليس لدي إجابة محددة على هذا السؤال ، لكني أتخيل أن MSBuild يأتي كجزء من dotnet CLI كتثبيت منفصل تمامًا ، حتى لو كنت قد قمت بالفعل بتثبيت MSBuild بالفعل (قل مع VS). على الرغم من التكهنات البحتة من جانبي. أعلم أن الهدف الضخم لمشروع ".net في كل مكان" بأكمله هو الحصول على الحد الأدنى من الجلبة لجعل الناس يتطورون. يجب أن يكون حرفيا apt-get dotnet-cli (أو أيا كان) ، dotnet new ، dotnet build. لن تضطر أبدًا إلى الاتصال بـ MSBuild لبناء المشروع ، فهذه وظيفة dotnet-cli.

إذا كنت أستخدم محرر نصوص لإضافة تبعيات nuget أو ملفات .cs ، فما الخطوات الإضافية التي يتعين علي إضافتها الآن ، إن وجدت؟

بالنسبة لملفات .cs ، بالتأكيد لا شيء آخر ، تمامًا كما هو الحال اليوم - الشيء الوحيد الذي كانوا واضحين بشأنه هو أن أيام تحديد كل ملف .cs في مشروعك قد ولت (على الرغم من أنه من المفترض أنه لا يزال بإمكانك فعل ذلك إذا أردت ، ينظر إليك @ Mike-EEE). بالنسبة إلى التبعيات ، بالتأكيد على المدى القصير (المدى القصير هو أشهر) ، سيبقون في project.json ويعملون تمامًا كما كان من قبل. هناك احتمال أن يصبح project.json nuget.json وبغض النظر عن تغيير الاسم ، فلن يتغير أي شيء آخر ، ولكن هناك احتمالات أخرى لهذا ويبدو أن هذا أحد الأشياء الرئيسية التي لا تعرفها Microsoft تمامًا - دع صوتك أن تسمع عن تفضيلاتك لهذا.
(أفضّل شخصيًا أن أكون قادرًا على فعل شيء مثل.nuget.json لكن هذا فقط لي spitballing).

عندما أقوم بمراجعة مجموعة التغييرات حيث أضاف مستخدم VS تبعية nuget وملف .cs ، هل ستكون تغييرات csproj بسيطة وسهلة القراءة؟ (للمقارنة ، مع .net 4.6 و VS2015 ، رأيي هو أن التغييرات في csproj لا يمكن قراءتها بسهولة.)

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

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

أنا أتفق تمامًا مع هذا تمامًا ، لكن Microsoft استثمرت كثيرًا في جهودها عبر الأنظمة الأساسية لجعلها فجأة كابوسًا. من خلال "الأدوات" ، أظن أنها ستكون مرتبطة بـ .net CLI بدلاً من VS أو أي شيء من هذا القبيل. لا تنس أن "لعبة النهاية" النهائية لـ .net core هي أن تكون منصة رشيقة للغاية وسريعة الحركة ولكنها لا تجبرك على قضاء بعض الوقت في الترقية كل أسبوعين. أنا متأكد من أنك إذا كتبت تطبيق dotnet 1.0 في حزيران (يونيو) ، فسيستمر في إنشاء وتشغيل سنوات من الآن ، ولكن الإصدارات الأحدث ستكون حالة تشغيل "ترقية dotnet" أو شيء من هذا القبيل عندما تكون جاهزًا . حتى عندما تصل RTM ، ستستمر مشاريع RC2 في إنشاء وحدات بت RC2 وتشغيلها حتى تدخل وتغير الهدف ليكون RTM (أعتقد في global.json أو في مكان ما؟).

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

أود أن أشير إلى أن استبدال مجموعة من وظائف إنشاء المشاريع السحرية الموجودة حاليًا في IDE بتطبيق سطر أوامر يقوم بالكثير من معالجة csproj السحرية يعد فكرة سيئة. إن جعل ملف تعريف المشروع بسيطًا قدر الإمكان أمر لا بد منه. أجمل جزء في project.json هو أنني أستطيع قراءته وفهمه.

shederman مشكلتك مع MSBuild هي أنه في نظام كبير ومعقد يكون كبير ومعقد ....

لقد عملت أيضا مع فريق يبني وأنا أيضا يكره ذلك على الاطلاق (الأزيز @ مايك-EEE عشان تحدثنا على حد سواء حول كيفية النكراء هذه التجربة)، أنا لا تحصل على ذلك، ولكن ما كنت تصف هي مختلفة تماما سيناريو. يمكن أن يكون MSbuild _ كبيرًا ومعقدًا وبشكل افتراضي VS _ يجعله كبيرًا ومعقدًا - ولكن هذا ما يتغير .

يجب أن يكون ملف csproj الأحدث أصغر بكثير ، مما يعني أنه يجب تبسيط "التصحيح" إلى حد كبير. لا (أو القليل) من الخردة. لا يزال بإمكانك استخدام أي نظام بناء تريده ، يمكنك استدعاء ملف .bat الذي يستدعي "dotnet build" على * .csproj وستحصل على الإخراج الذي تريده ، تمامًا مثل اليوم. دع dotnet cli يتعامل مع MSbuild ولا يجب أن تلمسه.

neoKushan لا شكرا.

أريد ما وعد به ، وليس أحمر شفاه على ما قيل لنا إننا نبتعد عنه.

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

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

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

والآن يقولون أنه يمكن تحسين بناء ms. هل لدى مرض التصلب العصبي المتعدد موارد كافية لإدارة كل هذا القرف الموروث؟ هل يمكن للمجتمع التعامل معها؟ أنا لا أؤمن به حقًا.

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

وإذا كنت لا تريد أن تعطينا ما وعدنا به ، دعنا نعطيه لأنفسنا.

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

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

إذا إفعلها؟ مرة أخرى ، لا شيء يمنعك.

أظن أن السبب الأول لعدم وجود رغبة في ترك الأمر هو إدراك أن هذا سيكون بداية هجرة ضخمة بعيدًا عن مشاريع MSBuild.

لماذا حتى يهتمون؟ ما الفرق الذي يحدثه لمايكروسوفت إذا كنت تستخدم MSbuild أو أي شيء آخر؟

السبب الأول الحقيقي هو أن بنية مشروع ASp.net الأساسية جيدة فقط لـ asp.net الأساسية. هناك المئات من أنواع المشاريع الأخرى التي لن تكون مناسبة لـ project.json. لا تهتم بحقيقة أن project.json له مشكلاته الخاصة ، والتي من الواضح أننا نسيناها جميعًا - عدم وجود تعليقات تثير غضبي (ولا ، مما يشير إلى بعض التنسيق الآخر طالما أنه ليس كذلك- XML لا يساعد).

أنا آسف ، لكن الاحتفاظ بتكنولوجيا قديمة في دعم الحياة ليس أحد أهداف تصميم .NET Core. فعلا؟

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

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

أنت تنتظر إذن Microsoft ، فهذا يعني أنك حصلت عليه بالفعل

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

مشكلتك الوحيدة هي أنهم تجرأوا على تسميته MSBuild

لا ، أنهم يريدون _use_ MSBuild. طفيف ، لكن فرق مهم. أعد تسمية نظام بناء project.json الجديد وأطلق عليه اسم MSBuild وسأستخدمه بسعادة.

لن تكون أكثر حكمة وكل ما عليك فعله هو "أنا أكره XML!"

ربما 😄

على أي حال ، تدور في دوائر.

الذهاب للسرير.

أقول اتركها للوقوف. لا أحد يقنع أحدا. أنا متأكد من أنني أفهم الجانب المؤيد لـ MSBuild ، لكنني لا أتفق معه. وأنا متأكد تمامًا من أن الجانب المؤيد لـ MSBuild يفهم جانب عدم وجود MSBuild ، لكن لا أتفق معه.

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

سؤال PerneoKushan :

ماذا تبقى؟

أرغب في الواقع في تأطير ردي ، إذا جاز لي ، حول "المبادئ" التي أشرت إليها أعلاه ، ما أعتقد أنه يجعله ملف مشروع جيد وقابل للاستخدام:

  • يجب أن يكون قابلاً للتحرير / القراءة

أخذ تصريحneoKushan أعلاه يعني أنه سيتم تناولها - أفترض أن أحد الأشخاص في MSFT قال / كتب هذا. مع ذلك ، أريد أن أرى اقتراحًا قائمًا على MSBuild حيث يتم تناول ذلك أولاً ، قبل "الالتزام" (كمجتمع / إطار عمل) بـ MSBuild.

أفترض أن التخلص من Guid ProjectType هو أحد أهم العناصر التي يجب تناولها؟

لكنني أقف إلى جانب الملحق أعلاه: إنه مطلب صعب (غير قابل للتفاوض) أنه بالنسبة للمشاريع البسيطة (مثل ASP.Net Hello World in Angular) ، يمكنني إنشاءها بالكامل يدويًا ، في المفكرة. إذا كنت بحاجة إلى استخدام Yeoman / VS / مماثلة ، فقد فشلنا في اقتراح ملف مشروع يمكن تحريره بواسطة الإنسان.

  • يجب أن تسمح للتعليقات

تعمل بالفعل في MSBuild

  • يجب أن يكون تصريحي

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

  • يجب أن تكون قائمة بذاتها

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

هذا مشابه لمخاوف قابلية القراءة البشرية / قابلية التحرير.

  • يجب تصميمه لتقليل تعارضات الدمج / تبسيط الدمج ، إن أمكن

يدعم MSBuild هذا تقنيًا في شكل أحرف البدل. دعم VS لأحرف البدل أسوأ من الدعم السيئ. بنشاط يجعل من الصعب العمل. حسب ما ورد أعلاه ، أنا على استعداد لقبول أنه سيتم إصلاح هذا - ولكن يجب أن يكون عنصرًا في _ اقتراح _ إلى _ الهجرة _ (وهو ترحيل إلى ، لأن جميع الرسائل حتى الآن حول project.json) إلى MSBuild ملفات المشروع المستندة.

  • يجب أن تكون قابلة للتوثيق بالكامل (مع تطبيق مبدأ الاحتواء الذاتي على الوثائق)

أعتقد أن MSBuild لديها وثائق. هذه الوثائق ، خاصة بالنسبة لـ VS _flavor_ من MSBuild تترك الكثير مما هو مرغوب فيه. غالبًا ما أكون في حيرة من أمر سبب وجود أشياء مختلفة في المجموعات التي هم عليها ، و VS "المساعدة" في تحريكها ليس مفيدًا للغاية.

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

(نعم ، أعلم ، سأقدم تقريرًا عن الخطأ)

  • يجب أن تكون مستقلة عن الأداة

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

ملف تعريف البناء ليس تنسيق ملف مشروع. تمكن VS من جعله يعمل (إلى حد ما) ليس سببًا جيدًا للاستمرار في استخدامه على هذا النحو. أريد ملفًا حقيقيًا يمثل المشروع نفسه ، ومعلومات حول الأداة التي ينتجها (وليس إرشادات حول كيفية إنشائه). في هذا ، يفشل حتى project.json لأنه يسمح لنا بتعريف "الأوامر". لماذا هؤلاء موجودون؟ ما عليك سوى تحديد نوع الإخراج وأين يمكن العثور عليه.

لقد قرأت هذا الموضوع بالكامل ، وشيء واحد لفت نظري في هذه المناقشة حول project.json مقابل project.csproj هو أن اسمًا واحدًا فقط من هذه الملفات يحتوي على لغة برمجة كاملة. أفضل القيام بتطوير ASP.NET في F #. هل هذا ممكن حتى في ASP.NET Core؟ في هذه المرحلة ، ليس لدي أدنى فكرة ، لكنني أشعر أنها ليست كذلك. لست متأكدًا حتى مما إذا كان الأشخاص يستخدمون csproj كاختصار لـ csproj, fsproj, vbproj أم أنهم يقصدون حقًا csproj فقط.

تحديث: يعمل أفراد F # على دعم CoreCLR ، ولكن لا يوجد ETA حقيقي حتى الآن. نقطتي هي أن أي نظام مشروع يتم تحديده الآن سيؤثر على لغات البرمجة التي لا يبدو أنها موجودة على رادار الناس في الوقت الحالي. بقدر ما أفضل JSON على XML ، إذا كان project.json سيقفلني في C # (وترتيب الملفات في التجميع مهم للغاية في F #) فأنا لست مع ذلك.

في الوقت الحالي ، يبدو أنه عاد إلى FAKE و Paket بالنسبة لي ...

أنا أعمل مع .NET منذ البداية ولم أواجه أية مشكلات جديرة بالملاحظة مع MSBuild. السبب الرئيسي لذلك هو أنني لم أستخدمه مطلقًا لأي شيء آخر غير تجميع الحلول الجاهزة.

وهذا ما لم أحصل عليه بشأن كره MSBuild هذا. لا أحد يجبر أي شخص على استخدام MSBuild لأي شيء بخلاف تجميع الحلول. وأعتقد أن القدرة على تجميع حل هي ميزة مفيدة جدًا - والتي لا توجد حتى الآن في "dotnet cli" راجع للشغل حتى الآن (عليك أن تقوم يدويًا بتنفيذ حلقة عبر المشاريع الآن - صححني إذا كنت مخطئًا).

لا يحتاج نظام البناء الفعلي إلى التغيير. إذا كنت تستخدم Nant ، فاستمر في استخدام Nant. إذا كنت تستخدم psake ، فاستمر في استخدام psake. إذا كنت تستخدم برنامجًا نصيًا بوويرشيل ، فاستمر في استخدامه. إلخ! على الأرجح ، يجب استبدال جزء "بناء dotnet" فقط باستدعاء MSBuild. (ربما لا يكون هذا ضروريًا إذا قامت dotnet ببناء مكالمات إلى MSBuild)

أود أن أزعم أن هذا يجعل MSBuild تفاصيل تنفيذ غير مهمة إلى حد ما. هكذا رأيته في العقد الماضي ، وهكذا سأستمر في رؤيته.

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

jtmueller ليس هناك أي سبب تقني يمنعك من استخدام F # (أو VB.net إذا كنت مائلاً). لن أتفاجأ إذا كان جزء من التحول إلى ملفات مشروع MSBuild هو المساعدة في تسهيل ذلك. لم يكن DNX سعيدًا به أبدًا ، لكن CoreCLR يدعم بالتأكيد F #. لا أعرف ما إذا كنت ستتمكن من استخدام F # come RTM لكنه بالتأكيد قيد الإعداد.

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

سيستخدم نظام بناء أحلامي (لاستبدال MSBuild بالكامل) Roslyn لمعرفة المهام والأهداف ، مما يسمح لك باستخدام F # لتحديد عملية الإنشاء (أو C # أو VB.NET ، أي شيء تدعمه Roslyn).

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

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

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

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

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

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

ولكن في حين أن هذا قد يكون كافيًا لـ 80٪ من حالات الاستخدام ، إلا أنه لا يكفي لـ 20٪ أخرى. إنهم بحاجة إلى شيء أكثر. (تحذير: قد تختلف الآراء حول نسب حالات الاستخدام).

الخطوة الثالثة هي أننا نسمح بشكل بسيط للغاية من القابلية للتوسع لنظام البناء هذا. لكننا نتحدث بشكل بسيط

أنا سعيد لأن عملية البناء الجديدة يجب أن تكون قادرة على الوصول إلى MSBuild ، لكنني لا أعتقد أن شيئًا مثل (IMO) قديم ، شاذ ، ومتضخم مثل MSBuild يجب أن يكون أساسًا لجميع الإنشاءات في المستقبل.

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

مع خبز MSBuild في أدوات .NET بالكامل ، يصبح استخدام أي شيء آخر أمرًا مزعجًا. أين المنافسة؟ ويمكنك أن ترى آثار ذلك في لوحة MSBuild Github. ما عليك سوى الانتقال إلى مراجعة جميع المقترحات المغلقة. السبب الوحيد الذي يجعلهم يتحدثون عن إجراء تغييرات "التخسيس" هذه الآن هو أنهم يريدون أن ينتقل الأشخاص من project.json إلى MSBuild.

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

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

هذه ليست وصفة لنجاح أي إطار عمل.

من فضلكم جميعًا ، ضع في اعتبارك أننا جميعًا نريد أن ينجح .NET. I _love_ .NET ، أعتقد أن C # هي واحدة من أفضل لغات البرمجة الموجودة هناك ، وقد استمتعت بانتقالها البطيء إلى Scala - The Good Parts ™ 😉.
لا أعتقد أننا نبدأ من جديد مع .NET Core ، ونفعل ذلك عن طريق تقييد أنفسنا بواحد من أسوأ أجزاء (IMO) من النمط القديم .NET. نعم ، MSBuild ، لكن لا ، غير مقيد به.

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

سيستخدم نظام بناء أحلامي (لاستبدال MSBuild بالكامل) Roslyn لمعرفة المهام والأهداف ، مما يسمح لك باستخدام F # لتحديد عملية الإنشاء (أو C # أو VB.NET ، أي شيء تدعمه Roslyn).

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

الخطوة الثالثة هي أننا نسمح بشكل بسيط للغاية من القابلية للتوسع لنظام البناء هذا.

نظام / نموذج بناء قائم على الموفر ؟! العبقري! وافقت على هذا الرسالة.

راجع للشغل ، إذا حصلت على رغبتك ولديك حق الوصول إلى نظام البناء الخاص بك ، أقترح أن نسميه ... BERSERKER BUILD! سميت على اسم "Berzerkershederman" ... كنيتي الجديدة لك. :ابتسامة:

@ Mike-EEE لا تتحمس كثيرا. لا أقترح بأي حال من الأحوال أي شيء متطرف مثل كل ذلك _ مع ذلك_.

في الوقت الحالي ، أعتقد أنه يجب أن تكون الخطوة الأولى والثانية فقط ، مع دعم MSBuild للخطوة الثالثة.

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

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

هل هذا هو المكان المناسب لإجراء هذه المحادثة

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

بناء بيرسيركر! سميت على اسم "Berzerkershederman" ... كنيتي الجديدة لك. :ابتسامة:

لست متأكدا كيف تشعر حيال ذلك 😉

لا تحاول أن تكون هائج. أنا فقط لا أريد أن أتراجع عندما _ كنا نتحرك للأمام.

مرحبًا يا رفاق ، ربما بدلاً من إعادة اختراع العجلة ( nuget.json أو أيًا كان ما سيطلق عليه) ، دعنا نستخدم الحل الحالي الذي يحركه المجتمع والذي يحل معظم مشاكل إدارة التبعية - Paket .

  1. لديها مفهوم التبعيات متعدية
  2. يتكامل بشكل جيد مع MsBuild
  3. يحتوي على تنسيق ملف يمكن قراءته من قبل الإنسان لتحديد التبعيات
  4. يحتوي على مسار ترحيل جيد جدًا من packages.config
  5. والعديد من الميزات الأخرى (ولكن من الواضح أن هذه 4 هي الأشياء الأكثر أهمية للجميع ، لذلك لن أذكر أشياء مثل تبعيات Git أو استراتيجية أفضل لحل الحزمة)

@ Krzysztof-Cieslak تذكر أن السبب الأكبر وراء قيام Microsoft بدفع تعريفات مشروع MSbuild هو المساعدة في تسهيل ترحيل أولئك الذين استثمروا كثيرًا في MSBuild. هذا الصدد ، فإن Paket ليست أفضل من project.json (أو project.yaml أو project.cs أو أيًا كان).

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

neoKushan @ نعم ، ولكن هل سيتطلب "dotnet build" ملف MSBuild حتى لو لم نستخدم MSBuild؟ هل سيتم إنشاءه إذا لم يكن هناك ملف MSBuild على الإطلاق؟ أم أنها ستتجه إلى MSBuild والتي ستنطلق بعد ذلك إلى أي نظام بناء آخر مستخدم؟

shederman بلا شك dotnet build" MSBuild في الخلفية لبناء المشاريع فعليًا ، ولكن سواء كنا نرى حقًا أيًا من ذلك أم لا ، فسيكون هناك الكثير في الهواء. في الوقت الحالي ، أنت بحاجة إلى project.json لبناء مشاريعك بشكل صحيح ، إن لم يكن للمراجع ، فعندئذٍ للبيانات المهمة الأخرى (مثل الأطر المستهدفة). في النهاية ، سينتقل بعض (أو حتى كل) ذلك إلى ملف csproj ، لذا يفترض المرء أنك ستحتاج إلى .csproj لبناء dotnet ، بغض النظر عما يستخدمه في النهاية في الخلفية. ومع ذلك ، يبقى مدى تأثير هذا عليك غير معروف.

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

ولكن إذا كان هذا سينجح ، فسيحتاج csproj إلى تضمين project.json مثل RichiCoder الذي اقترحه .

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

تغيير سهل للغاية في الواقع. من فوق رأسي نحتاج إلى:

  • احتفظ بكود dotnet-build الحالي وقم بتشغيله في ظروف معينة (يتم تحديدها لاحقًا).
  • في حالات أخرى ، قم بتشغيل MSBuild ، وفقًا لخطط فرق DotNet الأساسية
  • هل لديك VS قادرة على قراءة أي من project.json أو MSBuild لخصائص المشروع
  • إضافة القدرة على استيراد project.json إلى MSBuild

قدر ضئيل جدًا من العمل ، ويسمح لشركة Microsoft بمواصلة مسارها "MSBuild forever" ، وهي تحافظ على الوعود التي قطعتها لمجتمع .NET Core ، وتسمح لمن يريدون الانسحاب من MSBuild منا بالقيام بذلك.

من الجدير بالذكر أنه لم يقل أي شخص من أعضاء asp.net أي شيء هنا.

في غضون ذلك ، أعدت قراءة بعض الملاحظات من ASP.NET Community Standup - 10 مايو 2016 ، ويتحدثون عن نظام MSBuild "جديد" ، لكن لا أقول ما هو ، باستثناء أنه لن يتطلب ستوديو مرئي للتحرير. تمتص أنه لم يتم تصميمه في asp.net ويجب إضافته (الآن) في وقت متأخر جدًا من اللعبة ... عندما لم يتضمن التصميم ذلك في البداية. حقًا ، يجب أن يتضمن project.json عنصر {"BuildSystem": "MSBuild"} إذا كنت تريد / تحتاج إلى السير في هذا المسار. أتساءل أيضًا لماذا لا تستطيع MS (الكلمات الأخيرة الشهيرة) "ببساطة" السماح بالتعليقات في ملفات json عبر الأدوات.

rhires من فهمي ، فإن نظام MSBuild "الجديد" هو بعض التعديلات لجعل XML أخف قليلاً ، مثل تضمين جميع ملفات cs في البنية ، وإلغاء تحميل التبعيات إلى ملف nuget.json. لا توجد تغييرات كبيرة في تصميم MSBuild أو الهندسة المعمارية أو الاستخدام.

تعجبني فكرة مشروعك json. كان يمر للتو بتغييرات RC2 ، وقاموا بوضع "testrunner" ، لذلك ليس هناك سبب لعدم القيام بذلك. _BUT_ ، يبدو أن قلوبهم مصممة تمامًا على إزالة project.json تمامًا ، والعودة إلى عالم MSBuild-First.

لماذا لا تستطيع MS (الكلمات الأخيرة الشهيرة) "ببساطة" السماح بالتعليقات في ملفات json عبر الأدوات

لا يوجد سبب يمنعهم من ذلك. تدعم JSON.Net ، المكتبة التي يستخدمونها ، التعليقات.

حقًا ، يجب أن يتضمن project.json عنصر {"BuildSystem": "MSBuild"} إذا كنت تريد / تحتاج إلى السير في هذا المسار.

لماذا أرغب في أن يملي مشروعي نظام البناء الخاص به؟ بالتأكيد يبني نظام البناء المشروع وليس العكس؟

neoKushan :

تذكر أن السبب الأكبر وراء قيام Microsoft بدفع تعريفات مشروع MSbuild هو المساعدة في تسهيل ترحيل أولئك الذين استثمروا كثيرًا في MSBuild. هذا الصدد ، فإن Paket ليست أفضل من project.json (أو project.yaml أو project.cs أو أيًا كان).

Paket ليس نظام بناء جديد ، إنه مدير تبعية متوافق بنسبة 100 ٪ مع MsBuild. إنه يحل مشكلة packages.config .

@ Krzysztof-Cieslak لم أزعم أبدًا أنه كان نظام بناء وأن إدارة التبعية ليست مشكلة كبيرة في نواة .net (على حد علمي ، على الأقل). لا يستخدم .net core packages.config بل يستخدم project.json .

إذا كان .Net Core لا يزال مخططًا لاستخدام project.json فلن يكون لدينا مناقشة المشاركة الـ 100. ؛) كل ما أقوله هو أن الحل المقترح في العديد من الأماكن لاستخدام "nuget.json" للتعامل مع التبعيات هو إعادة اختراع العجلة لأن لدينا منتجًا يفعل الشيء نفسه تمامًا.

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

"نتائج الاستطلاع النهائية: 100 إجابة ، لـ 9 ملايين من مطوري .NET بنسبة ± 10٪ مع ثقة 95٪."

نعم ، وقد يعطيك السؤال في مؤتمر عن ألعاب القطط التي تعتبر الحيوان الأليف المفضل ، كلب أو قطة نتائج مماثلة.

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

"أعتقد أنه من المهم التمييز بين MSBuild والطريقة التي يستخدم بها Visual Studio حاليًا MSBuild. لقد كنت أقوم بتحرير ملفات MSBuild منذ سنوات واستخدامها في جميع مشاريعي. على سبيل المثال https://github.com/tavis- software / Tavis.home / blob / master / build / Build.proj "

هل يجب أن نناقش ملفات البناء الخاصة بـ VS أعلى ملفات المشروع حيث لا يعمل msbuild من سطر الأوامر؟

gregoryyoung علينا. لقد انتهيت من إنشاء ملفات تعتمد على devenv من قبل ، لكنني لم أر الملفات التي لن تعمل من سطر الأوامر. أي أمثلة؟

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

نعم ، وقد يعطيك السؤال في مؤتمر عن ألعاب القطط التي تعتبر الحيوان الأليف المفضل ، كلب أو قطة نتائج مماثلة.

هذا تشبيه مثير للاهتمام. إلا...

لقد قمت بنشر الرابط على موجز Twitter للأشخاص الذين _ دعموا_ الانتقال إلى MSBuild. لذلك ، في الواقع ليس مثل القياس الخاص بك على الإطلاق.

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

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

إنه بالتأكيد _هو_ ذو دلالة إحصائية ، ويمنحك إشارة جيدة إلى أين يكمن الرأي. GitHub و gitter و Twitter والمدونات كلها تدعمها بدرجة أو بأخرى.

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

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

سبب إجراء الاستطلاع هو أنه كان من الواضح تمامًا أن Microsoft ليس لديها أدنى فكرة عما كان يفكر فيه الناس. ما أصبح واضحًا تمامًا الآن هو أنه ليس لديهم أي اهتمام بما يفكر فيه الناس.

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

توقف عن محاولة تغيير الحقائق ، وابدأ في تغيير رأيك بناءً على الحقائق.

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

أعتقد أنه يمكننا منح هذا الفريق بعض التقدير ؛).

gregoryyoung آسف ، من القياس الذي قدمته ، افترضت أنك موظف MS ، لأنهم كانوا يتنقلون في نفس السطر التقريبي لمدة يومين الآن.

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

أعتقد أنه يمكننا منح هذا الفريق بعض الفضل

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

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

هل تدرك جميعًا أن project.json قد خضع بالفعل

الانتقال من ذلك إلى ملف csproj "الكلاسيكي" في الواقع لا يبدو أنه ممتد للغاية بالنسبة لي. وإذا تطور csproj نفسه أيضًا قليلاً في الاتجاه الأكثر مرونة الذي تعلمناه من project.json ، يمكنني في الواقع رؤية csproj "الجديد والمحسّن" يعمل جيدًا حقًا. وأعتقد أنه يمكننا أن نفترض بأمان أن تلك التغييرات الأخيرة على project.json لم تكن الأخيرة في الدورة لجعلها قابلة للاستخدام لجميع أنواع مشروعات .NET - أعتقد أنه من المهم ألا ننسى أن هناك هناك العديد من الأهداف الأخرى بخلاف ASP.NET (Core).

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

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

لذلك ، tl ؛ dr: نعم ، أنا حقًا أحب project.json وأتمنى أن تكون هناك طريقة للاحتفاظ بها لـ ASP.NET Core (على سبيل المثال باستخدام مهمة MSBuild خاصة). لكن في الوقت نفسه ، أفهم تمامًا سبب حدوث ذلك الآن ، وأعتقد أنه في الواقع ليس بالأمر السيئ الذي يفعلونه. بالطبع ، التوقيت غريب بعض الشيء ، ولكن نظرًا لأن التغيير لن يحدث بالتوازي مع إصدار ASP.NET Core و .NET Core ، لا أعتقد أن التوقيت يمثل مشكلة فعلية (على افتراض أن الانتقال لاحقًا سيكون بسلاسة ).

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

darrelmiller يبدو هذا مخيفًا بالنسبة لي ، لأنه يبدو أن هذا يعني أن إدراج الملفات في ملف csproj.

lokitoth بافتراض أن csproj سيعمل بشكل مشابه لمراجع الملفات مثل أحدث project.json ، فلا يوجد ما يمنعك من استخدام globs بشكل عام ووجود مراجع ملفات فردية جنبًا إلى جنب معها.

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

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

كان هذا تغييرًا مخيبًا للآمال للاستماع إليه. Project.json ، التضمين التلقائي للملف / globbing ، والاستعادة متعدية كانت الأشياء الأولى في ASP.NET Core التي جعلتني أذهب "أوه ، رائع!" في البداية.

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

جمعية البناء الخيرية.

بالنظر إلى التغييرات في مشاركة poke ، يبدو أنهم قاموا بشكل أساسي بترجمة csproj إلى json ، وهو أمر رائع حقًا أيضًا.

استنادًا إلى حقيقة أنهم يريدون دعم خيارات Compile و Embed و CopyToOutput و Exclude و Shared Files وما إلى ذلك ، فإن تنسيق json لن يعمل بشكل أفضل من XML على أي حال. أظن أيضًا أن json لم تكن لتعمل بشكل جيد مع تخصيصات البرنامج النصي للبناء الثقيل.

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

gregoryyoung ما قدمته ليس مفيدًا لأي مناقشة عاقلة

باهر. حسنًا ، لنرى ، ما الذي قدمته:

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

هل يمكنني أن أسأل ، بدافع الاهتمام ، ما هو الجزء المجنون؟ استجواب تفكير شخص ما ليس عقلانيا هذه الأيام؟ أم تركت شيئا هناك؟

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

ملاحظة. آه ، أنت _that_ جريج يونغ. احترام. أحب عملك. أنا حقا.

bzbetty أتفق معك تمامًا. آخر شيء أود رؤيته هو إعادة تخيل MSBuild وتحويله إلى project.json. واحدة من أكبر المشاكل مع MSBuild في شكله الحالي هو أنه يدمج _ تعريف المشروع_ مع _ عملية البناء_.

لذا فإن المضي قدمًا في عملية الإنشاء وإضافتها إلى project.json سيؤدي إلى ارتكاب نفس الخطأ الذي ارتكبه MSBuild / VS.

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

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

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

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

ولكن ، بمجرد أن تصطدم بسيناريو لا تستطيع أداة "إنشاء التعريف" البسيطة التعامل معه؟ بالتأكيد ، _ ثم ستفعل.

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

الصابون

أود فقط مشاركة القليل من البحث الذي كنت أقوم به. كنت أنظر إلى Twitter و Slack و Github و Gitter و Jabbr.

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

لقد شعرت بالفزع الشديد أيضًا من نزعة الكثيرين في المعسكر المؤيد لـ MSBuild للاستدلال على أن خصومهم لديهم معلومات مضللة ، أو بشكل أكثر شيوعًا ، غير مؤهلين. وقد قابل ذلك الاتجاه السائد في معسكر pro-project.json إلى استنتاج دوافع سيئة (بما في ذلك أنا ، mea culpa).

أود أن أسأل ما يلي:

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

الحجج ل
الأسباب الرئيسية التي رأيتها متقدمة للانتقال إلى MSBuild هي:

  • دعم الأدوات - للسماح بالتعثر الدائري بين الأدوات المختلفة ، على سبيل المثال VS و VSCode و Xamarin وما إلى ذلك.
  • الاستثمارات الحالية - العملاء الكبار لديهم بنى قائمة لا يمكن التخلص منها
  • "ذاكرة العضلات" - اعتاد الناس على بناء MSBuild

مناقشات ضد

  • الاستثمارات الحالية - الاستثمارات التي تمت في أدوات .NET Core: post RC. RC _should_ يعني عدم وجود تغييرات رئيسية
  • CSProj / MS قم ببناء تجارب سيئة - تجارب سلبية سابقة في التعامل مع csproj و MSBuild
  • خطوة للخلف - انتقل إلى project.json انتقل إلى طريقة جديدة للعمل ، جزئيًا لجذب جيل جديد من المطورين. يتم التراجع عن هذا

رأي
لقد دفعت مقابل اشتراك SurveyMonkey الكامل حتى أتمكن من الوصول إلى المجموعة الكاملة من النتائج (بدلاً من المائة الأولى). إنها 321 إجابة ، والتي تُترجم عادةً إلى هامش خطأ بنسبة 5.5٪ ، وثقة بنسبة 95٪ لتسعة ملايين من السكان.

الحجج الشائعة التي سمعتها ضد هذا الاستطلاع هي:

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

ها هم:
image
image
image
image
image

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

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

يذكرني Manshederman بي (والعديد من الآخرين) عندما أكله Silverlight ، باستثناء x10 وأكثر تركيزًا / خبرة. ربما هذا هو سبب دعمي له: 100:٪! هاها.

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

لذا فإن المضي قدمًا في عملية الإنشاء وإضافتها إلى project.json سيؤدي إلى ارتكاب نفس الخطأ الذي ارتكبه MSBuild / VS.

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

: +1:: +1:: +1: ... طريقة ممتازة لتأطير المشكلة !!! أتعلم ، لقد ظللت أنفي في هذا لفترة طويلة ، لدرجة أن هذا لم يحدث لي حقًا. لكنك (مرة أخرى) تعمل بنسبة 100٪.

أكره فتح ملف csproj لإصلاح مشكلة لأنه جدار من نص يصعب تحليله.

هذا يحتاج إلى تأطير في مكان ما ،nbarbettini! يجسد مشاعري تمامًا أيضًا.

وفي الواقع لا يهم كثيرًا ما إذا كان تنسيق الملف هو JSON أو XML أو أيًا كان.

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

في المقابل ، لا يتم تجذير MSBuild في XML ، في حد ذاته ، ولكن الطريقة التي تم تصميمها بها هي وصف "نموذجها" في هذا التنسيق. أقول "نموذج" لأن كلا النظامين يعاني من (ما أعتبره أ) عيبًا في التصميم يتمثل في وضع نموذج مستند أمام النموذج الفعلي / واجهة برمجة التطبيقات التي يتم فك تسلسلها في الذاكرة في النهاية. هذا يعني الاضطرار إلى إدارة المزيد من القطع الأثرية والمفاهيم أكثر مما هو ضروري حقًا ، وفي النهاية يعقد النظام. إن تشفيره لقبول تنسيق معين فقط (XML أو JSON) يزيد الأمر سوءًا ، ومرة ​​أخرى يجب علينا استكشاف طرق لتخفيف هذا القيد.

على أي حال ، إعلان الخدمة العامة في صباح الأحد العرجاء للجميع. : stuck_out_tongue:

لم أستطع رؤية هذا منشورًا في أي مكان في هذا الموضوع ، لذلك هنا يذهب ... https://youtu.be/N9MteJH-HsQ. نأمل أن تشرح قليلاً عن سبب إجراء التغيير.

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

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

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

لن يسمح لي GitHub على هاتفي بإجراء +

أوضح الفريق أن جزءًا من سبب التغيير هو الاستحواذ على Xamarin ، وهي صفقة كبيرة. تعد إمكانية مشاركة المكتبات بين مشاريع .NET و ASP.NET و Xamarin mobile / x-plat هائلة ، وإذا كان ذلك يعني المساومة على تنسيق ملف المشروع / البناء ، فهي تجارة جديرة بالاهتمام IMHO.

سأنتظر وأرى كيف تبدو الأدوات وإعداد الملف النهائي قبل تكوين رأي نهائي.

gregoryyoung كنت أشير إلى نتائج الاستطلاع

أي عينة سيكون هذا التحيز؟ الموقع الذي تم نشره فيه بشكل أساسي على خلاصات Twitter للأشخاص الذين _ مثل_ التغييرات؟ القناة التي كانت موجودة على قنوات Slack التي يستخدمها فريق التطوير؟

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

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

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

يحتاج الناس Jeez إلى تهدئة هيك أسفل :)

أوافق على أن هذا التغيير يبدو كبيرًا ولكني أعتقد أنه سيؤثر على الناس أقل بكثير مما قد يبدو. تذكر أنه عندما يتحدث الفريق عن "الأدوات" فإن ذلك يشمل أيضًا cli. أي تحويل يجب أن يحدث سيتم أيضًا بواسطة cli ، وستكون "الأدوات" لإضافة المراجع التي أجادل أنها أفضل من كتابتها إما في json أو xml ، في cli. Globbing مدعوم بالفعل في msbuild. من الواضح أنه سيتم تضمين Msbuild في لا sdk ، لذلك لن تكون هناك عمليات تثبيت إضافية ، وستكون قصة المشروع الجديد هي نفسها أيضًا ، وستقوم أوامر dotnet بأشياء أخرى تحت الغطاء. (أنا لست Microsoftie ، لكن هذا يبدو محتملاً للغاية)

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

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

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

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

دعنا نرى فقط ما يقترحونه ثم نطرح مشكلات محددة إذا وجدنا خطأً في ذلك :)

@ aL3891

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

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

إذا حصلنا عليها ، +10 مني.

@ aL3891 سؤال سريع. كان بعض الناس يقولون إننا يجب أن نحضر وقفة الأربعاء لمعالجة هذه القضايا. هل تقول أننا يجب أن ننتظر مشاركة المدونة؟

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

لقد شاهدت مقطع فيديو youtube الذي نشره khellang - كانت تغييرات ASP.NET _ ثورية_ ، ولكن يبدو ، في النهاية ، أنها كانت ثورية للغاية ، والآن مع وجود Xamarin في المزيج ، لن تنجح ثورة_الثورة.

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

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

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

من ناحية أخرى ، ربما فاتني شيء في مكان ما؟

shederman أود أن أقترح أن يحضر كل من أصحاب المصلحة الخاصة

لأولئك الذين ليسوا على دراية بالوقوف ، انتقل هنا: https://live.asp.net/

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

shederman لا أشعر أنني أمتلك حقًا السلطة لإخبار أي شخص بما يجب القيام به ، لكن يمكنني إخبارك بما

أحدث حلقة on.net ، المرتبطة أعلاه قدمت بعض الأفكار الجيدة بالرغم من ذلك

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

هل لدى شخص ما TL ؛ DR في حلقة on.net؟

أعتقد أنني غير معتاد للغاية في _المحادثة_ مشاهدة مقاطع الفيديو حول البرمجة. أعطني رسالة نصية في أي وقت 😄

جهنم الدموي! حتى إنني لا أملك IDE في طرق التعلم الخاصة بي 😱

أعتقد أنني غير عادي للغاية في كره مشاهدة مقاطع الفيديو حول البرمجة. أعطني رسالة نصية في أي وقت: ابتسم:

ما هي المشكلة؟ إنها _فقط_ ساعة من وقتك. :ابتسامة:

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

يا صديق. ربما تكون هذه واحدة من أفضل المشاركات التي رأيتها حول هذه المشكلة في الأيام الثلاثة الماضية!

ثمن ضئيل يجب دفعه للبقاء على حافة النزيف ، ولكن لكل منها ؛)

ليرة لبنانية الأساسية ؛ د:
بدأ الفريق في الحصول على تعليقات من العملاء الداخليين مثل xamarin والعملاء الخارجيين على أن الترحيل من المشاريع الحالية إلى project.json كان أمرًا صعبًا وكان الحصول على project.json للعمل جنبًا إلى جنب مع المشاريع الحالية بالإضافة إلى سلاسل الأدوات الأخرى مثل العملاء الأصليين والمشروعات الأخرى قد تعني الأنظمة الأساسية مثل android جلب قدر كبير من التعليمات البرمجية (أو المفاهيم) من msbuild. قد يستغرق هذا الكثير من الوقت والجهد ويبطئ الإصدار بمقدار غير مقبول من الوقت بالإضافة إلى إبطاء العمل المستقبلي (بما في ذلك المنتجات الأخرى مثل استوديو xamarin وتطوير الأحادي ، بالإضافة إلى مطوري البرنامج الإضافي للاستوديو المرئي).

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

إنهم يدركون أيضًا أن الأشخاص مغرمون جدًا بـ project.json وهم كذلك ، وأنهم يريدون الاحتفاظ بقدر كبير من الخير من ذلك ، وربما حتى تمكين msbuild من قراءة ملفات project.json أيضًا عبر الهدف. سيناريوهات Cli و VS-less هي أيضًا شيء يرون أنه سيناريو أساسي. يتحدثون أيضًا قليلاً عن أنظمة البناء الأخرى والهدف هو تمكين الأشخاص من استخدام أشياء أخرى غير msbuild إذا كانوا يريدون ذلك

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

أوصي بمشاهدته ، ربما أفتقد بعض النقاط الدقيقة هنا.

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

@ aL3891 شكرا على الملخص!

ثمن ضئيل يجب دفعه للبقاء على حافة النزيف ، ولكن لكل منها ؛)

آه ، لكنني لست على حافة النزيف ، فأنا أبقى بعيدًا قليلاً عن هناك. لقد عدت إلى الوراء بما يكفي حتى لا أجرح نفسي ، أو على الأقل هكذا اعتقدت عندما اعتمدت .NET Core post-RC1 😢

shederman بالنظر إلى أن "ما بعد RC1" هو في الأساس nightlies أو المصدر، كيف بالضبط هل تحب شريحة لحم ديك؟

neoKushan لقد قصدت أننا "فقط" اعتمدنا * NET Core _after_ RC1. ما زلنا في vanilla RC1.

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

لكن لا بأس ، لقد توقفت عن الاتصال بالنادل ، وقد اتصلت الآن بالمترد (ممثل شريك مجموعة Microsoft) ليأتي ويقابلني ويمكننا مناقشة اتخاذ القرار ونشر المعلومات واتجاه المنصة.

لا نعرف شيئا!

لم نعط معلومات كافية ، الكثير من النظرية والتخمين في هذه المسألة. ملخص سريع للكسالى الذين لا يريدون قراءة هذا الموضوع:

ما نعرفه

  1. سيتم تحويل xproj إلى csproj.
  2. قد يكون لدينا ملف nuget.json.
  3. نحن نستخدم msbuild .
  4. كل هذا سيحدث على مراحل.
  5. المكتبات لن تتغير.
  6. لن تضطر إلى تحديد كل ملف في csproj.

ما لا نعرفه بعد

  1. هل سيترجم csproj إلى .nupkg's؟
  2. هل سيترجم csproj إلى بنى وأهداف متعددة في وقت واحد x86 / x64 dotnet / dotnetcore؟
  3. هل سيكون هناك ملف nuget.config منفصل.
  4. كيف سيتم التعامل مع الأوامر لتنفيذ npm / gulp / bower / إلخ؟
  5. هل سنتمكن من استخدام dotnet build بالإضافة إلى msbuild ؟ أنا مستعد تمامًا لـ "one .net" الذي يطمح إليه
  6. هل سيبقى التحسس المعرفي لمراجع المشروع أم سيختفي؟
  7. هل ستكون أدوات VS أو سطر الأوامر جيدًا بما يكفي بحيث لا نضطر أبدًا إلى تحرير csproj.
  8. هل سنحصل على أدوات dotnet add reference MyAssembly ؟

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

أنا مستعد تمامًا لـ "one .net" الذي يطمح إليه

هذا ؟ : ابتسامة:: +1:: +1:: +1:

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

لكن لكن ... ثم ماذا سأفعل بحياتي ؟؟؟ : صرخة:: ابتسامة:

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

وماذا لو واجهت مشاكل مع قائمة "ما نعرفه"؟

هل يجب أن أنتظر الوضوح في قائمة "ما لا نعرفه بعد" قبل إثارة مخاوفي؟

أو يجب أن أصمت وأمتص؟

كما أدرك جيدًا ، فإن الكثير من الناس يرغبون في ... 😉

من كل شيء رأيته ، القرار 100٪ ، غير قابل للتغيير في:

image

إذن ما الذي أحتاجه أكثر من "ما لا نعرفه بعد"؟

shederman قد ترغب حقًا في مشاهدة فيديو On.Net. إنه يعطي مجموعة من الأسباب وراء القرار.

لمعلوماتك: عادةً ما أقوم بتغيير السرعة إلى 1.5 لمشاهدتها بشكل أسرع. https://www.youtube.com/watch؟v=N9MteJH-HsQ

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

MelGrubb ، الشيء الوحيد الذي نعرفه هو أن تخطيط المشروع الجديد لن يسرد جميع الملفات الموجودة ، سيكون تمامًا كما يفعل project.json

لأي شيء يُتوقع إدارته يدويًا ، يرجى TOML.

JSON ليس له أي معنى على الإطلاق للتكوين. حتى أقل منطقية من XML.

لأي شخص مهتم ، يبدو كما لو أن وحدات بت RC2 متوفرة (لا يوجد منشور مدونة حتى الآن يمكنني رؤيته)

https://www.microsoft.com/net/core#windows

و https://www.microsoft.com/net/download#core

سنتي ، fwiw:

لقد أحببت بساطة project.json. إليك ما أرغب (ولا أحب) رؤيته في الأدوات المستندة إلى MSBuild:

  • لا ينبغي ربط MSBuild بـ VS أو أي IDE / محرر آخر. يجب أن تكون أداة قائمة بذاتها يمكن تثبيتها من تلقاء نفسها. (أو تم تضمينه كجزء من تثبيت dotnet cli.) أقول هذا لأنني اضطررت إلى تثبيت مثيل VS كامل على وكلاء الإنشاء فقط للحصول على MSBuild. هذا لم يبدو منطقيأ لى أبدأ.
  • يجب أن يكون MSBuild (أو dotnet cli الذي يحتوي على MSBuild) نفسه قابلاً للتثبيت باستخدام سطر أوامر - سواء أكان apt-get أو chocolately أو homebrew أوowershell أو bash / curl. إذا لم أتمكن من تثبيت هذا كجزء من إعداد مؤتمت بالكامل لعامل بناء (على سبيل المثال ، في دائرة .yml أو Dockerfile) ، فسيكون ذلك عقبة في الطريق ومصدرًا للألم.
  • يجب أن يكون MSBuild مألوفًا جدًا لسطر الأوامر. يجب أن أكون قادرًا على فعل أي شيء من سطر الأوامر - وبالتالي سأكون قادرًا على أتمتة أي شيء في عملية البناء - في ملف دائرة أو باش أو ملف نصي آخر. وأود أن أرى استخدامًا جيدًا لكل من stdin و stdout ، حتى أتمكن من إدخال / إخراج أوامر MSBuild.
  • يجب ألا يتطلب العمل في مشروع NET Core في VS Code (أو محرر آخر غير VS) معلومات خاصة بـ VS في ملف csproj أو في أي مكان آخر. يجب أن تكون معلومات المشروع وتبعيات حزمة nuget وأهداف النظام الأساسي وتوجيهات المترجم وما إلى ذلك قابلة للمشاركة عبر المطورين باستخدام IDEs / المحررين المختلفين. هذه منطقية في ملف المشروع. لكن لا يجب على الأشخاص الذين لا يستخدمون VS رؤية إعدادات أدوات VS - فهؤلاء ينتمون إلى ملف منفصل.
  • يجب أن يكون ملف (ملفات) المشروع سهل الفهم والتحرير اليدوي. الأدوات رائعة ، لكن يجب أن أكون قادرًا على فتح الملف وفهم ما تفعله الأدوات من أجلي. وقم بإجراء التغييرات بسهولة.
  • على الرغم من أنني أعلم أنه لا يوجد فرق في الوظيفة / القدرة ، إلا أن لدي تفضيل شخصي قوي لـ json على xml. أعتقد أيضًا أن استخدام json سيساعد في جذب المطورين القادمين من مكدسات أخرى. من الصعب جذب الأشخاص إلى .NET بشكل كافٍ دون القيام بأحد الأشياء الأولى التي يرونها في ملف XML كبير يصعب فك تشفيره. (هذا عاطفي أكثر منه منطقي ، لكنني أعتقد أنه مهم). يرجى على الأقل جعل json خيارًا ، واستخدام هذا الخيار في مولدات yeoman وقوالب المشاريع الجديدة الأخرى. في أسوأ الأحوال ، يُرجى قبول طلب السحب الحتمي بسرعة بتنفيذ تنسيق json بسيط في MSBuild repo.
  • سيكون من الجيد الاحتفاظ بـ "البرامج النصية" على غرار npm ، لذلك يمكنني بسهولة مشاركة الأوامر المستخدمة للتطوير ، والاختبار ، والتصحيح ، والبناء ، والتشغيل ، وبناء / تشغيل عامل الإرساء ، وما إلى ذلك مع فريقي. يمكن أن يتم وضع هذه الملفات في ملفات البرامج النصية الخاصة بهم ، لكنها تبدو منطقية (بالنسبة لي) كجزء من ملف المشروع.

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

"لكن الأشخاص الذين لا يستخدمون VS لا يجب أن يروا إعدادات أدوات VS - فهؤلاء ينتمون إلى ملف منفصل."

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

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

لا ينبغي ربط MSBuild بـ VS أو أي IDE / محرر آخر.

لن يتم ربطها بـ VS على الإطلاق ، وسيتم تسليمها عبر Nuget لذا فهي غير مرتبطة بأي شيء.

يجب أن يكون MSBuild (أو dotnet cli الذي يحتوي على MSBuild) نفسه قابلاً للتثبيت باستخدام سطر أوامر

لم يتغير هذا من اليوم ، ستظل قادرًا على تثبيت dotnet cli عبر مصادر الحزم المعتادة.

يجب أن يكون MSBuild مألوفًا جدًا لسطر الأوامر.

سيكون _MSBuild_ جزءًا فعالًا من البنية نفسها ، لذلك لا أعتقد أنك ستحتاج إلى تمرير خيارات سطر الأوامر. ومع ذلك ، من الواضح أن donet (CLI) سيكون مناسبًا لسطر الأوامر وأعتقد أن هذا هو كل ما تريده / تحتاجه.

يجب ألا يتطلب العمل في مشروع NET Core في VS Code (أو محرر آخر غير VS) معلومات خاصة بـ VS في ملف csproj أو في أي مكان آخر.

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

يجب أن يكون ملف (ملفات) المشروع سهل الفهم والتحرير اليدوي.

لقد قالوا إن هذه أولوية بالنسبة لهم أيضًا.

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

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

من خلال القصص المتناقلة ، اضطررت مؤخرًا إلى العمل في مشروع حاول فيه شخص ما تضمين JSON في عناصر XML :(

تم نشر مشاركة .net الأساسية أيضًا https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

neoKushan شكرا!

michaelvolz لا أعتقد أن هذا الملف سيبقى ، إذا كان يجب تصديق ذلك: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .md

System.GC.Server (قديم: gcServer) - قيمة منطقية تشير إلى ما إذا كان يجب استخدام GC للخادم (الافتراضي: صحيح).

و

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

يبدو غريباً بعض الشيء بالنسبة لهم أن يكون لديهم XML لـ _project config_ لكن .json لـ _runtime config_؟

يبدو غريباً بعض الشيء بالنسبة لهم أن يكون لديهم XML للمشروع ولكن json لوقت التشغيل؟

هل هو الآن؟ : يضحك:

@ مايك - EEE نقطة جيدة! لقد قمت بالتحديث لأوضح ما قصدته: التقبيل:

neoKushan لا ، كنت على حق في المرة الأولى. : ابتسم: كنت أتفق معك في طريقتي غير المثمرة ذات الحد الفاصل. : smirk_cat:

لكن نعم ... يتفقون بنسبة 100٪ على أن وجود تنسيقات مختلفة داخل حل أمر مثير للجنون. يقلل وجود تنسيق واحد عبر اللوحة من التعقيد وتبديل السياق ، وبالتالي _ الارتباك_. إنه أحد الأسباب التي تجعلني أرغب في رؤية

أعتقد أنني سأكون من أتباع حملتك المقدسة @ Mike-EEE ، نظرًا لأننا عالقون مع msbuild فلنجعلها أفضل.

مرحبًا ، شكرًا sandorfr ... لا تتردد في المساهمة في الموضوع هناك (حتى لو كان رد فعل /: + 1 :). أشعر بالوحدة قليلاً هناك وبالتأكيد أمشي في المنطقة المتنازع عليها! من وجهة نظري ، سأكون منفتحًا جدًا على تحسين المنتج الخاص بي لزيادة التبني / الأفضلية / سهولة الاستخدام / الإعجاب إذا كان هناك عدد كبير من العملاء مجبرين على استخدام منتجي لأي سبب من الأسباب. لكنني لست مسؤولاً عنها ، لذا. : stuck_out_tongue:

@ Mike-EEE قرأت بعضًا من الخيط ، فأنا مكتئب جدًا الآن ... لقد دخلت في عالم تراث العقول الموروثة: د.

دعونا نأمل أن يكون الأشخاص في Microsoft أكثر انفتاحًا على أفكارك لأنني في الواقع جيد مع msbuild فقط إذا كان الشيء أكثر بساطة ومباشرة ولست بحاجة إلى Gui لتعديل مشروعي (نعم كان json intellisense أفضل بكثير من علامات تبويب مشروع الاستوديو المرئي المعتاد).

لقد دخلت إلى عالم تراث العقول: د.

sandorfr ... wellllll-قال-قال Wellllll.

لأولئك الذين ليسوا على دراية بالوقوف ، انتقل هنا: https://live.asp.net/

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

@ Mike-EEE من المثير للاهتمام ، أنه كان مقررًا بالتأكيد الليلة في وقت ما ، لكني أتساءل عما إذا كان قد تغير. لقد قمت بالتغريد على shanselman ، وآمل أن يكون هذا مجرد خطأ ولكن نظرًا لأن RC2 ظهر أمس فقط ، فقد يرغبون في تخطيه هذا الأسبوع.

حسنًا ، neoKushan ... فقط أتأكد من سلامة العقل على رأسي لمرة واحدة. لكي أكون متأكدًا ، لا أريد أن أكون سريعًا جدًا في التعامل مع جميع أسئلتنا والاستياء أيضًا. :غمزة:

من Slack:

jongalloway [9:31 صباحًا] أنا متأكد من إلغاء ASP.NET Community Standup غدًا - كل من shanselman و damianedwards في OSCON.
...
davidfowl [9:34 AM] damianedwards: عاد ... لكن shanselman في oscon
...
jongalloway [9:46 ص] نعم ، تم بالتأكيد إلغاء ASP.NET Community Standup لمدة 17/5. لقد قمت بتحديث الموقع.

@ Mike-EEE التعامل مع جميع ... استياءنا

😆

image

في حالة وجود أي شك متبقي: https://twitter.com/shanselman/status/732585321775267842

يجب أن أتخطى. أنا في #vslive و OSCON

هناك شيء واحد أستمتع به كثيرًا في project.json: يتم تضمين جميع الملفات افتراضيًا في المشروع ، دون الحاجة إلى تضمين كل منها بشكل صريح. مع المشاريع الكبيرة (أعني آلاف الملفات) ، كانت عملية الدمج مؤلمة حقًا بسبب XML ، ولكن أيضًا بسبب إدراج كل ملف في csproj.

هل نعرف ما إذا كان هناك أي تحسن في هذا الجانب؟

pierrus لقد ذُكر أنهم لا يريدون العودة إلى الأيام التي تم فيها إدراج جميع الملفات داخل csproj.

MaximRouiller حسنًا لم أكن أعرف ذلك ، عظيم!

MaximRouiller لكنها لا أريد أن أعود إلى أيام حيث كان MSBuild الطوق واحد ™، أعني بناء أداة. 😉

_Ash nudertog vegal durbatulûk ، الرماد nudertog vegal gimbatul ،
الرماد nudertog vegal thrakatulûk agh burzum-ishi krimpatul._

shederman لقد

تفكيري هو أنهم أرادوا في البداية شحن تنسيق project.json لكن تطبيع النموذج باستخدام csproj / Xamarin سيتطلب منهم فقط دفع إطار العمل لفترة أطول. كان المكسب الأسرع هو الاندماج مرة أخرى في csproj. يمكنهم الاحتفاظ بالطريقة الجديدة في ملف منفصل مع الاحتفاظ بالبيانات الخالصة داخل csproj. يشرح ذلك بالنسبة لي العمل الهائل الذي تم إنجازه في RC2.

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

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

على أي حال ... لم نعد ننتهي في دورة إصدار سنوية بعد الآن. إذا كانوا جاهزين للانتقال من project.json إلى csproj post-RTM ، أفترض أنه يمكن إطلاق تغييرات أكبر بعد RTM أيضًا.

التغييرات التي لا يعلم بها أحد سوى فريق MS.

MaximRouiller لا أستطيع أن أعمل على إيقاف التغييرات "المحتملة" التي قد تنزل على الخط.

أنا فقط أعمل على إيقاف التغييرات المعلنة ، أنهم ينتقلون من البنية الخفيفة ، إلى استخدام MSBuild و xproj لكل شيء.

نعم ، سنعود إلى الوحش ... لكننا لسنا بعيدين جدًا.

حسنًا ، إذا _لقد قمنا _ بشيء يعمل من أجل 90٪ من حالات الاستخدام لإعادة _الرجوع _ إلى شيء معقد للغاية لحالات الاستخدام هذه ، حسنًا ، لدي سؤال واحد فقط:

لماذا ا؟

لماذا يقوم dotnet build بالاتصال بـ MSBuild في حين أن msbuild يقوم بهذا بالفعل بشكل جيد. لماذا يتم إهمال البناء البسيط؟ لماذا العمل الإضافي ؟ السبب الوحيد بسيط ، لقد تم اتخاذ القرار بأنه يجب علينا جميعًا استخدام MSBuild طوال الوقت لكل شيء ، إلى الأبد.

شيء يعمل في 90٪ من حالات الاستخدام

[بحاجة لمصدر]

حتى لو افترضنا أنها 90٪ من حالات الاستخدام ، فهل ستعمل على أي شيء فشل بنسبة 1/10 من الوقت؟

العودة إلى شيء شديد التعقيد

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

لماذا تستدعي dotnet build MSBuild عندما تقوم msbuild بهذا بالفعل بشكل جيد.

هل انتقلنا من القول أن MSBuild "معقد للغاية" إلى "MSbuild يفعل هذا بالفعل بشكل جيد"؟ حاليًا ، dotnet build فقط _ يبدو بسيطًا لأن كل ما يحدث في الخلفية مخفي عنك. التبديل إلى MSbuild لا يغير هذا ، بقدر ما تشعر بالقلق فهو لا يزال مجرد dotnet build .

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

تعمل في 90٪ من حالات الاستخدام

shederman من فضلك توقف عن افتراض أن كل شيء هو ASP.NET ... أنت جاهل _willelyant_ في هذا الموضوع. أقترح عليك أن تهدأ في الوقت الحالي حتى نحصل بالفعل على مزيد من المعلومات حول نظام المشروع الجديد بدلاً من مجرد افتراض أن كل شيء محكوم عليه بالفشل.

shederman السبب الذي يجعلك تبني

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

إذا كان الأمر مثل dotnet build فإن السؤال هو - ما مدى صعوبة تغيير عملية إنشاء التسطير؟ هل من الممكن استبدال msbuild بشيء مختلف؟ كم من أشرطة مجاري الهواء سوف تتطلب؟

إذا تمكنا من إجراء مثل هذا التغيير في 1 أو 2 من الشريط اللاصق ، فهذا مقبول.

neoKushan هل انتقلنا من القول أن MSBuild "معقد للغاية" إلى "MSbuild يقوم بهذا بالفعل بشكل جيد"؟

أم لا. أعتقد أنني كنت أقول أن الأمر msbuild يعمل MSBuild بشكل جيد. لم أكن أحكم على MSBuild كأداة. ألم يكن ذلك واضحا؟

neoKushan حتى لو افترضنا أنها 90٪ من حالات الاستخدام ، فهل

لا أحد يقول أي شيء عن أي شيء فشل . بعض الأدوات مناسبة لبعض الأغراض أكثر من غيرها. أود أن أقول إن قوة وتعقيد MSBuild مناسبان للغرض لحوالي 10٪ من المباني. يمكننا الجدال حول النسب المئوية الدقيقة ، لكنها بالتأكيد أقل من 100٪.

neoKushan التبديل إلى MSbuild لا يغير هذا

اممم ، لا يغير عملية البناء لا. إنه _ يفعل _ مع ذلك يغير ما هو مطلوب لعملية الإنشاء (مثل ملف csproj) والسرعة التي يتم بها تنفيذها.

neoKushan ، أنت غير راغب في قبول حقيقة أن هناك فرقًا بين وجود ملفات MSBuild XML كنظام مشروع وبين استخدام MSBuild كنظام بناء - هناك فصل بالفعل.

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

poke من فضلك توقف عن افتراض أن كل شيء هو ASP.NET

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

poke أنت جهل عن عمد في هذا الموضوع.

آمل ذلك ، نعم. لأن ما أجهله عن قصد هو الفوائد الرائعة التي تعود على مستخدمي MSBuild.

poke ، أقترح عليك أن تهدأ في الوقت الحالي حتى نحصل بالفعل على مزيد من المعلومات حول نظام المشروع الجديد بدلاً من مجرد افتراض أن كل شيء محكوم عليه بالفشل.

يا صاح ، أنا هادئ ، أعدك.

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

وهو نوع من السخرية عندما يطلب مني هذا

مضحك حقا.

MaximRouillershederman سبب بناء رقاقة فوق شيء ما هو عندما تريد استبداله. قم بتجريده حتى تتمكن من تغيير التنفيذ

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

أم لا. أعتقد أنني كنت أقول أن الأمر msbuild يدير MSBuild بشكل جيد.

لوضع هذا في السياق:

لماذا تستدعي dotnet build MSBuild

dotnet build بأكثر من مجرد استدعاء المترجم "فقط" ، ألق نظرة على تنفيذ CLI الحالي لبناء dotnet . بناء مشروع واحد هو مجرد جزء من عملية dotnet build . في النهاية _ جزء_ من هذه العملية سيكون استدعاء msbuild لكن هذه ليست وظيفتك ، هذه هي وظيفة CLI.

لم أكن أحكم على MSBuild كأداة.

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

ألم يكن ذلك واضحا؟

القليل جدًا مما تقوله واضح ، أو على الأقل مدروس جيدًا.

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

لذلك تفشل بعض الأدوات في أن تكون مناسبة للغرض.

أود أن أقول إن قوة وتعقيد MSBuild مناسبان للغرض لحوالي 10٪ من المباني.

حسنًا ، هذا مثير للاهتمام لأن كل مطور Visual Studio. net هناك يجب أن يختلف. أنت تقول فعليًا أن MSBuild ليس جيدًا لـ 90٪ من المستخدمين (متجاهلًا حقيقة أنك تسحب الأرقام من مؤخرتك) ، وهو - مرة أخرى - سخيف.

اممم ، لا يغير عملية البناء لا.

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

ومع ذلك ، فإنه يغير ما هو مطلوب حتى تعمل عملية الإنشاء (مثل ملف csproj)

هذا هو الشيء الوحيد الذي يتغير فعليًا بقدر ما يراه الناس.

والسرعة التي يتم بها.

[بحاجة لمصدر]

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

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

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

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

dotnet new
dotnet restore
dotnet build

من فضلك وضح لي كيف يغير الحل المقترح أي شيء يتعلق بسيناريو "الإنشاء البسيط"

بعض منها يبني ASP.NET.

yo asp-net web
dotnet restore
dotnet build

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

لا تفعل. أنت فقط بحاجة إلى dotnet build . الذي لا يزال لديك. لا شيء يتغير هناك.

أنا هادئ أعدك.

قليلا twerp

: -1:

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

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

حسنًا ، هذا مثير للاهتمام لأن كل مطور Visual Studio. net هناك يجب أن يختلف.

مضحك ، لقد جمعت أدلة تقول شيئًا مختلفًا. من أين لك لك؟

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

نعم. لذلك نحن نتفق. كنت سأحبها حقًا إذا كانت تافهة.

هل هذا حقًا طلب غير معقول؟ هل حقا؟

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

و dotnet build سيفعل ماذا بالضبط؟ شل إلى msbuild ؟ لماذا لا يمكننا استخدام msbuild إذا أردنا استخدام MSBuild؟ ما هو بالضبط الغرض من dotnet build في هذه الحالة؟ ما الذي يضيفه إلى الأدوات؟

قليلا twerp 👎

محاولة أن تكون مضحكا ، لكنك على الأرجح على حق.

poke أعتذر بلا تحفظ.

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

لا فكرة حرفيا عما تشير إليه.

أعتقد أيضًا أنه يجب عليك بالتأكيد تناول حبة منعشة.

...

هاجم الحجة وليس الشخص.

: إدراج RolleyEyeEmoticon هنا:

مضحك ، لقد جمعت أدلة تقول شيئًا مختلفًا. من أين لك لك؟

حسنًا ، من أين أتت نسبة 10٪ / 90٪؟

نعم. لذلك نحن نتفق. كنت سأحبها حقًا إذا كانت تافهة.

الأمر الذي لا علاقة له بتغييرهم إلى msbuild ، فستواجه بالفعل مشكلة في تغيير نظام الإنشاء الحالي بعيدًا عن dotnet build .

وسوف تفعل بناء دوت نت ماذا بالضبط؟ شل خارج إلى msbuild؟

ما الذي يختلف عن استدعاء msbuild dotnet build بدلاً من dnx أو roslyn؟

لماذا لا يمكننا استخدام msbuild فقط إذا أردنا استخدام MSBuild؟

هل تريد استخدام MSBuild الآن؟ لا شيء يمنعك ، إنها حزمة صلبة هذه الأيام. اذهب المكسرات. أنا مندهش من أنك تسأل رغم ذلك ، نظرًا لمدى كرهك لـ msbuild.

ما هو بالضبط الغرض من بناء دوت نت في هذه الحالة؟ ما الذي يضيفه إلى الأدوات؟

هل نناقش بالفعل مزايا dotnet build ؟ لا تحب dotnet build ؟ أنت لا تفهم الغرض من dotnet build ؟ لا يبدو ذلك محتملًا. ما الذي تحاول أن تسأل عنه؟

neoKushan من فضلك توقف عن استعدائه. هذا ليس بناء.

حسنًا ، من أين أتت نسبة 10٪ / 90٪؟

جاء ذلك من تجربتي الشخصية. لقد اكتشفت أن حوالي 90٪ من البنيات التي أنشأتها أنا وفريقي في السنوات القليلة الماضية لم تتطلب شيئًا أكثر تعقيدًا مما يتطلبه RC1 dotnet build .

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

يرجى التوضيح ، لست متأكدًا مما تقصده هنا.

هل تريد استخدام MSBuild الآن؟ لا شيء يمنعك ، إنها حزمة صلبة هذه الأيام. اذهب المكسرات. أنا مندهش من أنك تسأل رغم ذلك ، نظرًا لمدى كرهك لـ msbuild.

_تنهد_. سؤالي هو: لماذا يجب أن يخرج dotnet build إلى MSBuild عندما يقوم msbuild بعمل ذلك بشكل جيد بالفعل؟ لماذا هناك أمران يعملان شيئًا واحدًا؟

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

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

آسف على العرض المطول الذي يشرح سؤال جملة واحدة ، لكن من الواضح أنه ضروري.

مقالة عن InfoQ :
"توصلت Microsoft إلى استنتاج مفاده أن تجربة project.json قد فشلت وستعود إلى استخدام ملفات .csproj." :خائب الامل:

كما قلت ، الإدراك مهم.

سؤالي هو: لماذا يجب أن تبني dotnet shell إلى MSBuild عندما تقوم msbuild بذلك بشكل جيد بالفعل؟ لماذا هناك أمران يعملان شيئًا واحدًا؟

لأنهم لا يفعلون شيئًا واحدًا فقط؟

لماذا يجب أن يتم تحويل MSBuild إلى csc عندما يقوم csc بعمل جيد في بناء الأشياء بالفعل؟ لماذا هناك أمران يعملان شيئًا واحدًا؟

لماذا يجب أن يخرج dotnet test إلى عداء اختبار xUnit بينما يقوم بالفعل بعمل جيد في تشغيل الاختبارات من تلقاء نفسه. لماذا هناك أمران يعملان شيئًا واحدًا؟

لماذا يجب أن يخرج dotnet restore إلى NuGet عندما يقوم NuGet بعمل جيد في تثبيت الحزم بالفعل. لماذا هناك أمران يعملان شيئًا واحدًا؟

حصلت على الفكرة ... (أتمنى: غمزة :)

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

neoKushan من فضلك توقف عن استعدائه. هذا ليس بناء.

أنا لا أعادي أي شخص عمدًا ، فأنا shederman ، وهو بالضبط ما يريد الناس أن يفعلوه:

هاجم الحجة وليس الشخص.

على الرغم من أنني في هذه المرحلة ، لست متأكدًا تمامًا من حجة shederman كما يبدو أننا انتقلنا بطريقة ما من كون XML سيئًا ، إلى أن MSBuild أصبح سيئًا إلى dotnet build الآن.

هيا نواصل.

جاء ذلك من تجربتي الشخصية.

هذا هو "الدليل" الخاص بك؟ الذي ، تذكر ، كتبته بالخط العريض:

مضحك ، لقد جمعت أدلة تقول شيئًا مختلفًا. من أين لك لك؟

والآن هي "تجربة شخصية". هذا ما نسميه الدليل "الكلوي".

لقد اكتشفت أن حوالي 90٪ من البنيات التي أنشأتها أنا وفريقي في السنوات القليلة الماضية لم تتطلب شيئًا أكثر تعقيدًا مما يتطلبه إنشاء RC1 dotnet.

وماذا تتوقع أن يتغير RC2 dotnet build أو RTM dotnet build أو ما بعد RTM dotnet build في هذا الصدد؟

يرجى التوضيح ، لست متأكدًا مما تقصده هنا.

يبدو أن حجتك هي (وصححني إذا كنت مخطئًا) شيئًا على غرار "ليس من التافه الحصول على dotnet build للقيام بشيء آخر غير ما برمجته Microsoft للقيام به". كان الأمر جيدًا في أيام DNX لأننا جميعًا أحببنا DNX ، ولكن الآن تريد Microsoft استخدام MSBuild تحت غطاء المحرك وأنت لا تحب MSBuild ، فأنت تريد خيار تغيير MSbuild لشيء آخر - وجهة نظري كانت أن هذا ليس شيئًا جديدًا ، إذا كانت لديك مشكلة مع DNX ، فلا يمكنك تغيير ذلك أيضًا ، لذا مهما كانت "مشكلتك" مع dotnet build ، فهي ليست جديدة ، وبالتالي لا أعتقد أنها ذات صلة إلى مناقشة _actual_ هنا ، والتي تمثل بنية project.json للانتقال إليها. csproj

تنهد. سؤالي هو: لماذا يجب أن تبني dotnet shell إلى MSBuild عندما تقوم msbuild بذلك بشكل جيد بالفعل؟ لماذا هناك أمران يعملان شيئًا واحدًا؟

لقد أجاب khellang على هذا بالفعل ، لذلك لا أريد أن أكرر نفسي بشكل خاص ، ولكن هذا أيضًا لأنني أوضحت بالفعل ما هو الاختلاف بإيجاز (أكره أن أقتبس من نفسي ولكني لا أعتقد أنك قرأت هذا بالفعل):

dotnet build بأكثر من مجرد استدعاء المترجم "فقط" ، ألق نظرة على تنفيذ CLI الحالي لبناء dotnet . بناء مشروع واحد هو مجرد جزء من عملية dotnet build . في النهاية _ جزء_ من هذه العملية سيكون استدعاء msbuild لكن هذه ليست وظيفتك ، هذه هي وظيفة CLI.

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

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

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

khellang تعجبني الطريقة التي عبرت بها عن ذلك ، ولكن بعد ذلك من هناك ، يمكنني تكوين ما يفعله dotnet test . يمكنني وضع عداء اختبار مختلف عن xunit في project.json ، وسوف يستدعي dotnet test عداء الاختبار هذا.

ولكن حتى الآن ، مما سمعته عن التغييرات القادمة ، لن تكون هناك قدرة مماثلة مع dotnet build . سيستخدم دائمًا MSBuild لأداء بنياته. هل هذا الفهم غير صحيح؟

neoKushan أنا لا أفكك حجة

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

neoKushan على الرغم من shederman حتى كما يبدو أننا انتقلنا بطريقة ما من XML إلى كونه سيئًا ، إلى أن MSBuild سيئ إلى dotnet الآن أمر سيء.

XML تالف. MSBuild سيء. إذا كان dotnet build يستخدم MSBuild فقط ، فهو سيء أيضًا. من فضلك ، حاول ومواكبة. الأمر ليس بهذا التعقيد. إذا لم تكن منزعجًا عن عمد ، فستستوعبه منذ زمن طويل وتمكنت بالفعل من إضافة مدخلات بناءة.

neoKushan هل هذا "

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

كما تعلم ، لدعم تصريحك بأن "... _كل فرد _ مطور Visual Studio. net هناك يجب أن لا يوافق"؟ [تم اضافة التأكيدات]

neoKushan المناقشة الحقيقية ، التي تهم في الواقع هي بنية project.json وكيف يتم دمجها في .csproj

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

"هل سيكون MSBuild هو نظام البناء الرئيسي لـ .NET Framework إلى الأبد ؟"

إذا كان الأمر كذلك ، فنحن نحتاج فقط إلى أمر msbuild ، ولسنا بحاجة إلى أمر dotnet build ، فهو أمر غير ضروري تمامًا.

ومع ذلك ، إذا قبلنا أنه في مرحلة ما قد لا يكون MSBuild هو _One True Build System_ ، فنحن في منطقة أكثر إثارة للاهتمام. بعد ذلك ، يكون الحصول على dotnet build أمرًا منطقيًا. ولكن من الأهمية بمكان إذن أن نضع هذا المستقبل في الاعتبار عند مناقشة دمج csproj و project.json.

ما كنت أحاول (ربما بشكل سيئ) أن أشير إلى أن الخيار الأفضل (في ذهني) سيكون محاولة الاحتفاظ بفصل واضح بين ملفات تعريف المشروع وملفات _ تعريف الإنشاء_. سيؤدي هذا إلى إعدادنا بشكل أفضل مقابل dotnet build يمكنه دعم محركات إنشاء متعددة. إذا ، بدلاً من ذلك ، قمنا بنقل كل شيء إلى csproj ، فإننا نقفل أنفسنا في عالم MSBuild.

ونعم ، أفهم أن وضع "البناء الحقيقي الوحيد" هذا موجود في DNX. لكنني لم أستجوب ذلك بعد ذلك لأنني أحببت البناء الذي كان لدينا. آه ، المواقف التي نضع أنفسنا فيها عندما نقبل بصراحة الظلم _ مثل _ 😉.

لذلك ، ضع في اعتبارك موقفًا يكون لدينا فيه dotnet build قادرًا على استخدام واحدة من عدة أدوات بناء ، اعتمادًا على التكوين. تمامًا مثل dotnet test يمكنك استخدام واحد من العديد من المتسابقين الاختباريين. الآن ، بالنظر إلى هذا العالم الخيالي ، الآن كيف يمكنك دمج csproj و project.json؟ هذا هو مناقشة أريد أن يكون.

rhires من مستوى عالٍ جدًا dotnet build :

  1. يجمع ملفات المشروع
  2. تحديد ما إذا كان قد تم استيفاء الشروط المسبقة لبناء تزايدي
  3. يقرأ المشروع json
  4. يحدد الأطر المستهدفة
  5. لكل مشروع:

    1. بناء انها تبعيات

    2. إذا كانت الزيادة ، تحقق مما إذا كانت إعادة البناء مطلوبة

    3. يحدد أدلة الإخراج

    4. يجمع ملفات المصدر

    5. يحدد خيارات الترجمة

    6. يدير البرامج النصية قبل التحويل البرمجي

    7. يقوم بتشغيل المترجم مع الملفات والخيارات المصدر

    8. يدير البرامج النصية بعد التجميع

    9. إخراج التقارير

shederman شكرا لك! من هذه النقطة ، ما الذي من شأنه أن يضيف / يطرح / يستبدل إلى / من / في هذه العملية؟

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

وعاء -> غلاية

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

XML تالف. MSBuild سيء. إذا كانت dotnet build تستخدم MSBuild فقط ، فهي سيئة أيضًا.

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

من فضلك ، حاول ومواكبة.

ماذا عن _you_ مواكبة؟ من فضلك ، وضح لنا من أين حصلت على هذه الفكرة بأن dotnet build سيتصل فقط msbuild . من قال لك ذلك؟ حيث لم تقرأ ذلك؟

دليلي هو 281 مستجيبًا من أصل 383 ممن اعتقدوا أن عودة .NET Core إلى MSBuild فكرة سيئة. و 85 من هؤلاء المستجيبين الذين اعتقدوا أن MSBuild معطلة بشكل أساسي. هذا هو دليلي. أين لك بالضبط؟

وقد استحوذت على 10٪ من هذه الأرقام ، أليس كذلك؟ تذكر أن هذه هي مطالبتك:

أود أن أقول إن قوة وتعقيد MSBuild مناسبان للغرض لحوالي 10٪ من المباني.

ثم قلت فيما بعد:

مضحك ، لقد جمعت أدلة تقول شيئًا مختلفًا.

فأين هذا الدليل؟ أود أن أعرف كيف استخلصت هذا الرقم من "دليلك".

كما تعلم ، لدعم تصريحك بأن "... كل مطور Visual Studio. net هناك يجب أن يختلف"؟

سهل: https://msdn.microsoft.com/en-us/library/ms171468.aspx

يستضيف Visual Studio MSBuild لتحميل المشاريع المُدارة وإنشائها.

إذا كنت تستخدم Visual Studio لبناء مشاريعك ، فإنك تستخدم MSBuild. حتى عند العمل مع .net core اليوم ، حتى مع RC1 VS تستخدم MSbuild تحت الغطاء. قد لا تعجبك MSbuild ، ولكن كما قلت ، يستخدمه كل مطور VS تقريبًا سواء أدركوا ذلك أم لا.

الخطة التي أعربت عنها شركة MS هي أن MSBuild ستكون مركز بناء الكون.

أنا لا أتفق مع هذا. لم يقلوا أبدًا أنه سيكون المركز ، كل ما قالوه هو أن بعض أجزاء project.json سينتهي بها الأمر بالعودة إلى .csproj - بعد ذلك ، لم يقلوا كلمة واحدة حول إلى أي مدى يغير هذا dotnet build العملية.

"هل سيكون MSBuild هو نظام البناء الرئيسي لـ .NET Framework إلى الأبد؟"

إذا كان الأمر كذلك ، فنحن نحتاج فقط إلى أمر msbuild ، ولسنا بحاجة إلى أمر بناء dotnet ، فهو غير ضروري تمامًا.

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

dotnet new
dotnet restore
dotnet build

حتى إذا أصبح msbuild مكونًا أساسيًا في dotnet CLI ، فإن هذا لا يغير حقيقة أن بناء dotnet هو الغلاف النظيف والبسيط حول ما هو (وسيظل دائمًا) نظامًا معقدًا إلى حد ما. الجحيم ، نصف سبب وجود dotnet CLI (و DNX قبله) هو على وجه التحديد الابتعاد عن جحيم حجة سطر الأوامر الذي هو MSBuild في النهاية. إن حجتك تشبه إلى حد ما قول "لماذا نحتاج إلى أمر npm install يمكنني فقط curl الحزمة؟". بالتأكيد ، يمكنك القيام بكل ذلك يدويًا إذا كنت تريد ذلك حقًا ، لكنك لن تكسب شيئًا منه تقريبًا. فماذا إذا كان dotnet build يستخدم msbuild تحت الغطاء؟ من شبه المؤكد أنك لن تراها أبدًا ، أو تحتاج إلى معرفتها.

لا يمكنك مقارنة تجربتك القديمة مع MSBuild ، فالأمر مختلف تمامًا. لقد أحرقنا جميعًا (على ما يبدو) بسبب ذلك لأننا اعتدنا على فتح VS ، وإنشاء مشروع وإنشاءه فقط ، ولكن بعد ذلك عندما تذهب لإنشاء نفس المشروع على خادم بناء ، فإنه يشكو فجأة من الهراء يجب أن يعمل فقط. ربما كان أحد أفضل الأشياء التي فعلتها Microsoft مع TFS 2015 هو إنشاء تعريف بناء يرتبط بـ _Visual Studio_ بدلاً من _MSBuild_ لأنك تعود إليه "تعمل فقط". هذا هو بالضبط ما تمثله سلسلة أدوات البناء هذه - لا يُقصد بـ dotnet build استبدال نظام الإنشاء بالكامل ، إنها معنية فقط ببناء مشاريعك ، حتى لو كانت تستخدم MSBuild تحت الغطاء. إذا كنت ترغب في استخدام شيء مثل TeamCity أو Jenkins ، فإن dotnet build هو كل ما عليك إخبارهم بالاتصال به وستقوم dotnet بالباقي. _How_ لا يهمك.

الشيء الوحيد - وأعني هذا تمامًا ، الشيء الوحيد الذي يتغير بالفعل هو ملف project.json / csproj. هذا هو_. هذا هو السبب في أن كل هذا الجدل حول ما يفعله dotnet build حقًا وما هو MSBuild جيدًا وسيئًا هو _ بلا نقطة_ مطلقًا.

neoKushan فقط توقف ...

neoKushan فقط توقف ...

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

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

سيتم دمج معظم الأشياء غير التابعة لـ NuGet في csproj. ماذا سيحدث لأشياء NuGet إذا لم يكن هناك project.json (nuget.json؟)؟

توفر طريقة للمستخدمين لإدارة تبعياتهم بالطريقة التي يحبونها ، وربما توفر dotnet nuget افتراضيًا لأن NuGet راسخ في مجتمع .net.

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

هل سنحتفظ بالتحسس الذكي لإدارة التبعية؟ هذه في الأساس واحدة من أفضل الميزات التجريبية التي نوفرها لـ project.json.

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

قد ترغب في تقديم إكمال شل أيضًا ، مما سيشجعك كثيرًا من الإعجاب من الأشخاص الذين يستخدمون bash أو zsh :

dotnet nuget add S[tab] قائمة إكمال لمعرفات المشروع بدءًا من S

يجب أن يكون وجود intellisense في ملفات msbuild * proj ممكنًا أيضًا إذا كنت تريد خبز علامة <NuGet> هناك ، ولكن لا تقم بربط nuget بالنظام البيئي بالكامل ، مثل <Package>NuGetPackageId</Package> shouldn ' t يساوي <NuGet>NuGetPackageId</NuGet> أو يجب أن تكون هناك طريقة بسيطة للغاية (وموثقة ومدعومة جيدًا) لتجاوز هذا.

يحتوي المكون الإضافي لـ Paket Visual Studio على تكملة تلقائية على nuget ، إنه يعمل ولكنه بطيء نوعًا ما على أي حال لأنني أفترض أن الأمر يستغرق بعض الوقت لإرجاع الاستجابة من nuget.org.

هل نحتفظ بتنسيق JSON لإدارة التبعية؟ XML أمر مروع لهذه الأنواع من الأشياء (انظر Maven). JSON أسهل في تمثيل تلك التبعيات.

إذا كنت تبحث عن أفكار للتنسيق ، فيمكنك إلقاء نظرة على paket.dependencies ، وإلا ، فأنا لا أعتقد أن الأمر مهم للغاية ، فقد كان تحرير project.json لطيفًا مثل تحرير packages.config فيما يتعلق بالتعامل مع NuGet ، افعل كل ما هو مناسب للمستخدمين الذين يختارون NuGet كمدير تبعية للحزمة (وهو ليس 100٪ من المستخدمين ولا يتعين عليهم ذلك)

كملاحظة جانبية ، إذا كنت لا تزال بحاجة إلى ملف lock ، فهل يمكنك جعله قابلاً للقراءة من قبل المستخدم ، وهو شيء يتم التحقق منه في المستودع ، ويسهل إجراء الفروق فيه؟

rhires من هذه النقطة ، ما الذي يمكن أن يضيفه / يطرحه / يحل محلّه / من / في هذه العملية؟

حسنًا ، هذا يعتمد على كيفية دمجها. إذا قاموا بعمل "قفل صلب" ، بدمج msbuild عميقًا في بناء dotnet ، والذي يبدو أن المعلومات العامة تشير إليه هو نهجهم المفضل ، فسيتم استبداله بالكامل بـ msbuild.

ومع ذلك ، إذا جعلوا dotnet build قابلاً للتكوين ، أتوقع أنه سيعمل شيئًا مثل:

  1. يجمع ملفات المشروع
  2. يقرأ المشروع json
  3. يحدد الأطر المستهدفة
  4. حدد أداة البناء المراد استخدامها
  5. قصف أداة البناء
  6. إخراج التقارير

neoKushan لهذا السبب كل هذا الجدل حول ما يفعله بناء dotnet حقًا وما يعتبر MSBuild جيدًا وسيئًا لا معنى له على الإطلاق.

👍

ما أريد _ مناقشة_ هو الشكل الذي يجب أن يبدو عليه كل من project.json و csproj في عالم يمكن أن يتحول فيه dotnet build إلى MSBuild كأحد _ العديد من أدوات البناء الممكنة_. هل هذا مقبول؟ هل يمكننا التحدث عما سيكون في project.json مقابل ما سيكون في csproj ، بالنظر إلى ذلك؟

لأننا إذا _استطعنا_ أن نناقش ذلك أعتقد أن هذا الخيط يمكن أن يصبح في الواقع بناءًا.

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

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

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

shederman من أجل استمرار مناقشة مثمرة ، أود أيضًا أن أرسم خطاً لمناقشة الآثار المترتبة على التغييرات المقترحة.

أعتقد أن المناقشة الأساسية هنا يجب أن تكون على تخطيط وشكل ملف .csproj "الجديد" وما يحدث لـ project.json (أو على وجه التحديد ، هيكل "المشروع" ككل). لا أعتقد أن نظام البناء ، سواء أكان msbuild أم لا ، وكيف يعمل بناء dotnet ، وما إلى ذلك ، يدخل في نطاق _ هذه المشكلة. هذا لا يعني أن المناقشات حول ذلك غير مرحب بها أو غير صالحة ، فقط لأنها لا تنتمي إلى هذه القضية _الخاصة_ ، بل يجب أن تكون قضايا منفصلة. كما يمكن لأي مطور متمرس أن يشهد ، فإنه أمر محبط للغاية عندما يحتوي تقرير الخطأ على أخطاء متعددة ومنفصلة وعادة ما يكون أول شيء تفعله هو تقسيمها إلى عدة مشكلات لتتبعها - أعتقد أن هذا هو الشيء المفقود هنا حقًا.

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

لا أريد التعامل مع merge hell لمجرد أنني أضفت ملفًا بتنسيق .cs ، ولا أريد التعامل مع ملف XML بطول ألف سطر لمجرد أن بعض الأنظمة التي - لا أهتم بها - تعتمد عليها - لا أفعل ذلك. لا أعتقد أن أي منا يفعل ذلك وكان ذلك مصدر قلق لتطوير VS لسنوات حتى الآن. كان لدينا بصيص من الأمل في تنسيق project.json كما هو قائم اليوم لأنه كان _ أفضل بكثير _ مما كان عليه من قبل ، لذلك أفهم تمامًا وأعرف سبب تلاشي الغضب بسرعة عند مجرد تلميح إلى أننا سنعود إلى "الأيام الخوالي السيئة" ، ولكن في الوقت نفسه ، من الجدير القول بأنه لا ينبغي لنا أن نخدع أنفسنا - إن Project.json اليوم ليس بأي حال من الأحوال _perfect_ ، إلا أنه يحتوي على مجموعة من المشكلات الخاصة به وعلى الرغم من أنها قد تكون ثانوية بالمقارنة مع قضايا csproj "القديمة" ، يجدر بنا أن نكون موضوعيين ومناقشة أين يمكن تحسين الأشياء وما يمكن أن يكون أفضل.

هناك بالتأكيد أفضل احتمال في كلا العالمين.

أعتقد أن المناقشة الأساسية هنا يجب أن تكون على تخطيط وشكل ملف .csproj "الجديد" وما يحدث لـ project.json (أو على وجه التحديد ، هيكل "المشروع" ككل).

كما تعلم ، تم ذكره عدة مرات في هذا الموضوع ، لكنني اعتقدت أنني سأذكره مرة أخرى ، فقط لمشاركة "آها الشخصية" الخاصة بي هذا الصباح ، ولكن هناك مجهود آخر كامل جارٍ مع نظام المشروع القائم على روزلين - أو أن نكون أكثر دقة من الملف التمهيدي الخاص به في نظام المشروع المركزي (CPS) . من خلال استعراض وثائقه ، يبدو أنه يمثل جهدًا لتعريف المشروع أكثر من كونه عملية. ربما هذا هو المكان الذي يتم فيه دمج كل السحر بين .json و .csproj؟ وبعد ذلك سيتم إهمال MSBuild كنقطة نهاية للعملية؟ لن يكون هذا لطيفًا. :ابتسامة:

على أي حال ، لقد بدأت / شاهدت هذا الريبو لبدء الحصول على تحديثات حول ما يحدث هناك. : +1:

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

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

ما يقلقني ، هو حجج مثل "msbuild is battle test" ، و msbuild العادي هو لكن xplat الحالي لا يبدو كذلك. عندما ننظر إلى المشكلات المتعلقة بـ github repo ، فإنها ليست موجودة تمامًا بعد. بالإضافة إلى ذلك ، قال فريق msbuild بالفعل أن دعم تنسيق التسلسل الجديد / المحسن لن يكون هدفًا لـ msbuild بل لنظام بناء جديد (والذي لن يحدث في أي وقت قريب).

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

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

@ Mike-EEE نعم هناك أمل :)

أنا متأكد تمامًا من أن الاتجاه الحالي هو جعل project.json يصبح nuget.json - والذي نأمل أن يحل مشكلة التبعية ويترك معظم وظائف project.json الحالية في لباقة.

الشيء الوحيد الذي لا يمكنني معرفته هو كيف يؤثر ذلك على الاستهداف المتعدد ، هل يجب أن يكون كل من csproj و nuget.json على دراية وفهم ما يستهدفه كل منهما؟ هل ينتهي بنا الأمر باستخدام csproj لكل هدف (yuck!) ، أم يمكنهم توسيع .csproj بما يكفي لحسابه؟

project.json يصبح nuget.json

مجرد فضول هنا .. أين _تحدث هذه المحادثة؟ لقد انضممت إلى فريق nuget من قبل للتثبيت بتنسيق معين. فيما يتعلق بـ project.json ، قالوا إن هذا كان مصدر قلق لأدوات Visual Studio وشيء لا يمكنهم معالجته. الآن يبدو أن الديناميكيات قد تغيرت ونسخ / لصق المزيد من نفس النوع من المشاكل. : stuck_out_tongue:

لتوضيح قلقي ، هو أننا نمزج الآن JSON و XML معًا مما ينتج عنه عدم كفاءة على أقل تقدير.

مجرد فضول هنا .. أين تحدث هذه المحادثة؟

حسنًا ، تم ذكره هنا في الأصل: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may definitely/

من الممكن أن يبقى ملف project.json ، ويحتوي على جميع مراجع الحزمة الخاصة بـ NuGet وإعادة تسميته إلى nuget.json.

وأعتقد أن هذا هو حقًا موضوع المناقشة هنا ، ما مقدار ما تخرجه من project.json وتضعه في ملف csproj. في مشاريعي ، كانت غالبية project.json عبارة عن مراجع للحزم ، لا سيما إذا كنت أستهدف أطر عمل متعددة. ما ورد أعلاه يشير إلى أن كل هذا سيبقى وسيتم إخراج البتات "الأخرى" فقط. في تجربتي (مرة أخرى: شخصية) ، لا تتغير هذه البتات "الأخرى" كثيرًا خلال حياة المشروع ، لذلك حتى لو كانت في XML فهي ليست كثيرًا من XML ويجب أن تكون ثابتة إلى حد ما ... يأمل المرء .

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

حسنًا ، تم ذكره هنا في الأصل ...

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

أوافق على أن خلط ومطابقة XML و JSON للتكوينات المختلفة له رائحة كريهة بعض الشيء

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

هاها ... بالحديث عن ذلك ، كتابة ما سبق جعلني أسحب أرشيفات OL. ها أنا مرة أخرى في عام 2014 وأنا أعرض قضية (نعم ، لقد خمنت ذلك!) Xaml بدلاً من JSON هاهاها ، انظر إلى كم كنت شابًا وساذجًا تمامًا! لطيف جدا ومتواضع! يا فتى ، هل لدي العالم لأتعلمه. : stuck_out_tongue: لكن ، سأقول أنه كان هناك بعض التقدم. لقد تخلصنا من ملف .ini المستخدم في تكوين خادم الويب ، بعد كل شيء. :ابتسامة:

neoKushan هناك بالتأكيد أفضل إمكانية في كلا العالمين.

👯 👯 👯

neoKushan ، أنا متأكد من أن الاتجاه الحالي هو أن يكون لديك project.json يصبح nuget.json ... الشيء الوحيد الذي لا يمكنني معرفته هو كيف يؤثر ذلك على الاستهداف المتعدد ، هل يجب أن يكون csproj و nuget.json على دراية وفهم ما يستهدفه كل منهم؟

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

  • قائمة ملفات المصدر
  • تبعيات المشروع
  • الأطر المستهدفة
  • أوامر المشروع (مثل الويب والاختبار وما إلى ذلك)
  • ويبروت
  • البيانات الوصفية
  • نسخة اللغة

لا أعتقد أن ما يلي يجب أن يكون موجودًا في ملف تعريف البناء ، لكنني سأفعل ذلك إذا كان الأمر كذلك:

  • تعريفات التكوين
  • مخطوطات ، قبل وبعد

يجب أن يكون ما يلي على الأرجح في ملف تعريف البناء:

  • خيارات التجميع (باستثناء إصدار اللغة)

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

shederman هل نحتاج إلى توضيح ما تعنيه ب "تعريف البناء"؟ ربما تكون المصطلحات الخاصة بي معطلة ، لكنني لن أسمي المشروع الحالي json ملف _تعرّف البناء_ بل ملف _تعريف المشروع_ (ونفس الشيء ينطبق على ملف csproj الجديد). ربما دلالات ، لكن بالنسبة لي ، يقترح تعريف البناء أنه يعرف كيف تُبنى الأشياء ، بينما يحدد تعريف المشروع ما الذي يتكون منه المشروع ويترك خطوات البناء لشيء آخر.

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

يمكن تحديد الكثير من المشروع فقط من خلال الاصطلاح ، مثل كيف يأتي اسم التجميع من مجلد المستوى الأعلى. وفقًا لخط التفكير هذا ، سيكون _nuget.json_ أي شيء له علاقة بـ nuget - لذلك ستدخل الحزم / التبعيات هناك وأعتقد أننا جميعًا سعداء بذلك.

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

ثم مرة أخرى ، هناك ما هو أكثر من nuget من مجرد مراجع الحزمة ، فهو يحتوي أيضًا على الحزمة _definition_ والإصدار أيضًا عندما تصبح مكتبتك _تصبح _ حزمة nuget. يبدو إلى حد ما كما لو أن nuget.json يقوم بعمل شيئين مختلفين على الأقل وقد بدأت الرائحة في الظهور قليلاً. ربما (فقط spitballing هنا) ، سيحدد csproj تفاصيل الحزمة ، والأطر المستهدفة وما إلى ذلك ويمكن أن يشير كل إطار هدف إلى ملف .json ، وهو في الأساس حزم nuget. بمعنى آخر ، بدلاً من ملف nuget.json واحد ، سيكون لديك ملف .json منفصل لكل إطار عمل. قد تكون هذه فكرة رهيبة ، لم أفكر فيها بشكل خاص.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

كان لدينا خياران. كان أحدها هو نقل جميع مشاريع .NET لاستخدام project.json. سيتطلب ذلك منا القيام بأعمال الأدوات التي تمس جميع أنواع المشاريع في Visual Studio و Xamarin وشركائنا مثل Unity. سيتعين علينا توسيع project.json لدعم جميع سيناريوهات الإنشاء المطلوبة لكل نوع من أنواع المشاريع هذه وتقديم قصة ترحيل. كان هناك خيار آخر وهو بناء الجسور بحيث يمكن لمشروع .xproj الرجوع إلى مشروع .csproj ويمكن لمشروع .csproj الرجوع إلى مشروع .xproj في Visual Studio و Xamarin Studio. يحتوي الجسر أيضًا على تحديات ، على سبيل المثال عندما ينشئ العميل مشروعًا ، يتعين عليه الآن اختيار .xproj أو .csproj ، مما يضيف المزيد من الخيارات والتعقيد.

و

بعد النظر في اختياراتنا ، كان من الواضح أنه سيكون من الأسهل نقل مشاريع .NET Core إلى .csproj / MSBuild بحيث تستخدم جميع مشروعات .NET نفس الأدوات ونظام الإنشاء.

نحن نخطط لتحسين .csproj لدعم الوظائف المفقودة:

  • لا توجد قائمة بالملفات في نظام المشروع
  • أداة CLI لإجراء أي عمليات على ملف المشروع ، بالنسبة لمعظم السيناريوهات ، لن تقوم بتحرير الملف
  • بناء الحزم مباشرة من المشروع
  • متعدد الاستهداف

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

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

بافتراض أن .csproj لا يزال يعني مشروع C # ، سيكون هناك بالطبع أهداف أخرى للمشاريع غير C # ، أليس كذلك؟ [بن]

نعم. [سكوت ح]

أخشى بعض الشيء أن .net سوف تكون عالقة مع نظام بناء معقد-قديم-justForTooling مثل msbuild ، ربما يجب أن نبدأ به لبدء dotNetCore ثم التخطيط لنظام بناء حديث جديد؟
لإعطاء كل شخص الأمل والقيام بالأشياء دون التسرع في الشحن. netcore.

لا أحتاج في كثير من الأحيان إلى تحرير ملفات msbuild ، ولكن عندما أحتاج إلى ذلك يكون صعبًا للغاية ، فإن النهج التصريحي يجعلك تفقد نفسك في التدفق ، أحضر مثاليًا ، ولا يبدو أن أحدًا قادرًا على حل مشكلة بسيطة مثل https: // github .com / madskristensen / BundlerMinifier / قضايا / 89
إذا لم يتمكن أي شخص بعد 6 أشهر من تشغيل مهمة (مهمتان مختلفتان لا يعرف كل منهما شيئًا عن الآخر) تلو الأخرى دون عمليات قرصنة قذرة أو بطريقة مضافة ، فربما يكون هناك شيء يجب إصلاحه هناك.

شكرا

أداة CLI لإجراء أي عمليات على ملف المشروع ، بالنسبة لمعظم السيناريوهات ، لن تقوم بتحرير الملف

: -1:

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

تعتبر أدوات cli رائعة للأتمتة ولكنها طريقة سيئة لأداء المهام باستثناء المهام الأساسية مثل npm install أو dotnet restore . إذا كان علينا تعلم أشياء مثل dotnet buildoptions define add --framework net451 SOME_DEFINE فمن المؤكد أنه سيء ​​للغاية. هذه خسارة كبيرة.

قصة التطوير الجيدة هي:

  • مشروع قابل للتحرير بسهولة وبناء الملفات
  • نظام بناء شكلي
  • أدوات cli بسيطة ومصممة جيدًا وكاملة
  • واجهة المستخدم العظيمة وأدوات IDE

جعل واحدًا من هؤلاء الفقراء (الذي كان عظيماً من قبل) لجعل الآخر مقبولاً هو مجرد غباء.

حجة الوحدة و xamarin سيئة للغاية في الواقع. لا أعتقد أنهم سينتقلون إلى .net core قريبًا ، والعودة للوراء من أجل راحتهم هي مجرد أعرج عند التصميم لمستقبل .net.

ونظرًا لأن كل برامج .NET تستخدم نفس الأدوات ، يمكننا عندئذٍ النظر في تحسين MSBuild

لا يتم تحسين MSBuild قبل أن نجبر عليه ...

هذه المقالة ليست في الحقيقة منشور المدونة الذي ننتظره ويؤكد أن .net الأساسية يتم تضليلها هناك.

تعتبر أدوات cli رائعة للأتمتة ولكنها طريقة سيئة لأداء المهام باستثناء المهام الأساسية مثل تثبيت npm أو استعادة dotnet.

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

بالنسبة لي ، يبدو أن هناك حاجة إلى إطار عمل من نوع ما لإنشاء API ثم يتم إنشاء إصدارات CLI و GUI تلقائيًا من أجلك.

يمكن أن نسميها ... CLIGUIAPI! : +1:: +1:: +1: تم حل المشكلة

هذه القضية صراع ثقافات / تفضيل / فلسفة

بالتأكيد وهذا أحد الأساليب التي لا يمكنك حلها باستثناء معالجة كل نهج بأفضل نهج ممكن. node.js ولست من أكبر المعجبين بهذا المكدس قام بعمل رائع في هذا باستخدام أداة cli الرائعة npm و package.json. يتم التعامل مع جزء Gui بواسطة بائعين مختلفين (webstorm ، vs code ، visual studio). أنظمة البناء الفاخرة مثل gulp اختيارية بنسبة مائة بالمائة.

ربما أنا أقلية في هذا وربما لا ، لكن بينما أحب project.json ، فإن الأسباب موضحة هنا https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json / له معنى كبير بالنسبة لي. أشعر بثقة تامة من أننا سننتهي بتجربة جيدة ، لذا فأنا لست قلقًا بشأن هذا الأمر ولا يقلل بأي حال من حماستي لهذه الأطر الجديدة. يبدو الناس سريعًا جدًا في الخروج من مفترق الملعب والتصرف كما لو كانت نهاية العالم حتى قبل رؤية ما ستكون عليه التجربة النهائية

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

ماذا عن الاحتفاظ بكل من project.json و .csproj ، حيث يتم إنشاء .csproj بواسطة الأمر dotnet restore ولا تتم مزامنتها في التحكم في الإصدار افتراضيًا؟ سيكون الاختلاف هو ، بدلاً من إنشاء ملف "project.lock.json" dotnet restore (والقيام بأشياء أخرى) ، سيتم إنشاء (أو تحديث) ملف ".csproj". حتى كلاً من "project.lock.json" و ".csproj" يمكنهما البقاء حيث يتم إنشاء كليهما تلقائيًا. يمكن استخدام العلامات في dotnet restore لتوليد csproj. في الإعلان ، تقول Microsoft بالفعل - "أداة CLI للقيام بأي عمليات على ملف المشروع ، بالنسبة لمعظم السيناريوهات ، لن تقوم بتحرير الملف". IMHO ، dotnet restore هو الأكثر ملاءمة ليكون أداة CLI تلك ، والتي ستأخذ project.json كمدخل. المكاسب ستكون-

  • يمكن أن يظل كلا تنسيقي project.json و .csproj بدون تغيير. وهذا يعني أن .csproj الذي تم إنشاؤه حديثًا سيكون متوافقًا مع الإصدارات السابقة من Visual studio والأدوات الأخرى. dotnet restore إدراج قائمة صريحة "تتضمن" بملفات المشروع في ملف .csproj.
  • نظرًا لأنه يتم إنشاء .csproj تلقائيًا وليس في التحكم في الإصدار ، لا يتعين على المطورين التعامل مع التحرير اليدوي ودمج .csproj.

yeahno

نعم لا.

إغلاق. كل ما يمكن أن يقال قد قيل.

إذا كنت ترغب في معرفة كيفية صنعها وكن في فريق التصميم الذي يتحدث عن ذلك ... يرجى القيام بذلك .

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

MaximRouiller آمل أن تجمع التعليقات التي تركز على الإجابة على أسئلتك الأولية على الرغم من مقدار الضوضاء.

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

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

ولكن ، كل هذا يبدو موضع نقاش: لقد أغلق MaximRouiller و MS كل شيء. لقد تم تجاهل ملاحظاتك وقتلها ، شكرًا على الاتصال.

بشكل عام ، كان csproj بالكامل -> project.json -> شيء csproj عبارة عن مجموعة من القرارات السيئة التي ستعود لتطارد MS في اعتماد .NET IMHO. سيستمر اتجاه مطوري البرامج في التخلي عن .NET من أجل مراعٍ أكثر اخضرارًا بلا هوادة.

image

فى غاية الحزن.

shederman لا توجد علاقة بين انخفاض مؤشر Tiobe لـ C # وقرار العودة إلى csproj. كما أن انخفاض مؤشر Tiobe ليس مؤشرًا على تدهور صحة النظام البيئي C #. المزيد من اللغات التي تدخل السوق تجعل من الصعب على أي لغة واحدة الحفاظ على حصة كبيرة في السوق.

Everything is awesome

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

csproj هو شيء أتحمله ، وليس أفضل.

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

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

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

المزيد من اللغات التي تدخل السوق تجعل من الصعب على أي لغة واحدة الحفاظ على حصة كبيرة في السوق.

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

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

@ Mike-EEE سمعوا أنك قادم: stuck_out_tongue_winking_eye:

محبط أنهم فعلوا هذا. لقد قمت بالتدوين حول هذا الموضوع: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

من موقف اليوم: https://youtu.be/YJsQ3tnS7Ew؟t=38m45s

يتناول على وجه التحديد project.json هنا: https://youtu.be/YJsQ3tnS7Ew؟

على الرغم من أن تعديل تنسيق project.json أسهل بكثير (إلا إذا كنت في تلك المرحلة من .NET dev لكونك قرد مجموعة بيانات السحب والإفلات) ، فإن أكبر مشكلة بالنسبة لي هي أنه لا أحد يكلف نفسه عناء تحديث مكتباته إلى. نت كور. تمكنت حتى الآن من الحصول على فرع واحد من Restsharp يعمل ، لكن هذا يستخدم تنسيق project.json. JSON.NET و Structuremap و NUnit وما إلى ذلك جميعها لها فروع DNX قديمة حيث يبدو أن المطورين قد تخلى عن الأمل.

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

دافعي الرئيسي للانتقال إلى vNext هو الاستفادة من استضافة Linux الرخيصة و Docker. سيكون من الحكمة استخدام أداة ترحيل المشروع في أسرع وقت ممكن لأن مكتباتهم سيتم إعاقة معظم الأشخاص تمامًا من خلال مراجع nuget التي تفتقد إلى إصدارات .NET Core.

yetanotherchris dnx كان مفهومًا في rc1 ، فقد تغير إلى dotnet cli في rc2 ، لذا فإن معظم مشاريع أو فروع dnx ستكون قديمة في هذا الوقت

project.json لا يزال هنا ولازمًا لـ rc2 ، مناقشة حول اختفاءه في المستقبل بعد RTM

يعمل json.net ويعرف أيضًا باسم newtonsoft.json ويستخدمه إطار العمل نفسه ، وأنا أستخدمه في مشروعاتي أيضًا
nunit غير متوافق ، يستخدم الجميع xunit afaik
Structuremap لديه ومكتبة متوافقة مع rc2

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

yetanotherchris إذا كنت تستخدم عمليات الاستيراد في project.json الخاص بك ، فيمكنك تحديد الألقاب القديمة غير القياسية وستستخدمها:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

ربما لهذا السبب لم يكلف الكثير من الناس عناء تحديث مكتباتهم حتى الآن ، فلا داعي للوصول إلى هدف متحرك آخر قبل RTM الفعلي.

joeaudette كنت أتحدث عن اسم الفرع (DNX) وليس أداة سطر الأوامر dotnet . يستخدم الكثير من الأشخاص NUnit ، إنه إلى حد كبير مجموعة الاختبار الفعلي خارج MsTest. لست متأكدًا من المكان الذي تعثر فيه على حزم JSON.NET أو Structuremap ، فهناك إصدار غير رسمي من Structuremap يسمى DNX وفرع Newtonsoft هنا و .NET Standard 1.0 beta على nuget.org (معيار .net أصبح الآن زائدا عن الحاجة بقدر ما أعرف).

neoKushan شكرا ، سوف أنظر في ذلك.

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

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

(معيار .net الآن زائدة عن الحاجة بقدر ما أعرف).

ما الذي جعلك تقول هذا؟ Netstandard لن يبتعد عن تغيير المشروع ، إنه موجود لتبقى. ستكون قادرًا على استهداف معايير الشبكة في ملفات csproj المستقبلية. Netstandard ضروري للغاية. أحد الأسباب الرئيسية وراء تخليهم عن project.json هو توحيد النظام البيئي .net بأكمله وهذا ما يجلبه netstandard أيضًا إلى الطاولة.

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

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

yetanotherchris عليك أن تتذكر أن rc2 عبارة عن معاينة ولذا عليك البحث عن حزم معاينة من جهات خارجية أيضًا
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

لا أعلم عن NUnit إذا كان سيتم دعمه لاحقًا ولكن في الوقت الحالي على مشاريع .NET Core و ASP.NET Core يستخدم الأشخاص xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

yetanotherchris أعتقد أننا يمكن أن نتفق جميعًا على أنه كان يجب تسمية rc1 beta9 ، rc2 هو أول إصدار حقيقي لجودة rc
project.json وهذه الأدوات ليست جزءًا من إطار العمل في حد ذاته ، وستظل الأدوات قيد المعاينة وعرضة للتغيير لفترة من الوقت حتى عندما يكون إطار العمل هو RTM

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

سكوت هانتر ، dotnetConf 2016 ، اليوم الأول ، الخطاب

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

بصفتي مدير برنامج .NET و Visual Studio ، أشك في أن coolcsh لديه وقت

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

ها هي فرصتك للجميع:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

أضع دولارًا في جرة البقشيش ، إذا جاز التعبير. : stuck_out_tongue:

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

كما قلت مرات عديدة ، أنا مطور مؤسسة في أحد البنوك الكبرى ، عميل مؤسسة. لم تتم استشارتنا بشأن هذه التغييرات. إذن من كان بالضبط "مطورو مشروع المادة المظلمة"؟ هذه المعلومات على ما يبدو سرية للغاية. 007 مستوى الاشياء.

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

shederman هل أنت مطور جوال مؤسسي أو مطور UWP مؤسسي؟ أو Enterprise Unity Dev؟

لا شيء مما سبق. نكتب الأنظمة الأساسية لإدارة الأصول والتكامل المصرفي. بعض الأشياء عبر الإنترنت أيضًا.

shederman أظن أن هذا قد يكون سبب عدم سؤالك؟

الرجاء التوضيح؟

هل تقول حقًا أن مطوري الشركات الوحيد الذي يدعمه MS الآن هم أولئك الذين يقومون بأعمال متنقلة لـ 1٪ من السوق ، وتطبيقات UWP لأم ، و 5٪ من المستخدمين المهتمين ، وتطوير الألعاب؟ من بين طيف التطوير الكامل ، هل MS يديرون ظهورهم لكل شيء ما عدا ذلك ؟

أم. رقم.

أنا أقول إن التغييرات حدثت بعد التحدث إلى هذه المجموعات ، ولهذا السبب لم يتم سؤالك. يتعين على Microsoft دعم جميع مطوريها ، وليس مطوري ASP فقط.

نعم ، إذا كانوا سيدعمون جميع مطوريهم ، فربما ينبغي عليهم التحدث إلى جميع المطورين. ربما نتحدث فقط لاختيار فرعية 5٪ من المطورين المؤسسة ليست وسيلة جيدة لقياس آراء المطورين المؤسسة ككل.

لذا ، للاستماع إلى رأي بنك كبير ، يجب أن نحول كل تطويرنا إلى UWP / Unity / Mobile؟

هذا كلام سخيف.

ربما ينبغي عليهم التحدث إلى جميع المطورين.

أليس هذا ما كانوا يفعلونه منذ أكثر من عامين؟

shederman لمجرد أنك لم تُسأل شخصياً ، فأنت تشير ضمناً إلى أنه لم يشارك أي شخص آخر يغطي نطاق تطويرك؟

أيضًا ، توقف عن اختلاق هذه الأرقام - فهذه أرقام سخيفة.

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

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

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

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

هناك طريقة أخرى للنظر إليها - والطريقة التي أراها بها شخصيًا - وهي أنه قد طُلب منك ، وسُئل في المرة الثانية التي تم فيها الإعلان قبل شهور. بالنسبة لجميع صرخات الأشخاص الذين يقولون إن القرارات قد اتخذت دون استشارة أي شخص ، فقد صرحت Microsoft مرارًا وتكرارًا أنها لا تزال تعمل على وضع التفاصيل ، وأنهم لا يزالون ليس لديهم الأجزاء النهائية معًا والآن حان الوقت للتعبير عن رأيك . حتى أن سكوت هانتر قال إنه إذا أراد الأشخاص _ حقًا_ أن يكون project.json خيارًا ، فسوف يفكرون في الاحتفاظ به. اذهب لمشاهدة الكلمة الرئيسية dotnetconf إذا كنت لا تصدقني.

neoKushan ، أقدر أن سكوت تراجع قليلاً قائلاً إنهم

project.json كانت خطوة جيدة. لكنها كانت ساذجة في رأيي. لا يتطلب الأمر معرفة أن الناس قد يرغبون في الحصول على مشاريع هجينة مكتوبة بلغة C ++ أو F #. لم تكن بعض قرارات التصميم المبكرة الخاصة بهم مثل dnx واستخدام nuget كوحدة تجميع ممكنة بالنسبة للنظام البيئي dotnet ككل. ما تراه هو أنه في عملية تحقيق الانسجام مع dotnet ، يتعين عليهم اتخاذ هذه الخيارات الصعبة.

في رأيي ، لن يساعد التشرد وإعادة الاختراع في النظام البيئي للدوتنت ، بل سيؤذيه فقط. تعتبر Node and Go (خاصة Go) جذابة للغاية للمبتدئين لأن لديهم منصة / أدوات متجانسة ومتسقة.

أجد أن حجة XML مقابل JSON بأكملها سخيفة لأنه في غضون 5 سنوات أخرى ، ستكون JSON vs YAML وبعد ذلك YAML vs Groovy (على سبيل المثال gradle). XML ليست شريرة كما تصوّرها جميعًا. لقد بلغت MSBuild مرحلة النضج ولديها الكثير من الاستثمارات التي ستفيد الجميع.

قال ذلك، هناك الكثير من العمل يجب القيام به مع MSBuild للتأكد من أنك يمكن أن تحصل إما نفس أو في وسيلة أقل إيلاما جدا الأقل من استخدام وتحرير ملفات csproj. ثم انقل تبعيات nuget إلى ملف nuget.json. استفد من الاتفاقية عبر التكوين بحيث إذا كنت على "الطريق السعيد" ، فسيكون csproj فارغًا تقريبًا ، مثل web.config اليوم. ثم لديك خيارات cli التي تعدل csproj

بالنسبة لي ، سأفتقد project.json ولكن ليس للأسباب التي تعتقد أنها .. مشاريع C # ستكون على ما يرام. سأفتقده بسبب F # لقد فضلت تحرير project.json لترتيب الترجمة بدلاً من تحرير msbuild. مرة أخرى ليس لأن xml شرير ولكن لأن ملفات fsproj بها الكثير من bloat الذي تسببه msbuild

كانت مشكلتي مع هذا القرار هي الطريقة التي كان بها ملف csproj أقل حول xml / json وأكثر بكثير حول ما اختاروا تضمينه في ملف csproj. احتوت على تعريف المشروع ، احتوت على إعدادات IDE ، احتوت على خطوات البناء ، احتوت على مراجع ...

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

أنا أتفق مع هذا. في نهاية اليوم ، المشكلة الرئيسية في csproj هي ذلك
يفعل كل شيء.

أنا أحب الوسط الذي يقترحه باتريوت بوب ...

في الثلاثاء ، 21 حزيران (يونيو) 2016 ، الساعة 1:28 مساءً ، كتب PatriotBob [email protected] :

كانت مشكلتي مع هذا القرار هي الطريقة التي كان بها ملف csproj أقل
حول xml / json والمزيد حول ما اختاروا تضمينه في csproj
ملف. احتوت على تعريف المشروع ، واحتوت على إعدادات IDE ، عليه
يحتوي على خطوات بناء ، ويحتوي على مراجع ...

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

XML كله سيء ​​، JSON هو هرج كبير كان مبالغًا فيه بشكل كبير. يعجبني ما يقوله باتريوت بوبو.

إدارة مشروع as / w بالكامل من npm 's package.json لم تقدم أبدًا ببساطة وإيجازًا إعلان مشروعي ، وبناء مشروعي ، وترقية مشروعي (على سبيل المثال ، Greenkeeper) ، قراءة / كتابة / تحليل البيانات عن مشروعي ، ونشر مشروعي بهذه السهولة. _سهل جدا. كما هو الحال بالنسبة للكثيرين منا ، فإن تاريخي في c ++ / java / python / node ، مع اللعب في الآخرين. أتوق الآن للحصول على تجربة npm في جميع مشاريعي الآن.

وعد project.json بإعطاء نفس الخصائص. أعتقد أنه نموذج يستحق المحاكاة وعدم التضحية بالبساطة والقوة.

إذا كان الفريق الأساسي. net يعتقد أن الحل الآخر يمكن أن يوفر هذه السمات ، ممتازة ، وقوة لهم! ومع ذلك ، من فضلك لا تقوض الجمال في البساطة كلما تقدمت.

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات