قواعد مكون MSI ODD

Question

لدي مثبت لا يبدو أنه يتبع قواعد مكون MSI في وقت التثبيت. إليك السيناريو:

نظام التشغيل: Windows 7 X64

المنتج يقوم بتثبيت مجموعة من الملفات المرفقة بمكون مع GUID "123abc" في C: \ Program Files \ Files Common \ Foo. يحتوي المكون على الملفات التالية:
foo.dll، الإصدار 1.0.0.0، (keypath)
foo.sys، الإصدار 1.0.0.0
foo.inf، لا يوجد نسخة
foo.cat، لا يوجد نسخة

المنتج B تثبيت نفس مجموعة الملفات المرفقة بنفس المكون GUID "123abc" في نفس المسار C: \ Program Files \ Files \ Foo. يحتوي المكون على الملفات التالية:
foo.dll، الإصدار 1.0.0.1، (keypath)
foo.sys، الإصدار 1.0.0.0
foo.inf، لا يوجد نسخة
foo.cat، لا يوجد نسخة

تم تثبيت المنتج A أولا، والمنتج B لا يقوم بترقية من المنتج A، فهي مجرد مشاركة MSM مشترك يحتوي على مكون "123abc". توقعاتي هو أنه عند تثبيت المنتج B، ستقوم MSI بمقارنة إصدارات Keypath من Foo.DLL وتحديد هذا المنتج B's Foo.dll أحدث. ثم تقوم جميع الملفات الأربعة المرتبطة بالمكون "123abc" بالكتابة فوق الملفات الموجودة على القرص والتي تم تثبيتها حسب المنتج أ. هذا لا يحدث :( بدلا من ذلك، هذا هو الملفات الناتجة:
C: \ Program Files \ Files Common \ Foo
Foo.dll، الإصدار 1.0.0.1 (من المنتج B)
Foo.sys، الإصدار 1.0.0.0 (من المنتج A)
foo.inf، لا إصدار (من المنتج أ)
FOO.CAT، لا إصدار (من المنتج B)

تم الكتابة فوق DLL وملف القط. من ملف سجل MSI، يمكنني رؤيته ما يلي:

giveacodicetagpre.

اعتقدت أن مكونات MSI مثبتة جميع الملفات المرتبطة بناء على ما إذا كان سيتم تثبيت KeyPath أم لا. ما الذي يمكن أن يسبب كل ملف مرتبط بنفس المكون المراد مقارنة بشكل فردي؟

Answer 1

تحدد الحالة

keypath ما إذا كان سيتم تصرف مكون.الموارد داخل المكون ثم اتبع قواعدها: على سبيل المثال، اتبع الملفات قواعد إصدار الملف .

Answer 2

على افتراض أن كل منتج يستخدم قواعد التكلفة الافتراضية (OMUS) دمج الوحدات التي تحتوي على مكونات مشتركة يجب أن تعمل.FWIW، قد ترغب في التفكير في إجراء MSI الذي يستهلك وحدة الدمج هذه ثم قم بإضافته إلى Boottrapper لكلا المنتجين.يمكن أن تكون خدمة التصحيح نظافة بهذه الطريقة.