איך בוחרים שיטת הפצה ליישום Windows - MSI/‏MSIX/‏ClickOnce/‏xcopy/עדכון עצמי

הורדת גיליון עבודה להחלטה ב-Excel, שכולל גיליון ביפנית ובאנגלית

כשמחליטים על שיטת הפצה ליישום Windows, נוטים להתחיל את השיחה מ-‘מה חדש יותר’ או ‘מה קל יותר’. אבל בעבודה מעשית, מה שבאמת משפיע הוא ציר אחר.

• האם רוצים להתקין ביחידת המשתמש, או במכונה כולה
• האם רוצים להפקיד את העדכון בידי תשתית ההפצה, או להחזיק אותו בעצמכם
• האם יש אינטגרציה עם ה-OS כמו שירות, מנהל התקן,‏ shell extension, או רישום COM
• האם יש צורך לעמוד בהפצת רשת סגורה,‏ offline, או USB
• האם דרוש package identity, או שרוצים לפעול כ-Win32 טהור וללא הגבלות (unrestricted)

בחירת שיטת ההפצה אינה טעם בצורת המתקין, אלא בחירה של עד כמה נוגעים ב-OS ו-מי נושא באחריות העדכון.

flowchart TB
    accTitle: שני הצירים שקובעים את שיטת ההפצה
    accDescr: תרשים המראה שבחירת שיטת ההפצה אינה טעם בצורת המתקין - מה חדש או קל יותר - אלא בחירה בשני צירים: עד כמה נוגעים ב-OS, ומי נושא באחריות העדכון.
    a0["'מה חדש או קל יותר'"] -.-> a1["לא מחליטים לפי הציר הזה"]
    a2["עד כמה נוגעים ב-OS"] --> a4["שיטת ההפצה נקבעת"]
    a3["מי נושא באחריות העדכון"] --> a4

איור 1: שיטת ההפצה נקבעת לא לפי טעם, אלא לפי שני צירים - צפיפות האינטגרציה עם ה-OS ואחריות העדכון.

המאמר הזה נכתב עבור מפתחים שבונים יישום שולחני ל-Windows ועדיין צריכים להחליט על שיטת הפצה, או רוצים לבחון מחדש את השיטה הנוכחית שלהם, וכן עבור אנשי מערכות מידע שמקבלים לידיים את התפעול. הוא לא מניח שפה או framework מסוימים. זהו תחום עם הרבה מונחים שנפוצים באנגלית כמות שהם, ולכן ריכזתי אותם בסעיף 1.1. תוכן גיליון העבודה שבראש המאמר מסוכם בסעיף 1.2.

1. קודם כל, המסקנה

בגסות רבה, אבל בניסוח נוח לעבודה מעשית, זה כך:

• אם מתקינים במכונה כולה, יש שירות או רישום COM, או יש תנאים מוקדמים להתקין - נקודת המוצא היא MSI
• אם מניחים Windows 10/11, ורוצים clean install‏/clean uninstall, עדכונים תכופים, ו-package identity - MSIX הוא האפשרות המובילה
• אם רוצים להפיץ בקלות ולעדכן אוטומטית יישום שולחני פנים-ארגוני של‏ .NET, ביחידת המשתמש - ClickOnce עדיין חזק למדי
• אם מעדיפים כלי שפועל רק בהנחתו, רשת סגורה, הפצת USB, ובלי הרשאות מנהל - xcopy הכי פשוט
• אם רוצים לאחוז בעצמכם ב-UX העדכון, ערוצים, הפצה מדורגת,‏ telemetry, ואסטרטגיית התאוששות - זהו מנגנון עדכון עצמי (updater)
• אם דרוש מנהל התקן, בטוח יותר לא לחשוב סביב MSIX מלכתחילה
• אם דרושה in-process shell extension ל-Explorer, יש לבדוק מראש את טווח התמיכה ב-MSIX ואת תנאי גרסת ה-OS

בסיכום גס, זה כך:

1. הרישום ל-OS צפוף ← MSI
2. רוצים package identity ו-modern packaging ← MSIX
3. רוצים הפצה קלה ב-per-user ועדכון built-in ← ClickOnce
4. הפצה שמסתפקת בהנחה היא בעדיפות עליונה ← xcopy
5. מוכנים לתכנן ולתפעל תשתית עדכון בעצמכם ← עדכון עצמי (updater)

flowchart TB
    accTitle: סיכום גס של חמש השיטות
    accDescr: תרשים המראה שאם הרישום ל-OS צפוף בוחרים MSI, אם רוצים package identity ו-modern packaging בוחרים MSIX, אם רוצים הפצה קלה ב-per-user ועדכון built-in בוחרים ClickOnce, אם הפצה שמסתפקת בהנחה היא בעדיפות בוחרים xcopy, ואם מוכנים לתכנן ולתפעל תשתית עדכון בעצמם בוחרים בעדכון עצמי.
    b1{"האם הרישום ל-OS צפוף"} -->|"כן"| b2["נוטים ל-MSI"]
    b1 -->|"לא"| b3{"האם רוצים package identity"}
    b3 -->|"כן"| b4["MSIX"]
    b3 -->|"לא"| b5{"הפצה פשוטה ב-per-user + עדכון אוטומטי"}
    b5 -->|"כן"| b6["ClickOnce"]
    b5 -->|"הנחה בלבד היא עדיפות"| b7["xcopy"]
    b7 -.-> b8["אם מוכנים לאחוז בתשתית העדכון בעצמם - עדכון עצמי"]

איור 2: כשמתלבטים, מפרידים לפי הסדר - צפיפות הרישום, identity, ופשטות ההפצה.

1.1 מונחים שמופיעים בגוף המאמר

בתחום ההפצה יש הרבה מונחים שנפוצים באנגלית כמות שהם, ולכן מסדרים אותם כאן מראש.

1.2 מה יש בגיליון העבודה שבראש המאמר

גיליון ה-Excel שבראש המאמר נועד להתאים את ההחלטות של המאמר לפרויקט שלכם ולתעד אותן. יש גרסה ביפנית וגרסה באנגלית, וכל אחת בנויה משני גיליונות.

גיליון ה-Planner מחולק לשלושה בלוקים.

1. גיליון קלט: מילוי שבעת הפריטים הבאים מאפשר לרשום מועמד ראשון ואת הסיבה
   • היקף ההפצה … per-user‏/per-machine/שניהם/טרם הוחלט
   • מרכיב אינטגרציה עם ה-OS … ללא/שירות/מנהל התקן/shell extension/רישום COM/כמה מהם
   • package identity … דרוש/לא דרוש/לא ניתן להכריע
   • דרישת התקנה במשתמש סטנדרטי … חובה/לא נדרש/תלוי בתנאים
   • תדירות עדכון … ידני או נדיר/חודשי/שבועי/יותר מכך
   • סביבת היעד … רשת סגורה/offline / Windows חדש ומנוהל / Windows מעורב עם דורות ישנים / USB/שטח
   • הערת סוג אפליקציה … שולחני פנים-ארגוני של‏ .NET/מוצר מסחרי/כלי שירות/מעורב
2. איך מבחינים בין המועמדים: עבור כל אחת מחמש השיטות, ‘התנאי שבודקים ראשון בתוקף’ ו-‘התנאי שקל לפסול קודם’
3. זרימת ההחלטה: באיזה סדר לבחון את הפריטים למעלה, ולאיזו שיטה זה נוטה בתוצאה

גיליון ה-Reference מכיל כמות שהן את טבלת ההחלטה מפרק 3 ואת טבלת ההשוואה מפרק 4 של המאמר הזה.

כלומר, זו צורה שמאפשרת למלא את פרקים 3, 4 ו-7 של המאמר לכל פרויקט. אם מספיק לקרוא כדי להגיע למסקנה, אין צורך להוריד. השתמשו בו כשרוצים להשוות בין כמה פרויקטים, או להשאיר תיעוד של בסיס ההחלטה בארגון.

flowchart TB
    accTitle: איך משתמשים בגיליון העבודה
    accDescr: תרשים המראה את זרימת גיליון העבודה, שמתעד את ההחלטה לכל פרויקט - מילוי שבעת פריטי גיליון הקלט, צמצום לפי איך מבחינים בין המועמדים, נטייה לשיטה לפי זרימת ההחלטה, ורישום המועמד הראשון והסיבה.
    c1["ממלאים את שבעת פריטי גיליון הקלט"] --> c2["מצמצמים לפי איך מבחינים בין המועמדים"]
    c2 --> c3["נוטים לשיטה לפי זרימת ההחלטה"]
    c3 --> c4["רושמים את המועמד הראשון ואת הסיבה"]
    c4 -.-> c5["גיליון ה-Reference הוא טבלאות פרק 3 ו-4"]

איור 3: גיליון העבודה נועד להפוך את החלטות המאמר לתיעוד עבור כל פרויקט.

מפת הידע של המאמר

שיטת ההפצה של יישום Windows נבחרת לא לפי טעם בצורת המתקין, אלא לפי שני צירים - צפיפות האינטגרציה עם ה-OS ומי נושא באחריות העדכון. MSI מתאימה להתקנה שנוגעת עמוק ב-OS, כמו שירות Windows, רישום COM, מנהל התקן, או shell extension, אך אין לה package identity. MSIX מממשת package identity ומספקת ניקיון ב-clean install ובעדכון, אך בעיקרה לא מתאימה למנהל התקן או ל-shell extension. ClickOnce מאפשרת להפיץ ולעדכן אוטומטית יישום .NET ב-per-user בקלות, אך לא מתאימה למוצר שכולל שירות Windows. הפצת xcopy מבוססת על הפשטות של להסתפק בהנחה, במחיר של אי-התאמה ל-package identity ולשירות. עדכון עצמי הוא בחירה שבה, במחיר של אחריות עצמית על אימות חתימה וניהול אישור לחתימת קוד, מקבלים חופש בעדכון ויכולת התמודדות עם הפצה ברשת סגורה.

flowchart LR
    accTitle: מפת הידע של שיטות הפצה ליישום Windows
    accDescr: תרשים המראה איך MSI,‏ MSIX,‏ ClickOnce,‏ xcopy ועדכון עצמי (updater) נבחרים לפי שני צירים - צפיפות האינטגרציה עם ה-OS ומי נושא באחריות העדכון.
    msi["MSI(Windows Installer)"]
    msix["MSIX"]
    clickonce["ClickOnce"]
    windows_service["שירות Windows"]
    driver_package["חבילת מנהל התקן"]
    shell_extension["הרחבת מעטפת (הרחבת סייר הקבצים)"]
    com["‏COM (Component Object Model)"]
    closed_network["רשת סגורה"]
    package_identity["package identity"]
    code_signing_cert["אישור לחתימת קוד"]
    dotnet["‏.NET (מ-Core ואילך)"]
    xcopy_deployment["הפצת xcopy"]
    custom_updater["מנגנון עדכון עצמי"]
    msi -->|"מענה מומלץ ל"| windows_service
    msi -->|"מענה מומלץ ל"| driver_package
    msi -->|"מענה מומלץ ל"| shell_extension
    msi -.->|"משתמש ב"| com
    msi -->|"מענה מומלץ ל"| closed_network
    msix -->|"מממש את"| package_identity
    msix -->|"שימוש לא מומלץ ל"| driver_package
    msix -.->|"שימוש לא מומלץ ל"| shell_extension
    msix -.->|"מענה מומלץ ל"| closed_network
    msix -->|"מחייב"| code_signing_cert
    clickonce -.->|"מחייב"| dotnet
    clickonce -.->|"מענה מומלץ ל"| closed_network
    clickonce -->|"שימוש לא מומלץ ל"| windows_service
    xcopy_deployment -->|"שימוש לא מומלץ ל"| windows_service
    xcopy_deployment -->|"מענה מומלץ ל"| closed_network
    custom_updater -.->|"מחייב"| code_signing_cert
    custom_updater -.->|"מענה מומלץ ל"| closed_network

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 17, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

2. חמש השיטות אינן על אותה זירה

זה חשוב מאוד.

MSI‏/MSIX‏/ClickOnce‏/xcopy הם בעיקר סיפור של איך מתקינים. לעומת זאת, עדכון עצמי (updater) הוא בעיקר סיפור של איך נושאים באחריות העדכון.

כלומר, בעבודה מעשית קל יותר לסדר את זה כשמפרידים לשתי שכבות.

בתרשים זה נראה כך. הקו המקווקו הוא ‘אמצעי העדכון שמתחבר באופן טבעי לשיטת ההתקנה הזו’.

flowchart TB
    accTitle: מודל שתי השכבות - התקנה ראשונית ועדכון מתמשך
    accDescr: תרשים המראה שיישום Windows להפצה מפוצל לשתי שאלות - איך מתקינים (שכבת ההתקנה הראשונית, עם MSI, MSIX, ClickOnce ו-xcopy) ומי נושא באחריות העדכון (שכבת העדכון המתמשך, עם MSIX App Installer, ClickOnce, החלפה ידנית ועדכון עצמי) - כשקו מקווקו מסמן איזה אמצעי עדכון מתחבר באופן טבעי לכל שיטת התקנה.
    APP["יישום Windows להפצה"] --> Q1["קודם - איך מתקינים - שכבת ההתקנה הראשונית"]
    APP --> Q2["אחר כך - מי נושא באחריות העדכון - שכבת העדכון המתמשך"]

    Q1 --> MSI["MSI"]
    Q1 --> MSIX["MSIX"]
    Q1 --> CO["ClickOnce"]
    Q1 --> XC["xcopy"]

    Q2 --> AI["MSIX App Installer"]
    Q2 --> COU["עדכון built-in של ClickOnce"]
    Q2 --> MAN["החלפה ידנית"]
    Q2 --> OWN["עדכון עצמי（updater）"]

    MSIX -.-> AI
    CO -.-> COU
    MSI -.-> MAN
    XC -.-> MAN
    MSI -.-> OWN
    XC -.-> OWN

איור 4: מודל שתי השכבות - התקנה ראשונית ועדכון מתמשך. קו מקווקו מסמן אמצעי עדכון שמתחבר באופן טבעי.

ב-ClickOnce וב-MSIX, אם מחליטים על השכבה העליונה, גם השכבה התחתונה נקבעת כמעט אוטומטית. לעומת זאת, ב-MSI וב-xcopy צריך להחליט על השכבה התחתונה בנפרד. ‘איך לעשות עדכון’ נוטה להישאר תלוי באוויר דווקא כשבוחרים בשניים האלה.

לכן, כדאי לחשוב על עדכון עצמי לא כמשהו שבוחרים בו ראשון, אלא כמשהו שנבחר בנוסף כשיש דרישת עדכון שלא מכוסה בשיטת ההפצה הקיימת - כך זה לא סוטה.

flowchart TB
    accTitle: העדכון נשאר תלוי באוויר ב-MSI וב-xcopy
    accDescr: תרשים המראה שב-ClickOnce וב-MSIX, בחירת שיטת ההתקנה קובעת כמעט אוטומטית גם את אמצעי העדכון, אך ב-MSI וב-xcopy יש להחליט על שכבת העדכון המתמשך בנפרד, ושעדכון עצמי הוא מה שמוסיפים כשהדרישה הזו לא מכוסה.
    d1["בוחרים ClickOnce / MSIX"] --> d2["אמצעי העדכון נקבע כמעט אוטומטית"]
    d3["בוחרים MSI / xcopy"] --> d4["איך לעדכן נשאר תלוי באוויר"]
    d4 --> d5["מחליטים בנפרד על שכבת העדכון המתמשך"]
    d5 -.-> d6["כשחסר - מוסיפים עדכון עצמי"]

איור 5: עדכון עצמי אינו האפשרות הראשונה, אלא בחירה נוספת שממלאת את החור בשכבת העדכון.

3. טבלת החלטה בדף אחד

קודם כול, הטבלה הנוחה ביותר לשימוש.

החשוב ביותר בטבלה הזו הוא לא לקפוץ ישר לעדכון עצמי רק בגלל ש’יש עדכון’.

4. השוואה לפי היבטים

מה שכדאי לראות בטבלה הזו הוא לא מה הכי חזק, אלא מה גורם לפחות חיכוך.

5. לאיזה סוג פרויקט כל שיטה מתאימה

5.1 MSI

MSI היא נקודת הייחוס כשרוצים להתקין, להסיר ולתקן (install/uninstall/repair) כראוי יישום שולחני מסורתי של Windows.

היא מתאימה במיוחד לפרויקטים מהסוג הזה.

• יישום עסקי לכל המשתמשים
• יישום שכולל שירות Windows
• יישום עם רישום COM, שיוך קבצים, והגדרות machine-wide
• מוצר שכבר יש לו תפעול מתקין קיים

היתרון של MSI הוא שקל לבטא בסגנון Windows ‘איך האפליקציה הותקנה ב-OS’.

מצד שני, יש גם חולשות ברורות.

• ה-authoring קשה באופן שקט
• תכנון רשלני של upgrade‏/patch גורם לסבל בהמשך
• ככל שמוסיפים custom action, קל יותר להישבר
• במוצר עם עדכון תכוף,‏ UX העדכון נוטה להיות כבד

flowchart TB
    accTitle: היתרון והמחיר של MSI
    accDescr: תרשים המראה ש-MSI מבטאה בקלות בסגנון Windows איך האפליקציה הותקנה ב-OS, אך במחיר של authoring קשה, שביר יותר ככל שמוסיפים custom action, ו-UX עדכון כבד בעדכון תכוף.
    e1["MSI"] --> e2["מבטא בסגנון Windows איך הותקן ב-OS"]
    e2 --> e3["install / uninstall / repair מלאים"]
    e1 -.-> e4["authoring קשה באופן שקט"]
    e4 -.-> e5["שביר יותר ככל שמוסיפים custom action"]

איור 6: MSI מקבלת כוח ביטוי באינטגרציה עם ה-OS, במחיר של קושי ב-authoring.

5.2 MSIX

MSIX היא בחירה כשרוצים modern packaging ו-clean update‏/uninstall. גם כשרוצים להשתמש בפונקציות Windows שדורשות package identity, המשמעות שלה גדלה.

היא מתאימה בערך לאלה.

• יישום שולחני שיכול להניח Windows 10/11
• יישום עסקי עם תדירות עדכון גבוהה יחסית
• יישום שרוצה להשתמש בפונקציות Windows שתלויות ב-package identity
• פרויקט שרוצה להתאים ל-Intune או App Installer

היתרון של MSIX הוא הניקיון של העדכון וההסרה.

עם זאת, לא הכול מתאים לה. בטוח יותר לבדוק מראש במיוחד את ארבע הנקודות האלה.

• in-process shell extension‏（ב-MSIX מ-Windows 11 21H2 ואילך אפשר לרשום handler-ים כמו legacy context menu, אך דרושה הצהרת מניפסט ובדיקת ה-OS היעד）
• driver
• הנחת Win32 ישנה ו-unrestricted
• תצורה שלא רוצה package identity

עבור כל אחת מארבע הנקודות האלה, מקור הבדיקה שונה. אל תעצרו ב-‘נראה שאי אפשר עם MSIX’ - מהיר יותר לקבוע מראש איזה מסמך יכריע.

כל הקישורים נמצאים במקורות בפרק 9. בעת ההחלטה, בדקו לא רק ‘האם נתמך’, אלא גם ‘מאיזו גרסה, ובאיזו הצהרה זה נתמך’. אם לא תופסים את זה כולל תנאי גרסת ה-OS, זה יצוץ בהמשך בצורה של - עבד במחשב הבדיקה, אבל לא הותקן ב-Windows הישן שבשטח.

flowchart TB
    accTitle: מגבלות MSIX - קובעים גם את מקור הבדיקה
    accDescr: תרשים המראה שארבע הנקודות שמעוררות ספק ב-MSIX - כמו shell extension ו-driver - לכל אחת מקור בדיקה שונה, ושבמקום לעצור ב-'נראה שאי אפשר', בודקים מאיזו גרסה ובאיזו הצהרה זה נתמך, כדי למנוע תאונה של עבד בבדיקה אך לא בשטח.
    f1["ארבע הנקודות שמעוררות ספק ב-MSIX"] --> f2["לא עוצרים ב-'נראה שאי אפשר'"]
    f2 --> f3["קובעים באיזה מסמך זה מוכרע"]
    f3 --> f4["בודקים מאיזו גרסה ובאיזו הצהרה"]
    f4 -.-> f5["מונעים עבד בבדיקה אך לא בשטח"]

איור 7: מגבלות MSIX מוכרעות כשבודקים גם את תנאי גרסת ה-OS וגם את אופן ההצהרה.

5.3 ClickOnce

ClickOnce עדיין חזק למדי כשרוצים להריץ במהירות, ב-per-user, כולל עדכון, יישום שולחני פנים-ארגוני של‏ .NET.

היא מתאימה למצבים כאלה.

• יישום עסקי פנים-ארגוני
• רוצים להתקין עם משתמש סטנדרטי
• מספיקה הפצה ביחידת המשתמש
• לא רוצים להשקיע יותר מדי ב-UX העדכון

מצד שני, בטוח יותר לא לצפות ממנה תפקיד של מוצר שנוגע עמוק ב-OS, או מתקין שאוגד כמה תנאים מוקדמים.

5.4 xcopy

xcopy הוא deploy, לא install. אין לה רישום Registry, אין פונקציית תיקון, ואין package identity. במקום זאת, אם מספיק להניח, היא פשוטה ברמה הכי גבוהה.

היתרון שלה בולט בכלים מהסוג הזה.

• כלי אבחון
• כלי הגדרת ציוד
• כלי איסוף לוגים
• כלי שירות שמעבירים לשטח ב-USB
• מקרה שרוצים לקיים כמה גרסאות במקביל (side-by-side)

היתרון של xcopy הוא שדרך הכישלון שלה ברורה. קל לתפעל אותה - מחליפים את התיקייה כולה, ואם רוצים לחזור, חוזרים לגרסה הקודמת.

flowchart TB
    accTitle: xcopy הוא deploy ולא install
    accDescr: תרשים המראה ש-xcopy אין לה רישום Registry, פונקציית תיקון, או package identity, אך במקום זאת מספיק להניח אותה, מעדכנים בהחלפת התיקייה כולה, וחוזרים לגרסה הקודמת אם צריך - תפעול שבו דרך הכישלון ברורה.
    g1["מניחים את התיקייה כולה"] --> g2["פועלת כמות שהיא"]
    g2 --> g3["עדכון: מחליפים את התיקייה כולה"]
    g3 --> g4["חזרה: מחזירים לגרסה הקודמת"]
    g1 -.-> g5["אין רישום, תיקון, או identity"]

איור 8: הערך של xcopy הוא שהתקנה, עדכון וחזרה כולם פשוטים.

אבל כמובן, יש גם חולשות.

• Start menu‏/ARP‏/repair
• שיוך קבצים/שירות/shell extension/מנהל התקן
• עדכון built-in

5.5 עדכון עצמי (updater)

עדכון עצמי הוא פחות בחירת חופש ויותר בחירת אחריות.

כדאי לשקול אותו כשיש דרישות כאלה.

• תדירות עדכון גבוהה
• רוצים ערוצים כמו stable‏/beta‏/preview
• רוצים לשלוט בהפצה מדורגת ובאחוז ה-rollout
• רוצים לשלוט בפירוט בהורדה ברקע, בהתראות, ובחלון תחזוקה
• רוצים לעקוב בעצמכם אחר telemetry של עדכונים והתאוששות מקריסה

היתרונות גדולים, אבל גם המחיר גדול.

• אימות חתימה
• manifest להפצה
• ניסיון חוזר/resume
• proxy/firewall/תמיכה ברשת סגורה
• rollback
• התאוששות מעדכון פגום
• עדכון של ה-updater עצמו

כלומר, מה שגדל הוא אחריות, לא חופש.

flowchart TB
    accTitle: עדכון עצמי הוא בחירת אחריות
    accDescr: תרשים המראה שעדכון עצמי מקבל חופש כמו ערוצים, הפצה מדורגת ו-telemetry, אך במחיר של אחריות לתכנן ולתפעל בעצמכם אימות חתימה, manifest להפצה, rollback, התאוששות מעדכון פגום, ואפילו עדכון של ה-updater עצמו.
    h1["מה שמקבלים: ערוצים, הפצה מדורגת, telemetry"] --> h3["עדכון עצמי"]
    h2["מה שמשלמים: אימות חתימה, rollback, התאוששות"] --> h3
    h3 --> h4["מה שגדל הוא אחריות, לא חופש"]
    h2 -.-> h5["גם עדכון ה-updater עצמו הוא באחריותכם"]

איור 9: מה שגדל בעדכון עצמי אינו החופש, אלא אחריות התפעול של תשתית העדכון.

5.6 אחרי שבוחרים שיטה, מה בודקים הלאה

גם אם מחליטים ‘הולכים על MSI’, אם לא ברור מה לבדוק משם, נתקעים. מסדרים כאן נקודות כניסה נפוצות. אף אחת מהן אינה ‘תשתמשו בזה’, אלא מה שכדאי להכיר בשם, אם בחרתם בשיטה הזו.

מה שכדאי לשים לב אליו כאן הוא שבחירת כלי ובחירת שיטה הן שני דברים שונים. לדוגמה,‏ Inno Setup נוח לשימוש, אבל התוצר אינו MSI, ולכן הוא לא עולה על תפעול שמניח Windows Installer - כמו הפצת תוכנה ב-Group Policy או תיקון באמצעות msiexec. אם הסיבה שבחרתם MSI בסעיף 5.1 נמצאת שם, גם הכלי צריך להתאים לכך.

flowchart TB
    accTitle: בחירת כלי ובחירת שיטה הן שני דברים שונים
    accDescr: תרשים המראה ש-Inno Setup נוח לשימוש אך התוצר שלו אינו MSI, ולכן הוא לא עולה על הפצת תוכנה ב-Group Policy או תיקון באמצעות msiexec, ושיש להתאים את בחירת הכלי לסיבה שבגללה נבחרה השיטה.
    i1["מחליטים על השיטה"] --> i2["מחליטים על הכלי"]
    i2 -.-> i3["Inno Setup לא יוצר MSI"]
    i3 -.-> i4["לא עולה על הפצת GPO או תיקון msiexec"]
    i4 -.-> i5["מתאימים את הכלי לסיבת בחירת השיטה"]

איור 10: כלי נוח לא בהכרח עולה על זירת השיטה שנבחרה.

6. נקודות שקל להתלבט בהן

6.1 האם דרוש package identity

אם מה שרוצים הן פונקציות Windows שמניחות package identity, הערך של MSIX עולה בבת אחת.

לעומת זאת,

• גישה ל-file system ללא הגבלה (unrestricted)
• גישה ל-Registry ללא הגבלה
• חופש ב-elevation/process model
• רוצים להשאיר כמות שהיא הנחת Win32 ישנה

אם כך, שיטה שנוטה ל-unpackaged טבעית יותר.

flowchart TB
    accTitle: מחלקים לפי הצורך ב-package identity
    accDescr: תרשים המראה שאם רוצים פונקציות Windows שמניחות package identity, הערך של MSIX עולה בבת אחת, ושאם רוצים לפעול ללא הגבלה בגישה לקבצים ול-Registry, שיטה שנוטה ל-unpackaged טבעית יותר.
    j1{"האם רוצים פונקציה שמניחה package identity"} -->|"כן"| j2["הערך של MSIX עולה בבת אחת"]
    j1 -->|"רוצים לפעול ללא הגבלה"| j3["שיטה שנוטה ל-unpackaged טבעית יותר"]

איור 11: הצורך ב-identity הוא קו פרשת המים בין packaged ל-unpackaged.

6.2 האם יש שירות, מנהל התקן, או shell extension

שלושת אלה מכבידים בבת אחת על שיטת ההפצה.

• driver: לא מתאים ל-MSIX
• in-process shell extension: לא מתאים ל-MSIX
• Windows service: MSI טבעי, גם MSIX מועמד בתנאים

ככל שיש יותר מרכיבים שקשורים עמוק ל-OS, במקום הפצה שנראית פשוטה, הנושא המרכזי הופך להיות האם אפשר להתקין, לעדכן ולהסיר כראוי.

6.3 per-user או per-machine

אם ממשיכים בעמימות בנקודה הזו, בהכרח יהיה עימות בהמשך.

• רוצים לנטות ל-per-user
  • ClickOnce
  • xcopy
  • חלק מ-MSIX
• רוצים לנטות ל-per-machine
  • MSI
  • MSIX אם התנאים מתאימים

‘רוצים להתקין בלי הרשאות מנהל’ ו-‘רוצים שכל המשתמשים ישתמשו מאותו מקום’ אינם אותו דבר.

flowchart TB
    accTitle: לא מבלבלים בין per-user ל-per-machine
    accDescr: תרשים המראה שאם רוצים לנטות ל-per-user, המועמדים הם ClickOnce, xcopy, וחלק מ-MSIX, ואם רוצים לנטות ל-per-machine, המועמדים הם MSI או MSIX אם התנאים מתאימים, ושהתקנה בלי הרשאות מנהל ומקום משותף לכל המשתמשים הם שני דברים שונים.
    k1["רוצים לנטות ל-per-user"] --> k2["ClickOnce / xcopy / חלק מ-MSIX"]
    k3["רוצים לנטות ל-per-machine"] --> k4["MSI / MSIX אם התנאים מתאימים"]
    k1 -.-> k5["התקנה בלי הרשאות ומקום משותף - שני דברים שונים"]

איור 12: אם ממשיכים בעמימות בהיקף ההתקנה, בהכרח יהיה עימות בהמשך.

6.4 תדירות עדכון ואחריות תפעולית

אם מסתכלים לפי תחושת תדירות העדכון, זה בגסות כך.

• עדכון רבעוני עד חודשי: גם MSI מסתדרת מספיק
• עדכון חודשי עד שבועי: MSIX‏/ClickOnce נוחים למדי
• עדכון שבועי עד יומי: יש סיבה לשקול עדכון עצמי
• עדכון ידני מספיק / הצד שמפיץ שולט: גם xcopy מספיקה

שיטת ההפצה היא גם בחירה טכנולוגית וגם תכנון תפעולי.

flowchart TB
    accTitle: מדרגות תדירות העדכון
    accDescr: תרשים המראה שבעדכון רבעוני עד חודשי גם MSI מספיקה, בעדכון חודשי עד שבועי MSIX או ClickOnce נוחים למדי, בעדכון שבועי עד יומי יש סיבה לשקול עדכון עצמי, ואם מספיק עדכון ידני גם xcopy מספיקה.
    m1["רבעוני עד חודשי: גם MSI מספיקה"] --> m2["חודשי עד שבועי: MSIX / ClickOnce נוחים"]
    m2 --> m3["שבועי עד יומי: יש סיבה לשקול עדכון עצמי"]
    m1 -.-> m4["אם מספיק ידני - גם xcopy מספיקה"]

איור 13: ככל שתדירות העדכון עולה, ערך העדכון ה-built-in והתשתית העצמית גדל.

6.5 הפצה ברשת סגורה/offline

ברשת סגורה, לרוב הפשטות מנצחת auto-update נקי.

• xcopy חזקה
• גם MSI חזקה
• גם ClickOnce אפשר להשתמש בה עם file share או removable media
• גם MSIX יכולה להסתדר, בהתאם לאופן השימוש ב-App Installer

עם זאת, אם מעדכנים תכופות ברשת סגורה, אם לא מחליטים גם ‘מי, לאן, מניח את הגרסה החדשה, ואיך משאירים את הגרסה הישנה’, התפעול נוטה להתמוטט גם אם בוחרים שיטה.

flowchart TB
    accTitle: ברשת סגורה הפשטות מנצחת
    accDescr: תרשים המראה שברשת סגורה לרוב הפשטות מנצחת auto-update נקי, xcopy ו-MSI חזקות, ושאם מעדכנים תכופות יש להחליט גם מי ולאן מניח את הגרסה החדשה, ואיך משאירים את הגרסה הישנה - אחרת התפעול נוטה להתמוטט.
    n1["סביבת רשת סגורה/offline"] --> n2["פשטות מנצחת auto-update נקי"]
    n2 --> n3["xcopy או MSI חזקות"]
    n2 -.-> n4["מחליטים מי ולאן מניחים גרסה חדשה"]
    n4 -.-> n5["מחליטים גם איך משאירים גרסה ישנה"]

איור 14: ברשת סגורה, לפני בחירת השיטה, מחליטים על תפעול הנחת הגרסה החדשה והישנה.

7. שש השאלות האחרונות כשמתלבטים

1. האם מספיק current user ליישום הזה, או שצריך להתקין machine-wide
2. האם יש service/driver/shell extension/רישום COM
3. האם משתמשים בפונקציית Windows שדורשת package identity
4. האם רוצים להתקין רק עם משתמש סטנדרטי
5. האם תדירות העדכון חודשית, שבועית, או גבוהה יותר
6. האם סביבת היעד סגורה, והאם גרסת ה-OS אחידה

רק מלענות על שש השאלות האלה, נקודת הנחיתה מתבררת בערך.

• אם 2 היא ‘כן’ ← חושבים קודם מצד MSI
• אם 3 היא ‘כן’ ← בודקים MSIX בעדיפות
• אם 1 היא current user,‏ 4 היא ‘כן’, ומדובר ב-.NET desktop app ← ClickOnce מובילה
• אם 4 היא ‘כן’, 2 היא ‘לא’, ומספיק תפעול של הנחה בלבד ← xcopy מובילה
• אם 5 גבוהה, ורוצים לאחוז ב-UX העדכון כערך מוצרי ← מכניסים עדכון עצמי להשוואה

flowchart TB
    accTitle: נקודת הנחיתה משש השאלות
    accDescr: תרשים המראה שאם יש אינטגרציה עם ה-OS כמו שירות, חושבים קודם מצד MSI, אם דרוש package identity בודקים MSIX בעדיפות, אם current user עם התקנה במשתמש סטנדרטי ויישום שולחני .NET אז ClickOnce, אם מספיק תפעול של הנחה בלבד אז xcopy, ואם תדירות העדכון גבוהה ורוצים לאחוז ב-UX העדכון מכניסים עדכון עצמי להשוואה.
    p1{"האם יש אינטגרציה עם ה-OS（שירות וכו'）"} -->|"כן"| p2["חושבים קודם מצד MSI"]
    p1 -->|"לא"| p3{"האם דרוש package identity"}
    p3 -->|"כן"| p4["בודקים MSIX בעדיפות"]
    p3 -->|"לא"| p5{"per-user + התקנה במשתמש סטנדרטי"}
    p5 -->|"אם יישום שולחני .NET"| p6["ClickOnce מובילה"]
    p5 -->|"אם מספיק תפעול הנחה בלבד"| p7["xcopy מובילה"]
    p6 -.-> p8["אם רוצים לאחוז ב-UX העדכון - גם עדכון עצמי בהשוואה"]

איור 15: אם עוקבים אחר תשובות שש השאלות בסדר הזה, נקודת הנחיתה מתבררת בערך.

8. סיכום

אפשר לרכז את שיטת ההפצה של יישום Windows במידה רבה למשפט הבא.

איך מממשים את ההתקנה הראשונית ו- מי אחראי להריץ את העדכון המתמשך - מחליטים בנפרד.

מעל לזה, ההחלטה המעשית הגסה היא כך.

• MSI: יישום שולחני מסורתי שנכנס עמוק ב-OS
• MSIX: יישום שרוצה package identity ו-modern packaging‏/update
• ClickOnce: רוצים להפיץ ולעדכן בקלות יישום עסקי של‏ .NET ב-per-user
• xcopy: כלי עצמאי שמספיק להניח
• עדכון עצמי: מוצר שמוכן לתכנן ולתפעל בעצמו את העדכון עצמו

והחשוב ביותר הוא זה.

• אם יש driver/shell extension/service, שיטת ההפצה נקבעת לא מהמראה החיצוני, אלא משיטת האינטגרציה עם ה-OS
• אם דרוש package identity, המשמעות של MSIX גדולה
• עדכון עצמי הוא הקלף האחרון, לא האפשרות הראשונה
• ב-רשת סגורה, לרוב הפשטות מנצחת את החוכמה

אם עדיין מתלבטים, אם מקבעים מראש רק את שלושת אלה - per-user או per-machine, מה רושמים ל-OS, ו-מה תדירות העדכון - השיחה מתקדמת משמעותית.

flowchart TB
    accTitle: שלושה דברים לקבע מראש
    accDescr: תרשים המראה שאם מתלבטים, קיבוע מראש של שלושה דברים בלבד - per-user או per-machine, מה רושמים ל-OS, ומה תדירות העדכון - מקדם משמעותית את השיחה על שיטת ההפצה.
    q1["per-user או per-machine"] --> q4["מקבעים מראש"]
    q2["מה רושמים ל-OS"] --> q4
    q3["מה תדירות העדכון"] --> q4
    q4 --> q5["השיחה מתקדמת משמעותית"]

איור 16: כשמתלבטים בשיטה, מקבעים מראש לפחות את שלוש הנקודות האלה.

מקורות

• Microsoft Learn, Windows Installer
• Microsoft Learn, What is MSIX?
• Microsoft Learn, Packaging overview for Windows apps
• Microsoft Learn, MSIX features and supported platforms
• Microsoft Learn, Support legacy context menus for packaged apps
• Microsoft Learn, App Installer file overview
• Microsoft Learn, Prepare to package a desktop application
• Microsoft Learn, Know your installer
• Microsoft Learn, Convert an installer that includes services
• Microsoft Learn, ClickOnce deployment and security
• Microsoft Learn, Manage updates for a ClickOnce application
• Microsoft Learn, Choosing a ClickOnce deployment strategy
• Microsoft Learn, ClickOnce cache overview
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה ההבדל בין MSI ל-MSIX?

MSI היא צורת המתקין המסורתית של Windows, ומתאימה היטב להתקנה שנוגעת עמוק ב-OS - כמו התקנה per-machine, שירות Windows, רישום COM, או shell extension - ומאפשרת לבטא install‏/uninstall‏/repair בסגנון של Windows.‏ MSIX הוא modern packaging שמניח Windows 10/11, ויתרונותיו הם clean install‏/clean uninstall, עדכונים תכופים, ו-package identity. מצד שני,‏ MSIX אינו מתאים למנהלי התקן,‏ in-process shell extension נתמך בתנאים מ-Windows 11 21H2 ואילך, וגם לא מתאים להנחות Win32 ישנות ו-unrestricted. אם הרישום ל-OS צפוף, נקודת המוצא היא MSI; אם רוצים package identity ועדכון נקי, נקודת המוצא היא MSIX.

האם לבחור ב-MSIX או ב-ClickOnce?

אם רוצים להפיץ בקלות ולעדכן אוטומטית יישום עסקי-פנימי של‏ .NET ב-per-user,‏ ClickOnce עדיין בחירה חזקה למדי. מודל העדכון ה-built-in נוח לשימוש, ההתקנה אפשרית עם משתמש סטנדרטי, ואין צורך לבנות UX עדכון בעצמכם. מצד שני, אם רוצים להשתמש בפונקציות Windows שדורשות package identity, לשים דגש על clean install‏/uninstall, או להתאים ל-Intune או App Installer,‏ MSIX הוא האפשרות המובילה. שניהם לא מתאימים למוצרים שנוגעים עמוק ב-OS, ולכן אם יש שירות או מנהל התקן, כדאי לחשוב מצד MSI.

האם עדיין אפשר להשתמש ב-ClickOnce? האם זו לא טכנולוגיה ישנה?

אפשר להשתמש בו גם עכשיו, והוא בחירה חזקה למדי בתרחישים שמתאימים לו. הוא יעיל כשרוצים להפיץ במהירות יישום שולחני פנים-ארגוני של‏ .NET, ביחידת המשתמש (per-user), עם הרשאות משתמש סטנדרטי, ולהפעיל באמצעות מודל העדכון ה-built-in. מצד שני, בטוח יותר לא לצפות ממנו תפקיד של מתקין שאוסף כמה תנאים מוקדמים, או מוצר שנוגע עמוק ב-OS כמו שירות Windows, מנהל התקן, או shell extension. מבחינת תדירות העדכון, בעדכון של חודשי עד שבועי,‏ ClickOnce או MSIX יכולים להסתובב די בקלות.

מתי כדאי לשקול מנגנון עדכון עצמי (updater)?

עדכון עצמי (updater) אינו הדבר שבוחרים בו ראשון, אלא נבחר בנוסף כשיש דרישת עדכון שלא מכוסה בשיטת ההפצה הקיימת. כדאי לשקול אותו כשיש דרישות כמו תדירות עדכון גבוהה, רצון להחזיק ערוצים כמו stable‏/beta‏/preview, שליטה בהפצה מדורגת ובאחוז rollout, או רצון לעקוב באופן עצמאי אחר telemetry של עדכונים והתאוששות מקריסה. עם זאת, מכיוון שלוקחים על עצמכם אחריות לתכנן ולתפעל בעצמכם אימות חתימה,‏ manifest להפצה, ניסיון חוזר,‏ rollback, התאוששות מעדכון פגום, ואפילו עדכון של ה-updater עצמו, כדאי לחשוב על זה כבחירה שמגדילה אחריות ולא חופש.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.