العمل مع المكتبات العامة/المفيدة

Question

في الشركة التي أعمل بها لدينا مشروع "منفعة" يتم الرجوع إليه من خلال أي تطبيق نقوم بإنشائه تقريبًا.إنه يحتوي على الكثير من الأشياء مثل NullHelpers وConfigSettingHelpers وCommon ExtensionMethods وما إلى ذلك.

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

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

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

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

Answer 1

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

ثم يستخدم الأشخاص الإصدار المحدد من مكتبة.

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

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

لكن هذا لا يهم حقًا لأننا نقوم بزيادة الإصدار في كل عملية نشر.

أتمنى أن يساعدك هذا.

Answer 2

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

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

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

Answer 3

لقد كان بالضبط المشكلة نفسها!

اعتدت على استخدام مراجع المشروع، ولكن يبدو أن كل شيء يسير على ما يرام، كما قلت، لديك العديد من المشاريع التي تشير إليه.

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

أعتقد من الناحية النظرية أنه من المحتمل أن يكون GAC'ed، ولكن إذا كانت المشكلة تتغير كثيرًا (مثل مشكلتي) فقد يصبح هذا مشكلة..