c# - إنشاء مجلد وملف على ملف تعريف المستخدم الحالي ، من ملف تعريف المسؤول




windows wix (2)

يسمح عميلنا فقط بتثبيت التطبيقات عند تسجيل الدخول كمسؤول. يجب تثبيت التطبيق الذي يحتاج إلى تثبيت للمستخدم الحالي للجهاز. يتم تثبيت التطبيق بشكل جيد ، تظهر مشكلتي عندما أحتاج إلى إسقاط ملف تهيئة في مجلد ملف تعريف المستخدم / المستخدم. نظرًا لأن هذا هو المكان الذي يريدونه ، يتم حاليًا إسقاط التكوين على ملف تعريف المسؤول عند التثبيت. كيف أتجاوز هذا ، هل هناك طريقة بالنسبة لي للتحقق من التثبيت إذا كان هناك ملفات تعريف أخرى ، وربما اكتب إليهم ، ولكن هذا يبدو سيئًا.


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

ربما ألقِ نظرة على ذكر ميزة حماية Win10 ransomware أدناه للحصول على حكاية مهمة حول كيفية تأثير تغيير Windows هذا على نشر ملفات ملفات تعريف المستخدمين .

المناهج المشتركة

  • هناك العديد من الطرق لنشر الملفات لكل مستخدم على جهاز كمبيوتر ، ولكن هناك العديد من العيوب والمشاكل المتعلقة بمعظم الطرق. بكل صدق ، هناك مشاكل في جميع الأساليب ، بشكل أو بآخر.

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

    • 1: قالب لكل آلة

      • قم بتثبيت ملف التكوين على موقع لكل جهاز يمكن قراءته لجميع المستخدمين ، ثم انسخ الملف من هناك ووضعه في ملف تعريف المستخدم عند بدء تشغيل التطبيق باستخدام التطبيق نفسه للقيام بنسخ العمل مرة واحدة لكل مستخدم.
      • هذا هو النهج الموصى به. يمكنك حتى تحديث التطبيق الخاص بك مع المنطق لفرض التحديثات لكل مستخدم إذا كنت بحاجة إلى استخدام نهج مثل هذا: http://forum.installsite.net/index.php?showtopic=21552 .
      • ستظل دائمًا قيد التشغيل في سياق المستخدم الصحيح عندما تحدث النسخة ، ولا داعي للقلق بشأن تعقيدات MSI المعقدة ، والتكيف مع التسلسل.
      • من الميزات الجيدة لهذا النهج أنه سيعمل حتى إذا كان مصدر التثبيت (MSI) مفقودًا عند بدء تشغيل التطبيق.
    • 2: إنشاء ملف عند التشغيل - "الإعدادات الافتراضية الداخلية"

      • كما يقترح gilliduck ، قم ببساطة بإنشاء ملف التكوين عند التشغيل باستخدام الإعدادات الداخلية للتطبيق وعدم تثبيت الملف على الإطلاق . يحدث مرة واحدة لكل مستخدم ، ومنذ ذلك الحين تستخدم الملف الموجود هناك. إن إبقاء هذا الملف خارج برنامج التثبيت الخاص بك يعني أنك تقضي على خطر قيام برنامج التثبيت بالكتابة عن غير قصد أو إلغاء تثبيته.
      • السؤال الواضح هو لماذا ستحتاج إلى مثل هذا الملف على الإطلاق - إذا كنت تستطيع إنشاؤه من الإعدادات الافتراضية الداخلية؟ من الواضح أن الإجابة قد ترغب في فرض بعض القيم المحددة الفريدة لبيئة المستخدم بمجرد إنشاء الملف. ومع ذلك ، يمكن حفظ الإعدادات مثل هذه في التسجيل؟
      • يمكنك تعيين الإعدادات المخصصة المعنية في قسم HKLM في السجل عبر الخصائص العامة أثناء التثبيت (يمكن تكوينه من قبل المستخدم في سطر الأوامر أو عبر تحويل ، راجع: كيفية استخدام ملفات MSI بشكل أفضل للحصول على معلومات حول هذا) ، وفرضها على جميع المستخدمين عند تشغيل التطبيق - بمعنى آخر ، اكتبهم إلى HKCU. أو يمكنك فقط إبقاء الإعدادات "للقراءة فقط" في HKLM وفرضها على جميع المستخدمين بهذه الطريقة في تطبيقك؟ (الإعدادات القابلة للتكوين من غير المستخدم - مثل اسم خادم الشبكة أو ما شابه).
      • لا يزال بإمكانك استخدام الطريقة من الرابط أعلاه لفرض التحديثات على ملفات التكوين الموجودة عند بدء تشغيل التطبيق من خلال جعل برنامج الإعداد الخاص بك يكتب إشارة إلى HKLM لإشعار أن عملية النشر قد "حدثت" منذ الإطلاق الأخير.
      • أو ، كما ذكر ، استخدم التسجيل للاحتفاظ بالإعدادات بدلاً من ذلك.
      • كيفية قراءة ملف نصي الموارد المضمنة
    • 3: MSI للإصلاح الذاتي

      • ضع ملف التكوين في مكانه لكل مستخدم باستخدام الإصلاح الذاتي لـ MSI . يحدث هذا عند استدعاء نقطة إدخال معلن عنها مثل اختصار معلن يستخدم لتشغيل التطبيق.
      • يتطلب الوصول إلى مصدر التثبيت في وقت حدوث الإصلاح. تأكد من تخزين ملف MSI في المربع.
      • قد لا يعمل الإصلاح الذاتي على الخوادم الطرفية (ميزة معطلة). لقد مرت سنوات منذ آخر اختبار لي. لست متأكدًا من كيفية تكوين الخوادم في هذه الأيام.
      • ما لم يتم تكوينه ، قد يقوم برنامج إلغاء التثبيت بإلغاء تثبيت ملف التكوين للمستخدم الذي يقوم بإلغاء التثبيت الفعلي ، أو قد يحدث ذلك أثناء عملية ترقية رئيسية (وهو في الحقيقة إلغاء تثبيت منتجك وإعادة تثبيته). بمعنى آخر: قم بتعيين المكون الدائم (وليس الكتابة فوقه أبدًا) - أو قد يظهر الملف الخاص بك مكتوبًا أثناء الترقية (لكن تم إلغاء تثبيته بالفعل وإعادة تثبيته).
      • بالنسبة لإعدادات تسجيل HKCU ، لن تحتاج بالضرورة إلى توفر مصدر التثبيت. راجع شرح ستيفان كروغر : http://www.msifaq.com/a/1011.htm . الإجراء هو نفسه لتشغيل تثبيت ملفات userprofile (ولكن بعد ذلك يكون مصدر التثبيت مطلوبًا). مناقشة مرتبطة - في حال كانت مفيدة .
      • على الرغم من عدم اختباري من قبل ، فقد فكرت في تعيين قيمة مسار مفتاح التسجيل إلى: HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] لجعل قيمة مسار المفتاح "هدفًا متحركًا" بحيث يكون الإصلاح الذاتي هو يتم تشغيله بشكل موثوق عندما يقوم المستخدم بتسجيل الدخول إلى جهاز كمبيوتر جديد (على الرغم من ملفات تعريف التجوال التي تجلب إعدادات HKCU الحالية).
      • كما قلت ، لم تختبره منذ أن تخلت عن هذا النهج إلى حد كبير - لأنه أقل موثوقية في الاعتماد على كل تحديث جديد لنظام التشغيل Windows. يتم تغيير شيء غريب في كل مرة ، مع نتائج غير متوقعة.
      • على الرغم من عدم ارتباطها بنسبة 100٪ ، إلا أنه يمكنني الإشارة إلى ميزة حماية برامج الفدية الجديدة في نظام التشغيل Windows 10 كمثال - يبدو أنها تسبب أخطاء وقت تشغيل متقطعة لأي MSI يحاول الكتابة إلى مجلدات بيانات المستخدم. يبقى أن نرى عدد مشكلات النشر التي ستنشأ - بينما نرى نتائج متقطعة حتى الآن - ما الذي سيحدث عند تشغيل الميزة ووقت تشغيلها افتراضيًا؟
      • وعلى نفس المنوال الموضح أعلاه ، يوفر برنامج أمان الجهة الخارجية أيضًا عوائق أمام النشر عن طريق حظر نشاط نظام ملفات معين وعزل الملفات التي تم وضع علامة عليها لسبب ما (بما في ذلك الإيجابيات الخاطئة) - مما تسبب في إصلاح ذاتي لا يمكن إكماله أبدًا ، ولكن الحفاظ عليه يعمل دون جدوى.
      • كملخص قصير ، فيما يلي بعض الأسباب التي تجعل من المفيد أكثر فأكثر تجنب نشر ملفات ملفات تعريف المستخدمين عبر الإصلاح الذاتي:
        • مضاعفات التشكيل الجانبي المتجول .
        • Ransomware ميزة الحماية تدخل .
        • تداخل برامج الأمان (خاصة إيجابيات البرامج الضارة الخاطئة).
        • قيود ملقم المحطة الطرفية على إصلاح الذات .
        • إعادة تعيين البيانات أو إعدادات إلغاء مشاكل أثناء الترقية الرئيسية .
        • ربما تشعر بنفس الشعور الذي أشعر به: فهناك المزيد ، وسيستمر الأمر في الأسوأ.
        • بلدي سنتان : تحدث إلى مديرك على الفور حول إدارة ملفات البيانات بشكل أفضل للتطبيق الخاص بك والتخلي عن كل المحاولات لتكون "ذكية" أثناء النشر. نشر لكل ملف الجهاز فقط مع MSI - إن أمكن.
        • من المحتمل أن يتغير هذا التفضيل في المستقبل حيث تتغير تكنولوجيا النشر ويتم التثبيت لكل مستخدم فقط (ربما).
        • وصفًا أطول للمشكلة التي تمت كتابتها مسبقًا: لماذا من الجيد قصر نشر الملفات على ملف تعريف المستخدم أو HKCU عند استخدام MSI؟
        • ودردشة فوضوي بالكامل حول مشكلات النشر بشكل عام : كيف أتجنب عيوب التصميم الشائعة في حل نشر WiX / MSI الخاص بي؟
    • 4: الإعداد النشط ( لم يعد مستحسن ، يرجى قراءة )

      • ضع ملف التكوين في مكانه باستخدام الإعداد النشط . يحدث هذا عند تسجيل دخول المستخدم (والذي يتطلب بعد ذلك تسجيل الخروج وتسجيل الدخول أن يحدث ما لم تتأكد من تثبيت الملف أيضًا إلى ملف تعريف المستخدم الحالي عند التثبيت).
      • هذا في الواقع اختلاف في الطريقة 1. يجب تثبيت ملف التكوين على موقع لكل جهاز ، يمكن قراءته من قبل جميع المستخدمين.
      • ثم تقوم بتسجيل مهمة في السجل لتشغيل "شيء قابل للتشغيل" مرة واحدة لكل مستخدم. يمكنك تشغيل أي شيء مثل ملف دفعي أو ملف قابل للتنفيذ أو برنامج نصي أو إصلاح النهج المفضل لدي MSI والذي سيتمكّن من وضع ملف ملف تعريف المستخدم في مكانه (في هذه الحالة ، لن تحتاج إلى ملف في موقع لكل جهاز ، ولكن الوصول إلى مصدر التثبيت كما يعمل الإعداد النشط).
      • احذر من الكتابة فوق ملف التكوين الذي تم وضعه أثناء التثبيت للمستخدم الحالي. أو تعطيل الإعداد النشط من التشغيل لهذا المستخدم عن طريق كتابة مفتاح HKCU المكتوب بعد تشغيل الإعداد النشط للمستخدم المعني (انظر الرابط أدناه).
      • تمت محاولة شرح الإجراء في إجابتي هنا: تحديث سجل كل ملف تعريف على Windows Server 2003 . كل ذلك يعتمد على مفتاح HKLM الذي يتم تشغيله مرة واحدة لكل مستخدم. تحقق من الإجابة المرتبطة لمزيد من التفاصيل ، وهناك عدد قليل من الروابط الخارجية التي توفر الكثير من التفاصيل.
      • استكمال : عند التثبيت على "الخادم الطرفي" ، يمكنك وضع الخادم في "وضع التثبيت" ، ثم تتم كتابة إدخالات التسجيل لكل مستخدم على HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install ثم كتابتها إلى خلية HKCU لكل مستخدم عند تسجيل الدخول. قد يتعارض هذا مع ActiveSetup - لكل ما أعرفه. لم تتح لي الفرصة أبداً لاختباره. تتم التعبئة والتغليف للخادم الطرفي عادة بواسطة فريق خادم متخصص.
    • 5: MsiProvideComponent

      • Phil MsiProvideComponent المثير للاهتمام ، وأنا لم تستخدم ذلك. يجب علي.

نهوج الغيوم

  • مع انتقال تخزين البيانات على ما يبدو إلى السحابة ، قد تصبح الطرق الشائعة لنشر ملفات البيانات قديمة.

    • 6: قم بتنزيل ملف الإعدادات

      • قم بتنزيل ملف الإعدادات - مرة واحدة لكل المستخدمين عند تشغيل التطبيق - من قاعدة بيانات / مشاركة شبكة محلية أو من الإنترنت بدلاً من ذلك - إذا كان هذا خيارًا.
      • يمكن أن يحفظ المسؤول عن الملف البعيد لتحديث القيم إذا كانت هناك قيم افتراضية جديدة أو يحتاج الأمر إلى إزالتها.
      • يمكن لآليات التكوين في ملف الإعدادات الذي يفهمه التطبيق الخاص بك أن تفرض قيمًا جديدة "مفروضة" على جميع المستخدمين.
      • هل تسمح بتكوين قائمة بالخوادم في HKLM؟ شكلي في MSI عبر الخصائص العامة ؟
      • أو قم بتعيين عنوان URL واحد في الإعداد أثناء التثبيت ، واحتفظ بقائمة من الخوادم عبر عنوان URL هذا (يمكنك إعادة توجيه الخادم الذي يشير إليه هذا عبر DNS بحيث تكون التهيئة مهمة مسؤول النظام دون الحاجة إلى إعادة النشر؟). مجموعة الاختيار الحالية في HKCU.
    • 7: قراءة / إعدادات الكتابة من قاعدة البيانات عن بعد

      • إعدادات القراءة / الكتابة مباشرة من / إلى قاعدة بيانات محلية أو الإنترنت باستمرار بدلاً من ذلك.
      • لا يوجد ملف إعدادات محلية على الإطلاق ، أو نسخة للقراءة فقط مؤقتًا عندما يتعذر الوصول إلى الخادم؟ أو مجرد تشغيل مع الإعدادات الافتراضية للتطبيق الداخلي إذا تعذر الوصول إلى الخادم؟ لا يوجد ملف على الإطلاق لإدارة في النهج الأخير.
      • يمكنك كتابة قائمة بالخوادم (عناوين URL) لاستخدامها في HKLM (حتى حسب سياسة المجموعة؟) ، وحتى الحفاظ على الخادم المحدد حاليًا في HKCU لكل مستخدم. ثم الباقي يحدث عبر الإنترنت.
      • يستخدم بشكل عام في تطبيقات العميل / الخادم للشركات حتى الآن - ولكن الأنظمة الأساسية المستندة إلى مجموعة النظراء ستغير النشر إلى الأبد - خاصة للمستخدمين المنزليين. لقد رأينا أن المتصفحات تحافظ على الإعدادات عبر الإنترنت لفترة طويلة (Chrome ، Opera ، Firefox ، إلخ ...).
      • تخزين قاعدة البيانات عن بُعد يعني أنه يمكنك الحفاظ على إعدادات المستخدم كمهمة لإدارة قاعدة البيانات ، ويمكنك حتى إصدار بيانات المستخدم في قاعدة البيانات وفرض افتراضيات جديدة بسهولة أو فرض تحديث القيم الحالية لجميع المستخدمين كمهمة DBO مركزية .
        • لا مزيد من مشكلة ملف تعريف التجوال المزعجة.
        • لا مزيد من فشل نشر ملفات userprofile.
        • باختصار: لا توجد إعدادات للمستخدم لنشرها على الإطلاق ، ولن تنفد البيانات متزامنة على أجهزة مختلفة.
        • جدار الحماية / الوكيل وشبكة الاتصال القضايا؟

ملخص

لم يعجبني الخيار 3 (إصلاح ذاتي) والخيار 4 (الإعداد النشط) بعد الآن ، على الرغم من أنني استخدمتهما عدة مرات - وهما يعملان بشكل صحيح عند الانتهاء. ومع ذلك ، فهي ليست محصنة ضد مشكلات ملفات التعريف المتجولة (الملفات التي لا يتم نسخها في مكانها على جميع الأنظمة التي يسجل المستخدم دخولها) وتفتقر إلى الوصول إلى مصدر تثبيت MSI عند تشغيل الإصلاح - مما قد يسبب مشاكل النشر. هناك أيضًا مضاعفات متكررة أثناء ترقيات رئيسية مع إعدادات إعادة التعيين ، وفشل الإصلاح الذاتي على الخوادم الطرفية. قد تفشل عملية الإصلاح الذاتي للتثبيت في ملف تعريف المستخدم بسبب تداخل حماية برامج الفدية أو تداخل برامج الأمان. يمكن أن يكون سطر الأوامر المحدد في الخيار 4 (الإعداد النشط) عربات التي تجرها الدواب وعملية مسح البيانات (على سبيل المثال يمكنك تمكين إشارة خاطئة لإصلاح msiexec.exe وفرض ملف الإعدادات عن طريق الصدفة - وغالبا ما لا يتم اكتشاف هذا حتى يتم أيضا في وقت متأخر ويتم الضرر). وهناك المزيد من القضايا التي تنجو مني الآن. كلا النهجين لها قيود متشابهة ، لكن مختلفة بعض الشيء.

أفضّل أكثر فأكثر الأساليب المستندة إلى مجموعة النظراء لجعل ملفات إعدادات المستخدم المحلية (والمعزولة) شيئًا من الماضي - لكنني نادراً ما تمكنت من نشر الأشياء بهذه الطريقة. قد تواجه هذه الطرق السحابية مشاكل في جدار الحماية / مشكلات الوكيل ومشاكل اتصال الشبكة رغم ذلك - وربما العديد من الأشياء الأخرى التي لست على دراية بها حتى الآن (الآن سيتشاجر المطورون مع قواعد بيانات النشر بدلاً من متخصصي النشر ، إلخ ... ؛-)). الحوسبة الموزعة لها مغالطات: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing . أيضًا: في الأساليب المستندة إلى مجموعة النظراء ، قد لا يزال من الجيد للتطبيقات السماح بنسخ الإعدادات احتياطيًا على القرص ، لذلك من الواضح أنه لا تزال هناك حاجة إلى بعض إدارة الملفات - أو هل تقوم فقط بتصدير بضعة جداول قاعدة بيانات؟ أيضًا: إذا قمت بتثبيت إصدار تجريبي من التطبيق الخاص بك ، فقد ترغب في أن يكون قادرًا على العمل دون الاتصال بالشبكة على الإطلاق - في حال كان المستخدم وراء جدار حماية محكم للغاية. يعد من الخطأ الغالي جدًا عدم السماح للمستخدم باختبار ميزات التطبيق الخاص بك بسبب وجود مشكلة فنية.

الفائدة الكبيرة من الخيارين 1 و 2 هي أنها ستعمل حتى إذا كانت وسائط التثبيت الأصلية مفقودة عند تشغيل الإصلاح. هذا مهم بشكل خاص لنشر المنازل والمكاتب الصغيرة حيث قد يحدث النشر عشوائيًا دون مشاركة حزمة مركزية. يمكنك حل هذه المشكلة (مصدر MSI المفقود) باستخدام أساليب التخزين المؤقت لتخزين MSI بالكامل على النظام أثناء التثبيت (المتوفر في Installshield ، لم أقم بالتحقق من WiX أو Advanced Installer).


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





profiles