هناك عمومًا طريقتان لتحديث التطبيق: إحداهما هي إخطار المستخدم (مثل إرسال بريد إلكتروني) ومطالبة المستخدم بتنزيل البرنامج المحدث من عنوان موقع ويب معين، والأخرى هي نقل مسؤولية التحديث من المستخدم إلى المستخدم بدلاً من حصول المستخدم على تحديث البرنامج وتثبيته، يكون تطبيق العميل نفسه مسؤولاً عن تنزيل التحديثات وتثبيتها من خادم معروف. والتدخل الوحيد الذي يتعين على المستخدم القيام به هو تحديد ما إذا كان يريد تثبيت التحديثات الجديدة الآن أم لا لاحقاً. من الواضح أن الأخير أكثر ودية من الأول. يمكنك الآن رؤية المنتجات الفعلية التي تشبه الأسلوب الأخير، مثل Windows XP وMicrosoft Money. يمكن أن يوفر مكون تحديث تطبيق .NET المقدم في هذه المقالة وظائف مشابهة.
1. مقدمة إلى مكون تحديث تطبيق .NET
تم تطوير مكون تحديث تطبيق .NET AppUpdater باستخدام إطار عمل .NET. على الرغم من أن AppUpdater ليس أحد منتجات Microsoft، طالما قمت بإضافة المكون إلى شريط أدوات VS.NET، فيمكنك سحب المكون وإسقاطه من شريط الأدوات إلى تطبيقك تمامًا مثل استخدام المكونات الأخرى بعد تعيين بعض الخصائص (مثل الموقع وتكرار الحصول على التحديثات، وما إلى ذلك)، يمكن أن يحتوي تطبيق العميل الخاص بك على وظيفة التحديث التلقائي.
2. مبدأ العمل
لفهم مبدأ عمل مكون تحديث تطبيق العميل .NET بعمق، تحتاج إلى دراسة ما يجب القيام به بعناية لتنفيذ تحديث تطبيق العميل. الخطوة الأولى هي التحقق من وجود تحديث؛ عند العثور على تحديث، ابدأ الخطوة الثانية - قم بتنزيل التحديث عند اكتمال تنزيل التحديث، وانتقل إلى الخطوة الأخيرة - قم بتنفيذ التحديث.
(1) التحقق من وجود تحديثات
، يجب عليك أولاً إخبار التطبيق بمكان التحقق من التحديثات. وإلا، ألن يكون الأمر مثل البحث عن إبرة في كومة قش؟ ثانيًا، حدد متى يجب التحقق من وجود تحديثات. من المستحيل على المستخدم تشغيل برنامج العميل في كل مرة، وهو يبحث باستمرار عن التحديثات في الخلفية. يا له من مضيعة للموارد! آخر شيء مهم يجب معالجته هو كيفية التحقق من وجود تحديثات. يستخدم مكون تحديث تطبيق .NET HTTP للاتصال، مما يسمح لتطبيقات العميل بإجراء التحديثات من خلال جدران الحماية. ويصبح العنوان المطلوب للتحقق من التحديث عنوان URL لخادم ويب معروف، ويتم حل المشكلة الأولى بنجاح.
يقوم مكون تحديث تطبيق .NET بإنشاء مؤشر ترابط بناءً على إنشاء المكون، وهو المسؤول عن التحقق من التحديث. ينام هذا الخيط معظم الوقت، لكنه ينشط على فترات زمنية محددة ويقوم بالتحقق من التحديث. يعتمد معدل تكرار قيام التطبيق بالتحقق من التحديثات الجديدة على التطبيق. تتراوح القيم المشتركة للفاصل الزمني بين عمليات التحقق من التحديث عادةً من ساعة واحدة إلى عدة أيام. هذا النهج الأساسي في الاقتراع ليس مناسبًا لكل المواقف. على سبيل المثال، يقوم Microsoft Money فقط بالتحقق من التحديثات عندما يطلبها المستخدم. في هذه الحالة، يمكن تعطيل مؤشر ترابط استقصاء التحديث.
يتم تنفيذ التحقق من التحديث عن طريق استدعاء الأسلوب CheckForUpdate() الخاص بمكون التحديث باستخدام أمر.
هناك عدة طرق حول كيفية إجراء عمليات التحقق من التحديث:
الطريقة الأولى: التحقق المباشر من الملف - استخدم HTTP لمقارنة طابع تاريخ/وقت التعديل الأخير لتطبيقات الخادم والعميل لمعرفة ما إذا كانت متسقة. إذا كان هناك ملف محدث على الخادم، يعرف العميل أنه يمكنه تحديث نفسه. وينطبق الشيء نفسه على متصفح الويب، الذي يعرف ما إذا كان يحتاج إلى إعادة تنزيل صفحة أو صورة بتنسيق html أو ما إذا كان يمكنه إعادة استخدام صفحة أو صورة تم تنزيلها مسبقًا. عندما يتوفر إصدار جديد من التطبيق، يقوم المسؤول ببساطة بنسخ الإصدار الأحدث فوق الإصدار الأقدم على خادم الويب. المشكلة في هذا الأسلوب هي أن التحديث ليس تلقائيًا، لذلك هناك احتمال الفشل. على سبيل المثال، إذا كان المسؤول يقوم بتحديث إصدار تطبيق ما على خادم ويب، وقام العميل بتنزيل إصدار قبل التحديث، فسيحتوي جهاز الكمبيوتر الخاص بالعميل على بعض الملفات من قبل التحديث، بالإضافة إلى بعض الملفات من الإصدار الجديد الإصدار بعد وثيقة التحديث. للأسباب المذكورة أعلاه، لا يُنصح بالتحقق المباشر من الملفات بحثًا عن التحديثات للتطبيقات المهمة.
الطريقة الثانية: فحص صريح - استخدم ملف تكوين صريح على الخادم. يبدو الملف الصريح للخادم الصالح للاستخدام مع مكونات تحديث تطبيق .NET كما يلي: ..
<VersionConfig>
＜الإصدار المتاح＞1.0.0.0＜/الإصدار المتاح＞
＜ApplicationUrl＞ http://localhost/demos/selfupdate/V1/ ＜/
عنوان التطبيق＞
</VersionConfig>
يحددavailableVersion رقم الإصدار لأحدث تجميع متاح. تحدد سمة ApplicationURL عنوان URL الذي يوجد به هذا الإصدار من التطبيق. عندما يريد المسؤولون تحديث تطبيق عميل، يقومون بنسخ الإصدار الجديد من التطبيق إلى خادم الويب وتعديل ملفات الخادم الصريحة بشكل مناسب. سيكتشف العميل نفسه أن الملف الصريح الخاص بالخادم قد تم تعديله، ثم يقوم بتنزيل الملف الصريح. يقوم العميل بعد ذلك بمقارنة رقم إصدار التجميع المحدد في الملف الصريح برقم إصدار ملف EXE الخاص بالتطبيق. إذا كان رقم الإصدار الأحدث متاحًا في الملف الصريح للخادم، فسيعلم التطبيق أنه بحاجة إلى التحديث. يوصى بهذه الطريقة لمعظم التطبيقات.
الطريقة الثالثة: فحص خدمة ويب XML - توفر XML WebServices طريقة أكثر تقدمًا للتحقق من التحديث. على سبيل المثال، لنفترض أنك تريد تحديث مجموعة من المستخدمين الأوائل قبل تحديث المستخدمين الآخرين. إذا قام تطبيق العميل باستدعاء خدمة ويب XML للتحقق من توفر تحديث، فيمكن لخدمة ويب XML أيضًا الاستعلام عن قاعدة البيانات الخاصة بهذا المستخدم وتحديد ما إذا كان المستخدم مستخدمًا مبكرًا. إذا كانوا من أوائل المستخدمين، تقوم خدمة ويب XML بإرجاع قيمة تشير إلى توفر التحديثات. إذا لم يكن الأمر كذلك، تقوم خدمة الويب بإرجاع قيمة تشير إلى عدم توفر التحديث. ومع ذلك، لا يوفر مكون تحديث تطبيق .NET المقدم في هذه المقالة دعمًا مباشرًا لخدمة ويب XML.
لاستخدام خدمة ويب XML لإجراء عمليات التحقق من التحديث، قم أولاً بإنشاء خدمة ويب XML وربط حدث OnCheckForUpdate. يتيح لك هذا كتابة عمليات التحقق المخصصة الخاصة بك بدلاً من عمليات التحقق من تحديث مؤشر ترابط أداة الاستقصاء. يحتوي الحدث OnCheckForUpdate على قيمة إرجاع تشير إلى ما إذا كان قد تم اكتشاف تحديث أم لا.
(2) تنزيل التحديثات
عندما يكتشف مكون تحديث تطبيق .NET توفر تحديث جديد، فإنه سيبدأ تلقائيًا سلسلة رسائل أخرى ويبدأ تنزيل التحديثات غير المتزامن في الخلفية.
يتم التنزيل باستخدام HTTP-DAV. DAV هو إصدار موسع من HTTP، والذي يوفر وظائف مثل تعداد الدليل والملف. تبدأ عملية التنزيل الكاملة بتحديد عنوان URL. يعتمد عنوان URL المستخدم للتنزيل على الطريقة المستخدمة لإكمال التحقق من التحديث. على سبيل المثال، إذا كنت تستخدم ملفات صريحة للخادم، فسيتم تحديد عنوان URL المستخدم لتنزيل التحديثات من خلال سمة ApplicationURL في الملف الصريح للخادم.
من الواضح أن تنزيل التحديث يتطلب بعض القوة. من غير المقبول ترك تطبيق العميل في أي حالة غير مستقرة بعد التنزيل والتحديث. قد يحدث أي عدد من المشكلات أثناء عملية التنزيل: قد يكون خادم الويب الذي ينتمي إليه ملف التحديث معطلاً، أو قد يتعطل جهاز العميل، أو قد يقوم المستخدم ببساطة بإغلاق التطبيق لسبب ما. نظرًا لأنه يتم تنزيل التطبيق، إذا تم إغلاقه، فسيتوقف التنزيل. يتمثل أحد حلول التصميم البديلة في استخدام خدمات نظام منفصلة لتنزيلات التطبيقات وتحديثاتها. باستخدام خدمات النظام، تستمر تنزيلات التحديث حتى عندما لا يكون التطبيق نفسه قيد التشغيل. في الواقع، يحتوي نظام التشغيل Windows XP على خدمة تنزيل مضمنة تسمى BITS، والتي تخدم هذا الغرض. يتم استخدام BITS بواسطة Windows XP لتنزيل Windows نفسه وتحديثه. لمزيد من المعلومات حول BITS، راجع http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp . لا يتم استخدام هذه الخدمة في مكون تحديث تطبيق .NET، لذا يمكن استخدامها في نظام التشغيل Windows 9x الذي لا يدعم خدمات النظام.
(3) تنفيذ التحديثات
يكتسب مكون تحديث تطبيق .NET القوة عن طريق تقسيم عمليات التنزيل والتحديث إلى مرحلتين منفصلتين. عند اكتمال كل مرحلة، يتم تسجيلها في ملف بيان محدث موجود في دليل تطبيق العميل. إذا تمت مقاطعة عملية التنزيل أو التحديث في أي مرحلة، فسيتم استئناف العمل الأصلي من آخر نقطة توقف مكتملة في المرة التالية التي يبدأ فيها التطبيق. يمكن إعادة تشغيل كل مرحلة، لذلك إذا حدث فشل في منتصف المرحلة، فستنجح إعادة تشغيل المرحلة. في حالة حدوث خطأ، مثل فقدان الاتصال بالخادم أثناء التنزيل، فسيحاول مكون تحديث .NET مرة أخرى لاحقًا. إذا تم الإبلاغ عن عدد كبير جدًا من الأخطاء (على سبيل المثال، عدم عودة خادم الويب للاتصال بالإنترنت مطلقًا)، فسيتم إلغاء التنزيلات والتحديثات والإبلاغ عن الأخطاء.
نهجنا الأول هو ببساطة بدء عملية منفصلة لتنفيذ التحديث. ستقوم هذه العملية المنفصلة أولاً بإيقاف عملية التطبيق، وتنفيذ التحديث (نظرًا لأنه تم إلغاء قفله الآن)، وإعادة تشغيل عملية التطبيق، ثم إيقاف تشغيل نفسها عند الانتهاء. ولذلك، هناك ثلاث مشاكل أساسية في هذا التصميم:
في بعض الحالات لا يعمل. عندما يتم تحديث أحد التطبيقات، تغلق عملية التحديث عملية التطبيق الأصلية، كما يتم إغلاق عملية التحديث نفسها أيضًا، لذلك لن يتم تنفيذ التحديث.
نريد أن نكون قادرين على تحديث كافة التعليمات البرمجية التي تحتاج إلى تحديث تلقائيًا. نريد القدرة على تثبيت التصحيحات تلقائيًا ليس فقط على التطبيق، ولكن أيضًا على مكون تحديث تطبيق .NET نفسه. باستخدام هذا الوضع، لا يمكننا تحديث العملية التي تنفذ التحديث.
من غير اللائق إجبار المستخدم على إغلاق التطبيق والانتظار أثناء استخدامه.
الطريقة الأخيرة المستخدمة لتنفيذ تحديثات التطبيق هي استخدام نمط التجميع المتوازي لـ .NET Framework. كبديل لمحاولة تحديث التطبيق نفسه، قم بإنشاء إصدار أحدث من التطبيق من الإصدار الموجود حاليًا.
يمكن إنشاء إصدارات جديدة عن طريق دمج كتالوج التطبيق الموجود حاليًا مع الإصدارات المحدثة التي تم تنزيلها. عند اكتمال الإصدار الجديد، سيستخدم المستخدم الإصدار الجديد تلقائيًا في المرة التالية التي يعيد فيها فتح التطبيق. يمكن بعد ذلك إزالة نسخة الطلب الأصلي. الشيء الصعب هو معرفة الإصدار الذي يجب تحميله في لحظة معينة. نقدم تطبيقًا اسمه Appstart. Appstart هو نقطة الدخول إلى التطبيق الخاص بك. باستخدام هذا الوضع، يبدو دليل التطبيق الخاص بك كما يلي: ..
--> ملفات البرنامج
--> MyApp
--> Appstart.exe
--> Appstart.config
- -> V1 Folder
-- > MyApp.exe
--> مجلد V1.1
--> MyApp.exe
لتشغيل التطبيق الخاص بك، عادةً ما تقوم بتشغيل Appstart.exe. إذا كنت تريد الحصول على مفتاح اختصار على سطح المكتب، فيجب أن يشير مفتاح الاختصار هذا إلى Appstart وليس مباشرة إلى التطبيق (لاحظ أنه يمكنك إعادة تسمية AppStart.exe إلى أي شيء تريده، مثل YourApp.exe). برنامج بسيط للغاية يقرأ ملف Appstart.config ويقوم بتحميل التطبيق المحدد. يبدو ملف Appstart.config الصالح بهذا الشكل:
<Config>
＜اسم مجلد التطبيق＞مجلد V1＜/اسم مجلد التطبيق＞
＜AppExeName＞MyApp.exe＜/AppExeName＞
＜وضع تشغيل التطبيق＞نطاق التطبيق＜/وضع تشغيل التطبيق＞
＜/التكوين＞
يحدد AppFolderName المجلد الفرعي الذي يحتوي على إصدار التطبيق الذي يتم تشغيله حاليًا. يحتوي AppExeName على اسم ملف exe المراد تحميله في هذا المجلد. عند اكتمال تحديث التطبيق، فإن الخطوة الأخيرة هي تعديل قيمة AppFolderName للإشارة إلى الإصدار الجديد من التطبيق. بهذه الطريقة، في المرة التالية التي يقوم فيها المستخدم بتشغيل التطبيق، سيتم تشغيل الإصدار الجديد المحدث من التطبيق. يحدد AppLaunchMode كيفية تحميل التطبيق. هناك طريقتان لتحميل التطبيقات: الطريقة الأولى هي استخدام AppDomains. تعد AppDomains إحدى ميزات وقت تشغيل اللغة العامة لـ .NET Framework وهي أيضًا وحدة منطقية مستقلة وكائن إدارة. يسمح وقت تشغيل اللغة العامة بمجالات تطبيق متعددة لكل عملية. بهذه الطريقة يمكن لـ Appstart.exe تحميل التطبيق الخاص بك في AppDomain منفصل ولكن في نفس عملية AppStart.exe. على الرغم من وجود برنامجين مختلفين قيد التشغيل (أي Appstart.exe وMyApp.exe)، إلا أنه يتم استخدام عملية واحدة فقط. ستعمل AppDomains بشكل جيد مع معظم التطبيقات، على الرغم من وجود بعض الاختلافات الدقيقة بين التشغيل في AppDomain منفصل والتشغيل في عملية منفصلة. في هذه الحالة، يمكن ضبط AppLaunchMode على "معالجة"، مما سيؤدي إلى تحميل التطبيق في عملية منفصلة.
بمجرد قيام Appstart بتشغيل التطبيق، فإنه ينتقل إلى وضع السكون في انتظار إنهاء التطبيق. بمجرد إنهاء التطبيق، يتم إغلاق Appstart أيضًا.
3. مثال للإرشادات التفصيلية
لقد ناقشنا سابقًا كيفية عمل تحديث تطبيق .NET، والآن دعونا نطبقه على مثال.
الخطوة 1: إنشاء تطبيق للتحديث
1. استخدم VS.NET لإنشاء مشروع تطبيق Windows جديد، يسمى "SampleApp".
2. قم بإعطاء النموذج لون خلفية مثير للاهتمام من اختيارك. سوف نستخدم لون الخلفية لتمييزه عن الإصدارات المحدثة لاحقًا.
3. الآن دعونا نضيف ميزة خفية لهذا التطبيق أولا، أضف زرا إلى النموذج الخاص بك. يحتوي الملف المضغوط على مجموعة تحتوي على نموذج Windows بسيط. أضف مرجعًا إلى مجموعة SamplesSampleAppSimpleForm في الملف المضغوط. ثم أضف سطرين من التعليمات البرمجية إلى معالج حدث الزر الخاص بك:
..
SimpleForm.Form1 F = new SimpleForm.Form1();
F.Show();
4. قم بتحويل علامة البناء الخاصة بك من التصحيح إلى الإصدار. سيسمح لنا هذا بتجنب مشكلات قفل ملف pdb لاحقًا عندما نقوم بإنشاء إصدار جديد من التطبيق أثناء تشغيل النسخة الأصلية. بناء واختبار التطبيق الخاص بك.
الخطوة 2: إضافة مكون تحديث تطبيق .NET
1. في علامة التبويب "المكونات" بشريط أدوات VS.NET، انقر بزر الماوس الأيمن وحدد "تخصيص شريط الأدوات". حدد علامة التبويب ".NET Framework Components". انقر فوق "استعراض" وحدد AppUpdater.dll الموجود ضمن مشروع AppUpdater في الملف المضغوط، وانقر فوق "موافق".
2. من المفترض أن يظهر الآن رمز AppUpdater أسفل قائمة مكونات شريط الأدوات. قم بسحب وإسقاط مكون AppUpdater في نموذج SampleApp. يظهر مثيل لمكون تحديث تطبيق .NET المسمى appUpdater1 في أسفل النموذج.
الخطوة 3: إعداد مكون تحديث تطبيق .NET
في هذه الخطوة، سنقوم بإعداد مكون تحديث تطبيق .NET. لاحظ أنه في هذا المثال تحتاج فقط إلى تغيير الخصائص الأربع الأولى، مع ترك الباقي في قيمها الافتراضية.
سمة AppUpdater: هذا هو جوهر تحديث تطبيق تطبيق NET. يجب إجراء الإعدادات التالية لهذا البرنامج:
(1) AutoFileLoad: يتحكم هذا في خصائص تنزيل الأمر التي سيتم وصفها لاحقًا.
(2) ChangeDetectionMode: يحدد هذا التعداد كيفية التحقق من وجود تحديثات. في هذا المثال، سنستخدم فحصًا صريحًا للخادم، لذا قم بتعيين هذه القيمة على "ServerManifestCheck".
(3) ShowDefaultUI: يحتوي مكون تحديث تطبيق .NET على سلسلة من واجهات المستخدم لإعلام المستخدمين ببعض الأحداث، مثل توفر تحديث جديد أو حدوث خطأ أثناء التحديث. يمكن تعطيل واجهة المستخدم هذه عن طريق تعيين واجهة المستخدم الافتراضية على أنها غير صالحة واستبدالها بواجهة مستخدم مخصصة خاصة بالتطبيق، مع ربط الأحداث المناسبة (على سبيل المثال،
OnUpdateComplete) وافتح واجهة المستخدم المخصصة. في هذا المثال، سنستخدم واجهة المستخدم الافتراضية، لذا قم بتعيين هذه القيمة على true.
(4) UpdateUrl: يحدد UpdateUrl المكان الذي سيبحث فيه برنامج التحديث عن التحديثات. في هذا المثال، نستخدم ملفًا صريحًا للخادم للتحقق من التحديثات، لذلك يجب تعيين هذه الخاصية على عنوان URL للملف الصريح للخادم.
في هذا المثال، قم بتعيينه على: http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml . الرجاء استبدال "yourWebserver" باسم خادم الويب الخاص بك.
خاصية أداة التنزيل: يحتوي مكون AppUpdater على مكونين فرعيين. الأول يسمى Downloader، الذي يتحكم في خصائص التنزيل وPoller للمكون: المكون الفرعي الثاني لـ AppUpdater هو Poller، الذي يتحكم في التحقق من التحديث.
(1) التشغيل التلقائي: قيمة منطقية تتحكم في ما إذا كان يجب على المُستقصي بدء الاستقصاء عند بدء تشغيل التطبيق أو ما إذا كان يجب الانتظار حتى يبدأ استعلام التحديث المخطط له.
(2) DownloadOnDetection: قيمة منطقية، تتحكم في ما إذا كان Poller سيبدأ في تنزيل التحديثات فورًا عند اكتشاف تحديث جديد، أو ما إذا كان سيتم بدء التنزيل الصريح عن طريق استدعاء الأسلوب DownloadUdpate().
(3)InitialPollInterval: عدد الثواني التي يجب الانتظار قبل إجراء فحص التحديث الأول بعد بدء تشغيل التطبيق.
(4)PollInterval: بعد التحقق من التحديث الأول، يتحكم PollInterval في عدد الثواني بين كل فحص تحديث لاحق. ملاحظة: الإعداد الافتراضي هو التحقق كل 30 ثانية؛ ومن الواضح أنك تريد أن يقوم تطبيقك بتقليل عدد عمليات التحقق من التحديث .
بعد الانتهاء من كل هذا، يجب أن يبدو جدول الخصائص الخاص بك كما يلي:
يحتوي الدليل SamplesSampleAppSampleApp_Complete على إصدار التطبيق المثبت بشكل صحيح.
التثبيت:
(1) DownloadRetryAttempts: إذا حدث خطأ أثناء التنزيل (مثل تعطل خادم الويب)، فسيحاول برنامج التنزيل مرة أخرى لاحقًا. تتحكم هذه الخاصية في عدد المرات التي يقوم فيها برنامج التنزيل بإعادة محاولة طلب الشبكة قبل اعتباره خطأً كاملاً في تحديث التطبيق.
(2)SecondsBeteweenDownloadRety: عدد الثواني التي يجب الانتظار قبل إعادة محاولة طلب الشبكة.
(3)UpdateRetryAttempts: في حالة حدوث خطأ خطير أثناء التحديث (على سبيل المثال، تجاوز برنامج التنزيل عدد مرات إعادة المحاولة)، فسيتم إنشاء خطأ في تحديث التطبيق. افتراضيًا، سيتم إيقاف محاولات التحديث. ولكنه سيحاول الاسترداد في المرة التالية التي يبدأ فيها تشغيل التطبيق (على سبيل المثال، قد يكون تحديث خادم الويب معطلاً لعدة أيام). تتحكم هذه الخاصية في عدد مرات محاولة التحديث. إذا تم تجاوز هذه القيمة، يلغي المُحدِّث التحديث، ويعيد تعيين حالته ويعود للتحقق من التحديث.
(4) التحقق من صحة التجميعات: تتحكم هذه السمة في المستوى الذي يتم عنده إكمال التجميعات التي تم تنزيلها بشكل فعال. راجع قسم الأمان في هذه المقالة لمزيد من المعلومات.
الخطوة 4: إنشاء ونشر الإصدار V1 من التطبيق على العميل.
في مشروع SampleApp، افتح الملف AssemblyInfo.cs. قم بتعديل قيمة AssemblyVersion من "1.0" إلى "1.0.0.0". يؤدي هذا إلى الحصول على علامة بالقيمة "1.0.0.0" عند إنشاء التجميع.. بدلاً من القيمة التي يحددها VS.NET عادةً كزيادة.
1. قم ببناء التطبيق.
2. انسخ دليل SamplesSampleAppSampleApp_ClientSetup من الملف المضغوط إلى جهازك المحلي. لاحظ أن هذا الدليل يحتوي بالفعل على AppStart.exe. تم تعيين AppStart.config للإشارة إلى الدليل 1.0.0.0 وبدء تشغيل SampleApp.exe.
انسخ SampleApp (Appupdater.dll وSimpleForm.dll وSampleApp.exe) من دليل إصدار SampleApp
إلى دليل العميل SampleApp_ClientSetup1.0.0.0. في هذه المرحلة، تم "تثبيت" إصدار كامل الوظائف من التطبيق على العميل ويمكن تنفيذه عن طريق تشغيل AppStart.exe.
الخطوة 5: تثبيت خادم الويب
في هذه الخطوة، سنقوم بتثبيت خادم الويب لتوفير وظيفة استقصاء التحديث. يستخدم مكون تحديث تطبيق .NET HTTP-DAV لتنزيل تحديثات التطبيق وبالتالي يتطلب خادم ويب يدعم HTTP-DAV. يدعم IIS5.0 في نظام التشغيل Windows 2000 وأنظمة التشغيل الأحدث HTTP-DAV.
1. انسخ دليل Samples/SampleApp_ServerSetup إلى دليل wwwroot على خادم الويب الخاص بك.
2. انسخ الإصدار V1 من SampleApp إلى المجلد 1.0.0.0 الخاص بخادم الويب.
3. قم بتمكين إذن "استعراض الدليل" الخاص بـ IIS لدليل SampleApp_ServerSetup على خادم الويب.
الخطوة السادسة: تحديث التطبيقات تلقائيًا
حسنًا،... الآن حان الوقت لرؤية نتائج كل هذا العمل الشاق عن طريق تثبيت إصدار جديد تلقائيًا.
1. إذا كان إصدار SampleApp الذي قمت بنشره على العميل لا يعمل، فقم بتحميله واتركه يعمل، وتذكر استخدام AppStart.exe.
2. ارجع إلى VS.NET وقم بإجراء بعض التغييرات الملحوظة في نموذج SampleApp (مثل تغيير لون الخلفية).
3. قم بتغيير معلومات إصدار AssemblyInfo.cs إلى 2.0.0.0.
4. تجديد.
5. ارجع إلى خادم الويب وقم بإنشاء دليل 2.0.0.0 يعادل الدليل 1.0.0.0. انسخ الإصدار الجديد من التطبيق من دليل إنشاء الإصدار إلى الدليل 2.0.0.0 المنشأ حديثًا على خادم الويب.
6. افتح UpdateVersion.xml وقم بتعديل AvailableVersion إلى 2.0.0.0. قم بتعديل ApplicationURL للإشارة إلى المسار 2.0.0.0 الجديد.
7. احفظ التغييرات التي تم إجراؤها على UpdateVersion.xml.
بمجرد حفظ ملف UpdateVersion.xml الجديد، خلال 30 ثانية، سيؤدي تشغيل نسخ SampleApp إلى اكتشاف الإصدار الجديد المتوفر.
4. التثبيت حسب الطلب والأمان وقابلية التوسع وتصحيح الأخطاء
(1) التثبيت عند الطلب
يعني ما يسمى بالتثبيت عند الطلب أنه يتم تثبيت البرنامج الرئيسي القابل للتنفيذ فقط بشكل صريح على جهاز الكمبيوتر العميل. يمكن تنزيل باقي التطبيق وتثبيته تلقائيًا بناءً على الاحتياجات الأساسية.
بدء التثبيت عند الطلب من خلال خاصية AutoFileLoad لمكون تحديث تطبيق .NET. يجب أن تفكر بعناية في مكان وجود حدود التجميع داخل تطبيقك وما هي الإجراءات التي ستؤدي إلى تنزيل التجميع. نظرًا لأن تنزيل التجميع يتضمن إدخالاً وإخراجًا عبر الشبكة، فإن الوقت المستغرق للتنزيل متغير. أثناء تنزيل التجميع، يتم تجميد التطبيق في انتظار اكتمال تنزيل التجميع.
(2) النشر
إن القدرة على تثبيت تحديثات التطبيق تلقائيًا بشكل آمن لها فوائد عديدة، ولكنها تأتي أيضًا مع بعض المخاطر المحتملة. عندما تسهل تثبيت التحديثات، يمكنك أيضًا تسهيل تثبيت التعليمات البرمجية الضارة إذا لم تكن حذرًا. هناك خطران: الخطر الأول هو أن يستخدم شخص ما خادم الويب الخاص به لخداع خادم الويب المستخدم لنشر التحديثات. وقد يستخدمون خادم الويب هذا لتثبيت فيروس في مسار التطبيق الخاص بك. إن أبسط طريقة لمنع الانتحال أو أي تدخل غير لائق عبر الشبكة هو استخدام HTTPS. لاستخدام HTTPS مع مكون تحديث تطبيق .NET، ما عليك سوى استبدال عناوين URL HTTP بعناوين URL HTTPS. بالطبع، HTTPS ليس حلاً سحريًا. هناك مشكلتان في استخدام HTTPS، الأولى هي قابلية التوسع. يتطلب استخدام HTTPS أن يقوم الخادم بتشفير جميع الملفات التي تم تنزيلها من خادم الويب. إذا كانت ملفات تحديث التطبيق كبيرة، فقد تؤدي تكلفة تشفير ملفات التحديث إلى زيادة العبء على الخادم. هناك مشكلة أخرى في استخدام HTTPS وهي أنه لا يفعل شيئًا لصالح الخطر الأمني الثاني. الخطر الثاني هو أن المتسللين يمكنهم مهاجمة خادمك من الداخل وكذلك من الخارج. إذا نجح الهجوم، فقد يعني ذلك أن مئات أو آلاف العملاء يتأثرون أيضًا بالتحديثات التلقائية، الأمر الذي قد يكون كارثيًا.
لحل هذه المشكلة، يستخدم مكون تحديث تطبيق .NET ميزة الاسم الواضح لتجميعات .NET للتحقق من التجميعات التي تم تنزيلها. إذا اكتشف مكون تحديث تطبيق .NET أن التجميع لم يتم توقيعه باستخدام المفتاح الخاص بك أثناء التنزيل، فسيتم إلغاء التنزيل. وهذا يعني أن الشخص الذي لديه المفتاح الخاص لتطبيقك هو فقط من يمكنه إنشاء تحديثات يمكن نشرها تلقائيًا.
للتحقق من صحة التجميع، يتحقق مكون تحديث تطبيق .NET من تطابق المفتاح العام للتطبيق المثبت حاليًا القابل للتنفيذ والمفتاح العام للتحديث الذي تم تنزيله. إذا تم توقيع مجموعتين بنفس المفتاح الخاص السري، فسيكون المفتاح العام المضمن هو نفسه. نظرًا لأن التجميع الذي يتم تحميله بواسطة CLR يتحقق من مفتاحه العام، فإن CLR يحسب فحص التجزئة العادي الخاص به للتأكد من أن التجميع هو في الواقع تجميع حقيقي وليس تجميعًا تم العبث به. لتمكين التحقق من الصحة في وقت التنزيل، قم بإضافة أسماء قوية إلى كافة تجميعات التطبيق لديك وقم بتعيين خاصية ValidateAssemblies الخاصة بمكون تحديث تطبيق .NET إلى true.
يساعد التحقق من التجميع أثناء التنزيل كثيرًا، ولكن من الناحية العملية، غالبًا ما تحتوي التطبيقات على مكونات موقعة بمفاتيح خاصة مختلفة. على سبيل المثال، قد يحتوي تطبيقك على ملفين: تجميع قابل للتنفيذ موقّع بمفتاحك الخاص، وتجميع dll آخر يحتوي على عنصر تحكم مخطط تابع لجهة خارجية قمت بشرائه واستخدامه في تطبيقك. قد يتم توقيع تجميعات الجهات الخارجية باستخدام المفتاح الخاص للجهة الخارجية بدلاً من المفتاح الخاص بك. ولزيادة تعقيد الموقف، قد يتغير إعداد المفاتيح الخاصة الصالحة المستخدمة لتوقيع التجميعات في التطبيق الخاص بك من رقم الإصدار إلى رقم الإصدار. كيف تقوم بتحديث أنواع التطبيقات هذه تلقائيًا؟ لحل هذه المشكلة، يمكنك إنشاء تجميع في التطبيق الخاص بك يحتوي على قائمة بالمفاتيح العامة الصالحة. قم بتوقيع التجميع باستخدام المفتاح الخاص الرئيسي للتطبيق (المفتاح المستخدم لتوقيع ملف exe الخاص بالتطبيق) ثم ضع التجميع في دليل على خادم الويب مع ملفات تحديث التطبيق. قبل بدء عملية تنزيل التحديث، سيقوم مكون تحديث تطبيق .NET بالتحقق من وجود مجموعة تسمى "AppUpdaterKeys.dll" في دليل تحديث التطبيق على خادم الويب. إذا كان موجودًا، فسيتم تنزيل التجميع. يتم التحقق من التجميع مقابل المفتاح العام للتطبيق الرئيسي. إذا كان التوقيع صالحًا، فسيتم استخراج قائمة المفاتيح. من الآن فصاعدًا، سيتم اعتبار أي مفتاح في هذه القائمة بمثابة توقيع صالح للملف المحدث.
أسلوب الأمان الموصى به هو استخدام عناوين URL HTTPS للتحقق من التحديثات. وهذا يوفر المستوى الأول من الحماية من الانتحال. لتنزيلات التحديث، من الأفضل عدم استخدام HTTPS RLs لتجنب التحميل الزائد على خادم الويب الخاص بك. بدلاً من ذلك، أضف أسماء قوية إلى تجميعات التطبيق الخاص بك واستخدم ميزة التحقق من صحة التجميع.
(3) قابلية التوسع
في المثال المذكور سابقًا في هذه المقالة، قمنا ببساطة بسحب وإسقاط مكون في التطبيق وتعيين بعض الخصائص لتحقيق النشر التلقائي.
في حين أن هذا يعمل بشكل جيد في العديد من التطبيقات، إلا أن بعض التطبيقات تتطلب مستوى عاليًا من التحكم لا يمكن الحصول عليه إلا عن طريق كتابة التعليمات البرمجية. يمكننا كتابة التعليمات البرمجية الخاصة بنا لتحل محل العملية القياسية لمكون تحديث تطبيق .NET، باستخدام أساليب CheckForUpdate() وApplyUpdate() التي تم تجاوزها لتخصيص سلوك التحقق والتحديث.
(4) تصحيح الأخطاء
سيشير هذا القسم إلى بعض خيارات التصحيح المفضلة، بالإضافة إلى وصف المشكلات الأكثر شيوعًا التي يواجهها مستخدمو هذا المكون.
يقوم برنامج .NET Application Updater بإنشاء ملف سجل مخفي يسمى AppUpdate.log في نفس الدليل مثل AppStart.exe.
يتم تسجيل جميع معلومات نجاح وفشل التحديث في هذا السجل. يكون ملف السجل مفيدًا بشكل خاص عندما يفشل عميل معين في التحديث بنجاح.
يمكنك استخدام السجلات لتحديد متى وكيف فشلت التحديثات. بالإضافة إلى ذلك، يستخدم مكون .NET Application Update فئة Debug الخاصة بـ .NET Framework لإخراج مجموعة كبيرة من المعلومات المفيدة. إذا قمت بتشغيل التطبيق الخاص بك في مصحح الأخطاء، فسترى هذه المعلومات في نافذة الإخراج. يمكنك متابعة سجلات .NET Application Updater لتسليط الضوء على مناطق المشكلة والعثور عليها.
إذا لم تتمكن لسبب ما من تشغيل أداة تحديث تطبيق .NET، فيرجى التأكد مما يلي قبل التعمق في تصحيح الأخطاء. المشكلة التي تواجهها هي على الأرجح واحدة مما يلي: ..
هل قمت بالاستعراض إلى IIS فتح الدليل؟ إذا لم يكن الأمر كذلك، فلن يقوم المحدث بتنزيل أي ملفات وتثبيتها.
هل قمت بنشر كل شيء بشكل صحيح وقمت بتعيين عنوان URL بشكل صحيح؟
إذا تم تثبيت التطبيق الخاص بك في دليل ملفات البرنامج، فهل أنت متأكد من أنك المسؤول المتميز أو المستخدم المتميز للجهاز؟ إذا لم يكن الأمر كذلك، فلن يكون لديك حق الوصول للكتابة لتحديث التطبيق.
هل تقوم بإنشاء كائن AppUpdater في سلسلة واجهة المستخدم الرئيسية للتطبيق؟ إذا لم يكن الأمر كذلك، فلن يتمكن المُحدِّث من عرض واجهة المستخدم وسيفشل عند إطلاق حدث مرة أخرى إلى واجهة المستخدم.
هل ينجح التحديث ولكن يفشل التطبيق في إعادة التشغيل تلقائيًا مع التحديث الجديد؟ يحاول مكون .NET Application Update الخروج من التطبيق عن طريق استدعاء الأسلوب Application.Exit. ومع ذلك، لا تضمن هذه الطريقة إغلاق التطبيق. إذا قمت بنشر موضوع منفصل وتركته قيد التشغيل، فلن تتمكن هذه الطريقة من إيقاف العملية. الحل لضمان إنهاء كافة سلاسل الرسائل هو عن طريق استدعاء الحدث Application.OnExit، أو الاتصال بحدث OnUpdateComplete الخاص بمحدث تطبيق .NET ومعالجة عملية إيقاف التشغيل بنفسك.
5. ملخص
يعد النشر السهل لتطبيقات العميل هدفًا مهمًا للإصدار الأول من إطار عمل .NET. يعد استخدام إطار عمل .NET أسلوبًا رائعًا لإنشاء تطبيقات العميل التي تحل مشكلات النشر. تظل سهولة النشر هدفًا مهمًا للإصدارات الجديدة المستقبلية من .NET Framework. كحل، يمثل مكون تحديث تطبيق .NET الموصوف هنا بعض أفكارنا التي سنكون قادرين على استخدامها مباشرة في الإصدارات المستقبلية من .NET Framework. ومع ذلك، في الفترة التي سبقت ذلك الوقت، يمكن اعتبار مكون تحديث تطبيق .NET طريقة مهمة لبدء إنشاء تطبيقات التحديث التلقائي،
من: csdn، رأيته في Tianji، ولم أدرسه بعناية بعد سوف أتركها للرجوع إليها لاحقا