مزايا استخدام MSBuild أو NAnt مقابل تشغيل DevEnv.exe من سطر الأوامر

Question

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

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

أعلم أن إحدى ميزات استخدام MSBuild تسمح لك ببناء مشاريعك دون الحاجة إلى تثبيت Visual Studio على أجهزة البناء، لكنني لم أكن متأكدًا مما إذا كان هناك ميزات أخرى.

Answer 1

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

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

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

Answer 2

الجواب الواضح من فريقي هو ذلك لم يتم تثبيت استوديو مرئي على الإطلاق, ، وعلى وجه الخصوص، فإننا لا نقوم بتثبيت Visual Studio على خوادم البناء/CI الخاصة بنا.

Answer 3

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

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

Answer 4

بقدر ما يذهب C#، يقوم devenv.exe 2005 بتشغيل برنامج التحويل البرمجي in-proc، مما قد يتسبب في حدوث استثناءات في الذاكرة للحلول الكبيرة.يلجأ Msbuild إلى إطلاق عملية csc.exe لكل مشروع.المشاريع التي لا يتم تجميعها مع devenv /build تعمل بشكل جيد مع msbuild.آمل أن يعجبك هذا السبب.

Answer 5

نحن نجرب التبديل من DevEnv إلى أداة (Visual Build Pro) تستخدم MsBuild ضمن الغطاء وتلقينا خطأ "المرجع مطلوب للتجميع 'System.Drawing...'" لمشروع لا يحتاج إليه والذي يبني بشكل جيد في Visual Studio.

Answer 6

لدينا نظام كبير يتكون من C# وC++ المُدارة وتجميعات/ملفات dll القديمة غير المُدارة وغير المُدارة.يوجد كود C++ يعتمد على كود C++ المُدار الذي يعتمد على كود C# الذي يعتمد على كود C++ المُدار الذي يعتمد على كود C++ القديم البسيط (يا للعجب!).عندما كنا نقوم بإعداد بيئة البناء الآلية الخاصة بنا قبل بضع سنوات، اكتشفنا أن MSBuild.exe لا يتعامل بشكل صحيح مع كافة التبعيات الموجودة لدينا.

من خلال العمل مع Microsoft، تمكنا من حل بعض المشكلات ولكن ليس جميعها.إذا أسعفتني ذاكرتي، فلن نتمكن أبدًا من إنشاء تجميعات C# التي تعتمد على ملفات dll المُدارة لـ C++.لذلك انتهى بنا الأمر إلى إنشاء برنامج نصي مخصص للإنشاء يسمى devenv.exe من سطر الأوامر وقد عمل بشكل جيد.

بالطبع، كان ذلك مع VS2005، ربما تم إصلاحه الآن، لكن البرنامج النصي لا يزال يعمل، لذا لم نعد النظر في المشكلة.