בחר במנהל החבילות של NuGet הנכון והגדר אותו יחד עם IIS

בנית אפליקציה או אף סט של סקריפטים חשובים ואת/ה צריך/ה לארוז אותו ולהעלות אותו. אל תחפש/י רחוק יותר מ-NuGet ומסוגי המנהלים של NuGet השונים שיש לך זמינים.

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

קשור: התקנת שרת NuGet ב-Windows (מדריך מלא)

התקנת Wrapper של NuGet.Server

בעוד שהתקנת שרת NuGet.Server מהתחלה אינה מאוד מעורבת, זה עשוי לקחת זמן למישהו חדש ל-Visual Studio ול-IIS. אחד הדרכים להאיץ את תהליך ההתקנה והעדכון הוא באמצעות Wrapper. אחד ה-Wrapper הפופולריים ביותר, בשם nuget-server, נכתב על ידי svenkle וניתן למצוא אותו בדף ה-Github שלהם.

אחת ההבדלים העיקריים בשימוש ב-Wrapper הזה במקום התקנת השרת באופן ידני הוא שהוא משתמש ב-IIS Express. ניתן לקרוא עוד על ההבדלים באתר של מיקרוסופט.

ישנם שני הבדלים חשובים בין התקנת שרת NuGet.Server רגיל לבין עם ה-Wrapper הזה:

• עליך ליצור שירות Windows כדי להתחיל את השרת האינטרנט
• אינך יכול/ה להשתמש ב-IIS Manager להגדרה

החסרון הראשי בשימוש בעטיפה להתקנת NuGet.Server הוא שאין ניתן לעדכן בקלות את הגרסה עד שהעטיפה עצמה מתעדכנת.

דרישות מוקדמות

אם ברצונך ללמוד איך להגדיר את עטיפת NuGet.Server זו, עליך לוודא שיש לך את התקנים הבאים:

• מתקין עבור עטיפת NuGet.Server של svenkle
• שרת Windows – כל גרסה תומכת נוכחית של שרת Windows יעבוד, אך כל התמונות הוזקקו על שרת Windows 2019 Standard

התקנת שירות שרת האינטרנט

השלב הראשון הוא ליצור שירות Windows חדש. מכיוון שעטיפת NuGet.Server זו לא משתמשת ב-IIS, אין אפשרות להפעיל על IIS.

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

New-Service -Name NuGetServer -BinaryPathName '<UnzipPath>\Svenkle.NuGetServer.Service.exe' -StartupType Automatic
Start-Service -Name NuGetServer

התאמה אישית של שרת האינטרנט

עכשיו שהותקן ה-NuGet.Server מהמעטפת והשירות נוצר והופעל, זמן להתאים אישית את קובץ ה-web.config. תוכל לבצע את אותן השינויים שתעשה לקובץ ה-web.config באינסטלציה ידנית אם תרצה.

קובץ ה-web.config ממוקם בתיקיית <UnzipPath>\Host\Website. ההבדל העיקרי באינסטלציה זו הוא שהיא משתמשת בפורט 8080 במקום פורט HTTP ברירת המחדל 80. זה אומר שבכל מקום שבו היית משתמש ב-URL של האתר, עליך להוסיף את :8080, כמו לדוגמה בעת העברת הדף האינטרנטי יהיה http://localhost:8080/nuget.

הכל עבר. זה היה הרבה יותר פשוט משימוש ב-Visual Studio!

הגדרת BaGet על IIS

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

בוא נראה מה נדרש כדי להתקין ולהפעיל את BaGet על שרת Windows עם IIS.

דרישות מוקדמות

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

• BaGet.zip – בזמן כתיבת הטקסט זה, הפרויקט עדיין בשלב פרה-ריליס ואני משתמש בגרסה v0.1.77
• .NET Core Runtime & Hosting Bundle – עליך להוריד ולהפעיל את זה בשרת האינטרנט למעשה.
• שרת Windows – כל גרסה נתמכת כעת של שרת Windows תפעל, אך כל הלכודות צולמו על Windows Server 2019 Standard.

התקנת דרישות השרת האינטרנט

בעוד השלבים למטה יכולים להתבצע על לינוקס עם .NET Core או בדוקר, הוראות אלו ייעשו בכדי להתקין BaGet על שרת Windows. בכך תוכל להשתמש ב-IIS כדי להתחיל ולעצור את השרת שלך.

התקנת IIS

מכיוון ש-BaGet רץ על .NET Core, אין כמה דרישות כמו ה-NuGet.Server הבסיסי שהתקנת IIS עבורו לפני כן. אתה צריך רק שרת אינטרנט IIS ברירת מחדל ואת מנהל ה-IIS. כדי להתקין את אלו, פתח סשן PowerShell בשרת האינטרנט שלך והרץ:

Install-WindowsFeature Web-Server -IncludeManagementTools

התקנת .NET Core

לאחר מכן, התקן את אוסף ה.NET Core בשרת האינטרנט. כדי לעשות זאת, הרץ את קובץ ה-exe שהורדת לפני כן. תוכל להשאיר את כל האפשרויות כברירת מחדל עבור ההתקנה הזו.

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

עכשיו שיש לך את רכיבי שרת האינטרנט מוכנים, פתח את קובץ ה- BaGet.zip שהורדת לפני כן והנח אותו בתיקיית C:\inetpub\wwwroot בשרת האינטרנט שלך.

הגדרת אפליקציית השרת האינטרנט

עבור דומה ל- NuGet.Server, יהיה עליך להגדיר כמה רכיבים של IIS כדי להפעיל את מנהל החבילות של NuGet, BaGet.

יצירת בריכת האפליקציות של BaGet ב-IIS

פתח IIS Manager בשרת האינטרנט ועבור ל-Application Pools. צור בריכת אפליקציות חדשה עבור BaGet מאחר והיא לא תשתמש בקוד ניהול .NET. תוכל לתת לה שם לפי רצונך. למטה תוכל לראות כיצד זה צריך להיראות.

יצירת האתר של BaGet

לאחר שהבריכת אפליקציות נוצרה, יש ליצור אתר. מכיוון ש-BaGet משתמשת בפורט HTTP שאינו סטנדרטי ובבריכת אפליקציות שאינה ברירת המחדל, הכי נוח ליצור אתר נפרד מה-Default Web Site. כדי לעשות זאת, לחץ ימינה על התיקיה של Sites ב-IIS manager ובחר Add Website.

למטה תוכל למצוא את ההגדרות שצריך להגדיר עבור BaGet.

לאחר שהאתר מוגדר, הוא צריך להתחיל אוטומטית. תוכל לבדוק אותו על ידי גישה ל-http://localhost:5000/ מהשרת שלך.

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

התאמת השרת האינטרנט של BaGet

שים לב שהיית מסוגל להתאים אישית את השרת NuGet.Server שלך באמצעות קובץ web.config. אך מנהל החבילות NuGet של BaGet אינו משתמש בקובץ web.config. במקום זאת, מאחר ש-BaGet יכולה להימלט גם ב-Linux, המפתחים בחרו בפורמט יותר חוצה פלטפורמות עם קובץ JSON בשם appsettings.json. הוא ממוקם בתיקיית C:\inetpub\wwwroot\BaGet.

שים לב שמאחר ו-BaGet משתמשת ב-.NET Core לפונקציונליות חוצת פלטפורמות, כל הנתיבים משתמשים בקווים נטויים קדימה.

לדוגמה, אם תרצה להגדיר את נתיב החבילות שלך ב-C:\Packages על השרת שלך, תצטרך להכניס את המידע הבא לקובץ appsettings.json.

"Storage": {
    "Type": "FileSystem",
    "Path": "C://Packages"
}

מפתח API של BaGet

כדי להגן על שרת NuGet שלך ממשתמשים לא מורשים שמעלים או מוחקים חבילה, עדיין תרצה להגדיר מפתח API. הגדרת מפתח ה-API גם היא ממוקמת בקובץ appsettings.json, כך שתוכל להגדיר אותה בעת שהנך שם.

מאחר ואני משתמש ב-PowerShell כדי לנהל את החבילות שלי ב-NuGet, אני יכול שוב לרשום PSRepository. עבור BaGet, נווט לדף האינטרנט שיצרת. הדף יתן לך את הפקודה להרצה בסשן הפוורשל שלך. לדוגמה:

Register-PSRepository -Name "BaGet" -SourceLocation "http://<WebServer>:5000/v3/index.json" -PublishLocation "http://<WebServer>:5000/api/v2/package" -InstallationPolicy "Trusted"

הבנת הסנכרון של BaGet (LiGet)

בעוד ש-BaGet מספקת הרבה אפשרויות לשימוש, ישנם שלטונות נוספים של BaGet שנוצרו כדי להתמחות בתחומים אחרים של NuGet. אחד השלטונות הפופולריים ביותר הוא LiGet. LiGet שונה בגלל שהוא מתמקד בנקודת מבט של Linux תחילה.

LiGet הוא מנהל חבילות NuGet המפוצל מהפרויקט המקורי עבור BaGet. קיוו המפתחים כמה סיבות לעשות זאת, אך בעיקר התוכנן זאת כדי להתמקד בכמה מאפיינים מסוימים של NuGet כולל תמיכה בזרם v3. תמיכה בזרם v3 אינה משפיעה על מקרה השימוש עם PowerShell. אך אם אתה מתכנן לארח שרת NuGet למקרים שימוש אחרים, עשוי להיות לך הנאה מהפונקציונליות הנוספת.

מפתח ה- API מוצפן של LiGet

ההבדל המרכזי בין LiGet ל-BaGet הוא השימוש במפתח API המוצפן במקום הטקסט הפשוט. עם מפתח בטקסט פשוט, מישהו שיש לו גישה לקובץ web.config על NuGet.Server או ל- appsettings.json על BaGet יכול לפרסם לשרת. זה לא יכול לקרות עם LiGet.

כדי להפעיל את LiGet, יהיה עליך ליצור מפתח API מוצפן ולשים אותו בקובץ appsettings.json בתיקיית C:\inetpub\wwwroot\LiGet.

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

([System.Security.Cryptography.HashAlgorithm]::Create('SHA256').ComputeHash([System.Text.Encoding]::UTF8.GetBytes(<apikey>)) | 
Foreach-Object { $_.ToString('x2')}) -join ''

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

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

התקנת ProGet על IIS

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

דרישות מוקדמות

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

• שרת Windows – כל גרסת שרת Windows נתמכת כרגע תעבוד, אך כל הליפים נלקחו ב-Windows Server 2019 Standard
• מתקין ProGet – הגרסה של ProGet שאני משתמש בה היא 5.2.9.
• התקנת SQL – זה אופציונלי מאחר ו-ProGet מציע אפשרות להתקין SQL Express מתוך המתקין, אם כי זה מחייב חיבור אינטרנט מהשרת שלך כדי לבצע את ההורדה הראשונית

התקנת ProGet

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

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

אם תשאירו את האפשרות SQL Server כ-התקנת מופע Inedo הוא יתקין עבורכם שרת SQL Express.

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

הגדרת PSRepository ב-ProGet

בשלב זה, ProGet מותקן. זה די פשוט. מאחר שאנו משתמשים ב-PowerShell לעבוד עם חבילות NuGet, נצטרך להגדיר PSRepository כפי שעשינו קודם.

כדי להגדיר את ProGet ל-PSRepository, נווטו אל הכרטיסיה Feeds וצרו הזנה חדשה. תוכלו לתת להזנה כל שם שתרצו. לאחר מכן בחרו פורמט חבילה של צד שלישי ו-PowerShell כפי שמוצג למטה.

לאחר שיצרתם את ההזנה, חזרו אל הכרטיסיה Feeds, בחרו בהזנה החדשה שלכם והיא תציג את ה-URL שמשמש לפרסום. זה מה שתצטרכו להריץ ב-PowerShell על מכשיר כדי לפרסם לו או להוריד ממנו ל-PSRepository שלכם.

להלן מה שהוצג עם הדוגמה מלמעלה:

Register-PSRepository -Name ProGet -SourceLocation http://<WebServer>:8624/nuget/PSRepository/ -PublishLocation http://<WebServer>:8624/nuget/PSRepository/ -InstallationPolicy Trusted

הוספת מפתח API

כמו האפשרויות האחרות, אתם צריכים ליצור מפתח API. כדי לעשות זאת, לחצו על סמל הגלגל שיניים בפינה הימנית העליונה ולאחר מכן בחרו מפתחות API</di

במסך מפתחות API, לחץ על צור מפתח API. מכאן, סמן את התיק מפתח API ולחץ על שמור מפתח API.

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

חיפוש בחבילות ב-ProGet

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

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

עדכון של ProGet

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

כדי לעדכן את ProGet לגרסה החדשה ביותר, פשוט פתח את מתקין Inedo בשרת האינטרנט שלך. המתקין התקן בעת התקנת ProGet הראשונית שלך. לחץ על שדרוג וכמו שמוצג למטה, המתקין יעשה את יתר העבודה עבורך.

השוואת מנהלי חבילות NuGet

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

BaGet vs. LiGet

מאחר ו־LiGet הוא סנכרון של BaGet, יש להם המון דמיונים, כולל רוב תהליכי ההתקנה. למעשה, ניתן לעקוב אחר אותו הליך התקנה כמו BaGet.

פעם שהתקינת אותם, LiGet ו־BaGet משתפים חלק מהתכונות, אך שונים בדרכים רבות אחרות.

בעוד שרוב ההבדלים האלו אינם משפיעים על שימוש עם PowerShell, התקנתם משתנה מעט עקב השימוש במפתח API מוצפן.

שנייהם, BaGet ו־LiGet, מבוססים על .NET Core שהופכת אותם ליכולים לרוץ על מגוון רחב של מערכות הפעלה, כולל Linux וכמובן גם Windows. לשניים יש תמונות Docker זמינות שאם כבר תשתמש בשירות תפריט, יכולות להקטין את זמן ההתקנה ולשדרג את הניידות.

עם ההבדלים המעטים בין LiGet ל־BaGet, שניהם הם אפשרות נהדרת לשרת NuGet קוד פתוח, ידידותי לתוך תכולת קונטיינר, שמאפשרת להתחיל בשירות NuGet על Windows ולהעביר את עצמך ל־Linux או דמות Docker בעתיד בלעדי יותר עבודה.

BaGet נגד ProGet

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

ישנם מספר הבדלים גדולים בין ProGet ל־BaGet.

גם Inedo מציעה פירוט לכל ההבדלים בין הגרסאות של ProGet.

סיכום

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

למדת על איך להתקין כל כלי NuGet כדי שיעבוד עם Windows וכיסינו הרבה מהתכונות של כל אחד.