איך בוחרים שיטת הפצה לאפליקציית Windows: MSI, MSIX, ClickOnce, xcopy ו-updater עצמאי

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

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

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

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

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

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

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

1. קודם המסקנה

בגסות, אבל בצורה שאפשר לעבוד איתה:

• אם מכניסים לכל המכונה, יש שירות או רישום COM, או מתקינים prerequisites — מתחילים מ-MSI
• אם מניחים Windows 10/11 ורוצים clean install / clean uninstall, עדכונים תכופים, ו-package identity — MSIX הוא מועמד חזק
• אם רוצים להפיץ בקלות אפליקציית שולחן עבודה פנימית ב-.NET, per-user, עם עדכון אוטומטי — ClickOnce עדיין חזק
• אם העדיפות היא כלי שרץ אחרי ששמים אותו, רשת סגורה, USB, בלי הרשאות admin — 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; נכונות להחזיק תשתית עדכון מובילה ל-updater עצמאי.
    b1{"רישום עמוק ב-OS?"} -->|"כן"| b2["לכיוון MSI"]
    b1 -->|"לא"| b3{"רוצים package identity?"}
    b3 -->|"כן"| b4["MSIX"]
    b3 -->|"לא"| b5{"הפצה קלה per-user עם עדכון אוטומטי?"}
    b5 -->|"כן"| b6["ClickOnce"]
    b5 -->|"לשים ולרוץ בעדיפות"| b7["xcopy"]
    b7 -.-> b8["אם מוכנים להחזיק תשתית עדכון, updater עצמאי"]

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

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

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

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

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

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

1. גיליון קלט: ממלאים 7 פריטים ואפשר לרשום מועמד ראשון ונימוק
   • היקף הפצה: 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: ממלאים 7 פריטים בגיליון Planner, מצמצמים לפי הבחנה בין מועמדים וזרימת החלטה, ורושמים מועמד ראשון ונימוק; גיליון Reference הוא הטבלאות מפרקים 3 ו-4.
    c1["ממלאים 7 פריטים בגיליון הקלט"] --> c2["מצמצמים לפי הבחנה בין מועמדים"]
    c2 --> c3["דוחפים לשיטה לפי זרימת ההחלטה"]
    c3 --> c4["רושמים מועמד ראשון ונימוק"]
    c4 -.-> c5["Reference הוא הטבלאות מפרקים 3 ו-4"]

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

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 17, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. חמש השיטות לא באותה זירה

זה חשוב מאוד.

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

בפועל קל יותר לחשוב על זה בשתי שכבות.

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

flowchart TB
    APP["אפליקציית Windows שרוצים להפיץ"] --> Q1["קודם: איך מכניסים<br/>שכבת התקנה ראשונה"]
    APP --> Q2["אחר כך: מי נושא באחריות העדכון<br/>שכבת עדכון שוטף"]

    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 צריך להחליט על השכבה התחתונה בנפרד. שאלת “איך מעדכנים” נשארת באוויר בעיקר כשבוחרים את שתי אלה.

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

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

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

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

קודם הטבלה הכי שימושית.

מה שחשוב בטבלה: עצם זה שיש עדכון לא אומר לקפוץ ל-updater עצמאי.

4. השוואה לפי זווית

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

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

5.1 MSI

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

היא מתאימה במיוחד למקרים כאלה.

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

החוזק של MSI הוא שקל לבטא בסגנון של Windows איך האפליקציה נכנסה ל-OS.

גם החולשות ברורות.

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

flowchart TB
    accTitle: החוזק והמחיר של MSI
    accDescr: MSI קלה בביטוי איך האפליקציה נכנסה ל-OS בסגנון של Windows, אבל 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 אפשר לרשום למשל legacy context menu handler, אבל צריך לבדוק הצהרת manifest ו-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 עדיין חזק כשרוצים אפליקציית שולחן עבודה פנימית ב-.NET, per-user, מהר, כולל עדכון.

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

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

להפך, בטוח יותר לא לצפות ממנו מוצר שנוגע עמוק ב-OS, או תפקיד installer שאוסף כמה prerequisites.

5.4 xcopy

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

הוא זורח בכלים כאלה.

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

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

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

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

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

• Start menu / ARP / repair
• file association / service / Shell extension / driver
• עדכון built-in

5.5 updater עצמאי

updater עצמאי הוא פחות בחירת חופש ויותר בחירת אחריות.

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

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

החוזק גדול, וגם המחיר גדול.

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

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

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

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

5.6 אחרי שהשיטה נקבעה, מה בודקים אחר כך

גם אחרי “הולכים על MSI” אפשר להיתקע אם לא ברור מה לחפש. הנה נקודות כניסה טיפוסיות. אף אחת מהן היא לא “תשתמשו בזה”; אלה שמות שכדאי להכיר אחרי שבחרתם שיטה.

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

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

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

6. נקודות שמסתבכים בהן

6.1 האם צריך package identity

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

ולהפך, אם רוצים

• גישת קבצים unrestricted
• גישת Registry unrestricted
• חופש ב-elevation / במודל תהליכים
• להשאיר הנחות Win32 ישנות כמו שהן

אז שיטה לכיוון unpackaged טבעית יותר.

flowchart TB
    accTitle: מפרידים לפי הצורך ב-package identity
    accDescr: אם רוצים יכולת Windows שמניחה package identity, הערך של MSIX קופץ; אם רוצים גישה unrestricted לקבצים ול-Registry או להשאיר הנחות Win32 ישנות, שיטה לכיוון unpackaged טבעית יותר.
    j1{"רוצים יכולת שמניחה package identity?"} -->|"כן"| j2["הערך של MSIX קופץ"]
    j1 -->|"רוצים לרוץ unrestricted"| 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 אם התנאים מתאימים

“להתקין בלי הרשאות admin” ו”שכל המשתמשים ישתמשו מאותו מקום” הם לא אותו דבר.

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 נהיים הרבה יותר קלים
• עדכון שבועי עד יומי: מופיע נימוק לשקול updater עצמאי
• עדכון ידני / הצד שמציב שולט: גם xcopy מספיק

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

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

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

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

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

• xcopy חזק
• גם MSI חזק
• גם ClickOnce עובד מ-file share או מדיה נשלפת
• גם MSIX יכול לרוץ לפי איך משתמשים ב-App Installer

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

flowchart TB
    accTitle: ברשת סגורה פשטות מנצחת
    accDescr: ברשת סגורה פשטות מנצחת לעיתים קרובות auto-update מלוטש; אם מעדכנים תכוף, בלי לקבוע מי שם גרסה חדשה לאן ואיך משאירים גרסה ישנה, בחירת שיטה לבדה מתפרקת בתפעול.
    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 → ClickOnce חזק
• 4 הוא “כן”, 2 הוא “לא”, ותפעול של לשים ולרוץ מספיק → xcopy חזק
• 5 גבוה, ורוצים להחזיק UX עדכון כערך מוצר → מכניסים updater עצמאי להשוואה

flowchart TB
    accTitle: לאן מגיעים משש השאלות
    accDescr: אם יש אינטגרציה ל-OS כמו שירות, קודם MSI; אם צריך package identity, בודקים MSIX בעדיפות; אפליקציית שולחן עבודה ב-.NET per-user כמשתמש רגיל דוחפת ל-ClickOnce; תפעול של לשים ולרוץ דוחף ל-xcopy; אם רוצים להחזיק UX עדכון, משווים גם updater עצמאי.
    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 עדכון, משווים גם updater עצמאי"]

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

8. סיכום

שיטת הפצה לאפליקציית Windows מתכנסת די טוב למשפט הזה.

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

משם, ההחלטה המעשית הגסה היא:

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

ומה שחשוב ביותר:

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

אם מסתבכים, גם אם מקבעים קודם רק שלושה דברים (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: כשמסתבכים בשיטה, מקבעים לפחות את שלושת אלה קודם.

9. מקורות

• 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 היא צורת ה-installer המסורתית של 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. מצד שני, בטוח יותר לא לצפות ממנו תפקיד של installer שאוסף כמה prerequisites, או מוצר שנוגע עמוק ב-OS כמו שירות Windows, מנהל התקן או Shell extension. מבחינת תדירות עדכון, בעדכון חודשי עד שבועי ClickOnce או MSIX יכולים לרוץ די בקלות.

מתי שווה לשקול updater עצמאי?

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

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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