هل يجب أن أحتفظ بالحلول والميزات بنسبة 1-1؟

Question

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

لقد قمت أيضًا بإجراء تغييرات على المخطط للقوائم الموجودة، وإضافة أعمدة جديدة من بيانات التعريف وتغيير الأعمدة الموجودة.

هل يجب أن أقوم بتجميع ميزة واحدة أو مستقبل حدث أو سير عمل في حل واحد، أم يجب أن أضع ميزات متعددة داخل الحل الواحد نظرًا لأنها تعمل جميعًا معًا؟

أحد الأسباب الرئيسية التي أطلبها هو ترقيات الكود المستقبلية.إذا تم فصل الميزات، فلن تتطلب الترقية في جزء واحد من التعليمات البرمجية إعادة نشر جميع الميزات الموجودة في الحل.هل هذا شيء يجب أن أقلق بشأنه أم أن "stsadmin -o Upgradesolution" يعتني بأي مشكلات تتعلق بترقية الحل الذي يحتوي على العديد من الميزات؟

اسمحوا لي أن أعرف إذا كان هذا منطقيًا لأي من خبراء SharePoint هناك.

شكرًا لك،
كيث

تحديث:أبحث في الموقع دراكس تمت الإشارة إليه، وجدت هذا الموقع المرجعي: http://msdn.microsoft.com/en-us/library/aa543659.aspx

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

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

• إزالة الميزات القديمة في إصدار جديد من الحل.

• إضافة ميزات جديدة في ترقية الحل.

• تحديث أو تغيير مجموعة المتلقي للميزات الموجودة في إصدار جديد من الحل.

• إضافة أو تغيير عناصر الميزات (ملفات element.xml) في إصدار جديد من الحل.

• إضافة أو تغيير خصائص الميزة في إصدار جديد من الحل.

• تغيير المعرف أو نطاق الميزات القديمة في إصدار جديد من الحل.

• إزالة عناصر الميزات (ملفات element.xml) في إصدار جديد من الحل.

• إزالة خصائص الميزة في إصدار جديد من الحل.

لذا...ماذا يمكنك أن تفعل بترقية الحل؟

Answer 1

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

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

تم التعديل:

لذلك قمت ببعض الأبحاث السريعة حول موضوع تحديث MOSS.وفقًا لـ MS هناك طريقتان لتحديث الحلول:

1. التحديث في المكان
2. تحديث تزايدي

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

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

لاحظ أيضًا أن التحديث التزايدي غير مدعوم رسميًا بواسطة MS.

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

ربما سأنتظر وأرى ما إذا كان بإمكان الأشخاص ذوي الخبرة الأكبر في MOSS أن يقولوا شيئًا عن هذا الموضوع.

Answer 2

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

Answer 3

يعد UpgradeSolution مفيدًا حقًا إذا كنت تقوم فقط بتحديث التجميع وترك الملفات المتوفرة سليمة.

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