هل يجب أن أتحول من nant إلى msbuild؟

Question

أستخدم حاليًا nant وccnet (نظام تثبيت السرعة) وsvn وmbunit.أستخدم msbuild للقيام ببناء sln الخاص بي فقط لأنه كان من الأسهل التخلص منه.

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

تحديث:هل هناك أي ميزات مقنعة من شأنها أن تجعلني أتحول من nant إلى msbuild؟

Answer 1

أنا أحب MSBuild.أحد الأسباب هو أن ملفات .csproj هي ملفات msbuild، والبناء في VS يشبه تمامًا البناء في سطر الأوامر.سبب آخر هو الدعم الجيد من TeamCity وهو خادم CI الذي أستخدمه.إذا بدأت في استخدام MSBuild، وتريد القيام بالمزيد من الأشياء المخصصة في عملية الإنشاء، فاحصل على مهام المجتمع MSBuild.يعطونك مجموعة من المهام الإضافية الرائعة.لم أستخدم NAnt منذ عدة سنوات، ولم أندم على ذلك.

أيضًا، كما ذكر روبن، هناك مهام SDC المهام على CodePlex.

لمزيد من المتعة، هناك حزمة ملحق MSBuild على CodePlex, ، والذي يتضمن مهمة تويتر.

Answer 2

نصيحتي هي عكس ذلك تمامًا - تجنب MSBuild مثل الطاعون.يعد NANT أسهل بكثير في إعداد الإصدار الخاص بك لإجراء الاختبار التلقائي، والنشر في بيئات إنتاج متعددة، والتكامل مع التحكم في السرعة لبيئة الإدخال، والتكامل مع التحكم في المصدر.لقد مررنا بالكثير من الألم مع TFS/MSBuild (باستخدام TFSDeployer، ونصوص powershell المخصصة، وما إلى ذلك) لجعله يفعل ما كنا قادرين على فعله باستخدام NANT خارج الصندوق.لا تضيع وقتك.

Answer 3

السبب الأكثر إلحاحًا لاستخدام MSBuild (على الأقل في .NET 3.5 وما بعده) - يمكن إنشاء محرك البناء بشكل متزامن.

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

قبل الإصدار 3.5، لم يكن MSBuild يقوم بإنشاء بنيات متوازية.

Answer 4

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

أنا شخصيا أستخدم MSBuild لأي مشروع جديد، ولكن قد يختلف عدد الكيلومترات الخاصة بك.

امل ان يساعد!

يحرر: @ChanChan - ذكر @Jon أن Nant لا ينشئ تطبيقات .NET 3.5.قد يكون هذا سببًا كافيًا لتغييرها أو على الأقل استخدامها بالتوازي.نظرًا لأنني انتقلت أكثر نحو MSBuild، فربما لا أكون الشخص الأكثر اطلاعًا لتسليط الضوء على أي عروض أخرى مع أي من التقنيتين.

يحرر: يبدو أن Nant يبني الآن تطبيقات .NET 3.5.

Answer 5

لقد كان NAnt موجودًا لفترة أطول، وهو منتج أكثر نضجًا إلى حد كبير، كما أن IMO أسهل في الاستخدام.هناك الكثير من المعرفة المجتمعية المتاحة للاستفادة منها، وهي أيضًا متعددة المنصات، إذا كنت مهتمًا ببناء تطبيقات يمكن تشغيلها ضمن Mono بالإضافة إلى .NET وSilverlight.خارج الصندوق، فهو يفعل أكثر بكثير مما يفعله MSBuild.أوه نعم، ويمكنك الاتصال بـ MSBuild من NAnt (حسنًا، من NAntContrib) :-)

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

المزايا الرئيسية التي أراها لـ MSBuild هي أنه يأتي مع .NET Framework، لذا فهو منتج أقل للتثبيت؛وهناك المزيد من التطوير النشط الجاري (وإن كان ذلك في أماكن للحاق بـ NAnt الأقدم).

أنا شخصياً أجد صعوبة في فهم بناء الجملة، ولكن بعد ذلك أنا متأكد من أن التعرض المستمر لـ ti سيجعل الأمور أسهل.

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

Answer 6

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

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

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

Answer 7

• لا تقم بالتبديل إلا إذا كان لديك سبب مقنع جدًا (على الأقل).
• NAnt مفتوح المصدر، وإذا لم يكن كذلك فلن أتمكن من تخصيص نظام البناء الخاص بنا، MSBuild ليس كذلك.
• يمكن لـ NAnt تشغيل MSBuild بسهولة، ولست متأكدًا من العكس.
• تمت كتابة البرامج النصية لـ MSBuild لك بالفعل إذا كنت تستخدم VS2005 أو أحدث (ملفات المشروع نكون ملفات MSBuild.)
• إذا كنت تستخدم NAnt، وتستخدم VS لتحرير ملفات المشروع والإعدادات والتكوينات، فسيتعين عليك كتابة أداة تحويل/مزامنة لتحديث ملفات NAnt من ملفات VS Project.

Answer 8

@ براد ليتش

بشكل عام، لن أقوم بالتبديل بينهما ما لم تكن هناك ميزة مقنعة مفقودة

ما هي الأسباب المقنعة لاستخدام msbuild؟هل هناك سلبيات؟

حتى الآن أحصل على نتيجة جيدة جدًا، "لا لا تهتم" من إجابتك.

Answer 9

أعتقد أنهما متشابهان نسبيًا من حيث الميزات وسهولة الاستخدام.فقط لأنني أعتمد على C#، أجد أن العمل مع msbuild أسهل من العمل مع nants، على الرغم من أن هذا ليس سببًا مقنعًا للتبديل.

ما الذي لا يفعله لك بالضبط؟أم أنك تأمل فقط أن تكون هناك بعض الميزات الرائعة التي قد تفوتك؟:)

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

أنا شخصياً أفضل SCs على كلاهما :)

Answer 10

السبب الرئيسي الذي يجعلني لا أزال أستخدم nAnt عبر msbuild في تصميماتي الآلية هو أنني أتمتع بقدر أكبر من التحكم الدقيق في تصميماتي.نظرًا لوجود ملف البناء الخاص بـ msbuild باستخدام csproj، يتم تجميع كل المصدر في هذا المشروع في تجميع واحد.مما يجعلني أملك الكثير من المشاريع في الحل الخاص بي للمشاريع الكبيرة حيث أفصل المنطق.حسنًا، مع nant، يمكنني ترتيب بنائي حيث يمكنني تجميع ما أريد في تجميعات متعددة من مشروع واحد.

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

ومع ذلك، فأنا أستخدم كلاً من nant وmsbuild معًا لبعض مهام البناء، مثل إنشاء تطبيقات WPF.من الأسهل كثيرًا تجميع تطبيق WPF باستخدام هدف msbuild داخل nant.

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

Answer 11

في الواقع، ما زلت أحاول اكتشاف هذا السؤال بنفسي، ولكن هناك مكافأة كبيرة لـ MSBuild هنا:استخدام نفس ملف البناء للتكامل المستمر المحلي عن طريق استدعاء msbuild.exe مباشرةً، مع القدرة أيضًا على استخدام التكامل المستمر من جانب الخادم VSTS مع نفس ملف البناء (وإن كانت خصائص/إعدادات مختلفة على الأرجح).

أي.بالمقارنة مع دعم TeamCity للبرامج النصية MSBuild، VSTS فقط يدعم البرامج النصية MSBuild!لقد قمت باختراق هذا في الماضي من خلال تنفيذ NAnt من MSBuild؛لقد رأيت آخرين يوصون بهذه الممارسة وكذلك العكس، لكنها تبدو سخيفة بالنسبة لي، لذلك أحاول عدم القيام بها إذا كان بإمكاني تجنبها.لذلك، عندما تستخدم "مكدس Microsoft الكامل" (VSTS وTFS)، أقترح عليك فقط الالتزام بالبرامج النصية لـ MSBuild.

Answer 12

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

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

المواد التعليمية:

• داخل محرك Microsoft Build:باستخدام MSBuild وTeam Foundation Build
  بقلم سيد إبراهيم الهاشمي (يناير 2009)
• نشر تطبيقات .NET:تعلم MSBuild و ClickOnce بواسطة سيد
  بواسطة Y.الهاشمي (سبتمبر 2008)

Answer 13

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

أنا معجب بـ NAnt في هذا الصدد، لأنه يفصلك عن إطار العمل قليلاً.

لقد قمت بإنشاء إطار عمل يضع الاتفاقيات في تصميمات آلية وقمت بإنشائه على NAnt.يطلق عليه اسم UppercuT وهو Build Framework سهل الاستخدام للغاية.

الإنشاءات الآلية سهلة مثل (1) اسم الحل، (2) مسار التحكم بالمصدر، (3) اسم الشركة لمعظم المشاريع!

http://code.google.com/p/uppercut/

بعض التفسيرات الجيدة هنا: UppercuT

Answer 14

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

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

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

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

Answer 15

لقد قمت بالتبديل من NANT إلى MSBuild.المشروع يعمل على .Net 4.0.

تجربتي في نانت كانت جيدة.نوع المشروع مات.وعندما جاء .Net 4.0، كان الوقت قد حان لإعادة تقييم عملية الإنشاء.

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

كان الكثير من العمل في نص نانت يتعلق بإعداد البيئات المختلفة.في MsBuild/.Net 4.0، فهو مدمج.

Answer 16

أنا أستخدم MSBuild جنبا إلى جنب Nant، لأن الإصدار الحالي من Nant لا يمكنه حتى الآن ترجمة تطبيقات .NET 3.5 (وكان الأمر نفسه صحيحًا عندما ظهر .NET 2.0 لأول مرة).

Answer 17

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

Answer 18

أنا أستخدم نانت وأحبه.لقد استخدمت MSBuild وكرهته بسبب ما يلي:

1. تجبرك شركة Microsoft على اتباع إجراءات البناء الخاصة بها والتي تعتبر جوهرية جدًا في أفعالها لدرجة أنني على الأقل لم أتمكن من إنجاحها (اضطررت إلى تجميع NET1.1 لذا اضطررت إلى مزج Nant وMSbuild).أعلم أنه يمكنك إنشاء ملف MSBuild الخاص بك، لكنني أعتقد أنه من الصعب فهمه وصيانته.

2. من الصعب جدًا متابعة أنواع ItemTypes للقيام بعمليات الملفات.يمكنك جعل Nant يفعل نفس الأشياء تمامًا وبشكل أسهل ومباشر (اضطررت إلى إنشاء قائمة ItemType ثم التمرير إلى عمليات الملف).

3. في MsBuild، يتعين عليك إنشاء ملف dll للمهام الخاصة بك، وفي Nant يمكنك القيام بذلك أو يمكنك تضمين كود C# داخل البرنامج النصي الخاص بك، لذلك يكون من الأسهل كثيرًا التقدم وبناء المشروع بأكمله.

4. يعمل Nant مع Net1.1، بينما لا يعمل MsBuild.

5. لتثبيت nant، يمكنني أيضًا فك الضغط وتحديد موقعه داخل المستودع الخاص بي لتشغيله.يعد تثبيت MsBuild أصعب بكثير لأنه يعتمد على أشياء كثيرة من Visual Studio وما إلى ذلك.(ربما أكون مخطئا هنا، ولكن يبدو أن هذه هي الحقيقة).

حسنا هذه هي آرائي ...