اختيار مدير حزم Nuget الصحيح وتكوينه مع IIS

لقد قمت ببناء تطبيق أو ربما مجموعة من البرامج النصية الهامة وتحتاج إلى تجميعها ونشرها. لا تبحث أكثر من NuGet ومجموعة مدير حزم NuGet المختلفة التي تتوفر لديك.

في هذه المقالة، ستتعلم كيفية إعداد مدير حزم NuGet المختلفة للمرة الأولى حتى تتمكن من استخدامها على الفور.

ذات الصلة: إعداد خادم NuGet على نظام Windows (دليل كامل)

إعداد NuGet.Server Wrapper

على الرغم من أن إعداد NuGet.Server من البداية ليس معقدًا جدًا، إلا أنه قد يستغرق وقتًا طويلاً بالنسبة لشخص جديد في Visual Studio و IIS. يمكن تسريع عملية الإعداد والتحديث باستخدام أداة Wrapper. إحدى الأدوات الأكثر شيوعًا، المسماة nuget-server، هي واحدة مكتوبة بواسطة svenkle ويمكن العثور عليها على صفحتهم في GitHub.

إحدى الاختلافات الرئيسية في استخدام هذه الأداة بدلاً من تثبيت الخادم الويب يدويًا هو استخدام IIS Express. يمكنك قراءة المزيد حول الاختلافات على موقع مايكروسوفت.

هناك اختلافان مهمان بين إعداد خادم NuGet.Server الأساسي واستخدام هذه الأداة هما:

• يجب إنشاء خدمة Windows لبدء الخادم الويب
• لا يمكنك استخدام مدير IIS للتكوين.

العيب الرئيسي في استخدام الجهاز اللفافة لتثبيت خادم NuGet هو أنه لا يمكنك تحديث الإصدار بسهولة حتى يتم تحديث الجهاز اللفافة.

المتطلبات الأساسية

إذا كنت ترغب في معرفة كيفية إعداد جهاز اللفافة هذا لخادم NuGet ، فسيتعين عليك التأكد أولاً من وجود ما يلي:

• مثبت لجهاز اللفافة NuGet الخاص بـ svenkle
• خادم Windows – ستعمل أي نسخة مدعومة حاليًا من إصدار خادم Windows ، ولكن تم التقاط جميع لقطات الشاشة على Windows Server 2019 Standard

تثبيت خدمة خادم الويب

الخطوة الأولى هي إنشاء خدمة جديدة في Windows. نظرًا لعدم استخدام هذا الجهاز اللفافة لـ IIS ، لا يمكنك الاستفادة من IIS.

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

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

تخصيص خادم الويب

الآن بعد تثبيت خادم NuGet من الجهاز الخارجي وإنشاء الخدمة وتشغيلها ، حان الوقت لتخصيص ملف web.config. يمكنك إجراء نفس التغييرات التي تقوم بها في ملف web.config عند النشر اليدوي إذا كنت ترغب في ذلك.

يوجد ملف web.config في مجلد <UnzipPath>\Host\Website. الفرق الرئيسي في هذا النشر هو استخدام منفذ 8080 بدلاً من منفذ HTTP الافتراضي 80. وهذا يعني أنك بحاجة إلى إضافة :8080 في أي مكان تستخدم فيه عنوان URL للويب ، على سبيل المثال عند الانتقال إلى صفحة الويب سيكون http://localhost:8080/nuget.

تم الانتهاء من كل شيء. كان ذلك أسهل بكثير من استخدام برنامج Visual Studio!

إعداد BaGet على IIS

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

لنرى ما الذي يلزم لتثبيت BaGet وتشغيله على خادم Windows مع IIS.

المتطلبات المسبقة

قبل أن تبدأ ، تأكد من استيفاء بعض المتطلبات المسبقة.

• BaGet.zip – في وقت كتابة هذا المشروع ما زال في مرحلة ما قبل الإصدار وأنا أستخدم v0.1.77
• .NET Core Runtime & Hosting Bundle – يجب تنزيله وتوفره على خادم الويب لاحقًا.
• خادم ويندوز – أي إصدار من إصدارات خادم ويندوز المدعومة حاليًا سيعمل، ولكن تم التقاط جميع لقطات الشاشة على Windows Server 2019 Standard

تثبيت متطلبات خادم الويب

في حين يمكن تشغيل الخطوات التالية على نظام لينكس مع .NET Core أو في صورة Docker ، إلا أن هذه التعليمات ستُستخدم لتثبيت BaGet على خادم ويندوز. بهذه الطريقة يمكنك الاستفادة من 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 باجيت.

إنشاء بركة تطبيق IIS الخاصة بـ باجيت

افتح مدير IIS على الخادم الويب وانتقل إلى برك التطبيق. قم بإنشاء بركة تطبيق جديدة لـ باجيت حيث لن يتم استخدام رمز إدارة .NET. يمكنك تسميته على ما تريد. فيما يلي كيفية ذلك.

إنشاء موقع باجيت

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

فيما يلي الإعدادات التي تحتاج إلى تكوينها لـ باجيت.

بمجرد تكوين الموقع ، يجب أن يبدأ تلقائيًا. يمكنك الاطلاع عليه عن طريق الانتقال إلى http://localhost:5000/ من الخادم الخاص بك.

ستلاحظ أن هناك واجهة مستخدم أكثر في صفحة ويب باجيت مقارنة بصفحة ويب NuGet.Server القياسية. في باجيت ، يمكنك البحث بسهولة عن الحزم التي تم تحميلها ويوفر أيضًا الأوامر حول كيفية التحميل بطرق مختلفة بدلاً من استخدام خيارات سطر الأوامر NuGet.

تخصيص خادم الويب باجيت

تذكر أنه يمكنك تخصيص خادم 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 ، قم بالانتقال إلى صفحة الويب التي قمت بإنشائها. ستعطيك الصفحة الأمر الذي يجب تشغيله في جلسة PowerShell الخاصة بك. على سبيل المثال:

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 لحالات استخدام أخرى، فقد تستمتع بالوظائف الإضافية.

مفتاح واجهة برمجة التطبيق المشفر لـ LiGet

الاختلاف الرئيسي بين LiGet و BaGet هو استخدام مفتاح واجهة برمجة التطبيق المشفر بدلاً من النص العادي. باستخدام مفتاح النص العادي، يمكن لشخص ما الذي لديه وصول إلى ملف web.config على خادم NuGet.Server أو appsettings.json على BaGet نشر الملفات على الخادم. وهذا لا يمكن أن يحدث مع LiGet.

لتشغيل LiGet، ستحتاج إلى إنشاء مفتاح واجهة برمجة التطبيق المشفر ووضعه في ملف 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 ''

يمكنك أيضًا استخدام مولد تجزئة عبر الإنترنت لإنشاء التجزئة.

عيب هذا النهج هو أنه إذا نسيت مفتاح واجهة برمجة التطبيق، يجب عليك إنشاء تجزئة جديدة واستبدالها لأن التجزئة ليست قابلة للعكس.

إعداد ProGet على IIS

تم تغطية جميع الخيارات التي تمت مناقشتها حتى الآن بشكل مجاني ولا تحتوي على العديد من الأجزاء المتحركة بمجرد إعدادها. على الرغم من أن هذا أمر جيد لتجربة NuGet ، إلا أنه إذا كنت ترغب في الاندماج مع أدوات أخرى أو إذا كنت تحتاج إلى دعم البائع لنظام في مكان العمل ، فقد يكون الخيار الأفضل هو إدارة حزم NuGet ProGet.

المتطلبات الأساسية

لإعداد ProGet ، ستحتاج إلى بعض المتطلبات الأساسية الشائعة التي ربما تكون معتادًا عليها حتى الآن ولكن مع إضافة قاعدة بيانات SQL اختيارية.

• خادم Windows – أي إصدار مدعوم حاليًا من نظام التشغيل Windows Server سيعمل ، ولكن تم التقاط جميع لقطات الشاشة على Windows Server 2019 Standard
• مثبت ProGet – إصدار ProGet الذي أستخدمه هو 5.2.9.
• SQL Instance – هذا اختياري لأن ProGet يحتوي على خيار لتثبيت SQL Express من المثبت ، على الرغم من أن هذا يتطلب اتصالًا بالإنترنت من الخادم الخاص بك للقيام بالتنزيل الأولي

تثبيت ProGet

قم بتشغيل مثبت ProGet من خادم الويب الخاص بك. نظرًا لأنك تقوم بإعداد IIS ، حدد الخيار IIS web server عند تثبيت 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 من شريط الأدوات الأيسر. هنا يمكنك رؤية المفاتيح الحالية ويمكنك إنشاء مفاتيح جديدة. سترى فورًا الفرق الرئيسي بين ProGet المفتوح المصدر و ProGet الشركي. مع ProGet، يمكنك الحصول على العديد من مفاتيح API.

على شاشة مفاتيح واجهة برمجة التطبيقات، انقر على إنشاء مفتاح واجهة برمجة التطبيقات. من هنا، قم بتحديد خانة Feed API وانقر على حفظ مفتاح واجهة برمجة التطبيقات.

بمجرد إنشاء مفتاح واجهة برمجة التطبيقات، سيعيدك إلى صفحة مفاتيح واجهة برمجة التطبيقات. من هنا، يمكنك استخدام المفتاح واجهة برمجة التطبيقات الذي تراه لنشر الحزم إلى تغذيتك.

البحث عن الحزم باستخدام ProGet

يشمل ProGet أيضًا صفحة ويب تسمح لك بالبحث في جميع حزم NuGet في التغذية، ومشاهدة عدد التنزيلات الخاصة بهم، واسم وحدات PowerShell، والتغذية التي تم تحميل الحزمة فيها، وإحصاءات الحزم المماثلة الأخرى من الصفحة الحزم كما هو موضح أدناه.

بدلاً من ذلك، يمكنك الانتقال إلى صفحة التغذيات وتحديد تغذية لرؤية فقط الحزم لتلك التغذية. يمكنك من هنا تحليل الحزم الفردية لرؤية الإحصاءات والتفاصيل الأخرى حول الحزم كما هو موضح أدناه.

تحديث ProGet

أحد الأشياء الجميلة في استخدام منتج موجه للشركات هو أن بعض المهام الإدارية الأكثر استهلاكًا للوقت تتم بشكل أسرع بكثير. مثال على ذلك هو تحديث ProGet.

لتحديث ProGet إلى أحدث إصدار، ما عليك سوى فتح مثبت Inedo على خادم الويب الخاص بك. تم تثبيت هذا عندما قمت بتثبيت ProGet لأول مرة. انقر على زر الترقية كما هو موضح أدناه، وسيقوم المثبت بالباقي بالنيابة عنك.

مقارنة أدوات إدارة حزم NuGet

لقد تعلمت الكثير عن مختلف أدوات NuGet في هذه المقالة. إذا كنت لا تزال تبحث عن الأداة المناسبة لتجربتها، في هذا القسم، ستحصل على نظرة سريعة على ما يميز كل واحدة منها عن الأخرى.

BaGet مقابل LiGet

نظرًا لأن LiGet هو فork من BaGet، فإنهما يشتركان في العديد من الشبهات، بما في ذلك معظم عملية الإعداد. في الواقع، يمكنك اتباع نفس إجراءات الإعداد تمامًا كما هو في BaGet.

بمجرد التثبيت، يشترك LiGet و BaGet في بعض الميزات ولكنهما يختلفان في طرق أخرى.

على الرغم من أن معظم هذه الاختلافات لا تؤثر على الاستخدام مع PowerShell، إلا أن إعداد النظام يتغير قليلاً بسبب استخدام مفتاح API المشفر.

كل من BaGet و LiGet مبنيتين على .NET Core مما يجعلهما قابلتين للتشغيل عبر الأنظمة العاملة لينكس وويندوز. كما أن لديهما صور Docker المتاحة التي يمكن أن تجعل عملية الإعداد أسرع وأكثر قابلية للنقل إذا كنت تستخدم بالفعل خدمة حاويات.

مع الاختلافات القليلة بين LiGet و BaGet، فإن أيًا منهما هو خيار رائع لخادم NuGet مفتوح المصدر ويدعم الحاويات. كلا الخيارين يسمحان ببدء استخدام خادم NuGet على ويندوز وفي الوقت نفسه يتيحان لك الانتقال إلى نظام لينكس أو صورة Docker في المستقبل بدون مجهود إضافي كبير.

BaGet مقابل ProGet

إذا كنت تفضل عدم إعداد النظام بنفسك وتفضل السهولة، يمكنك دائمًا استخدام ProGet. ومع ذلك، هناك بعض العيوب. فProGet ليس مفتوح المصدر وليس مجانيًا بأي حال من الأحوال. ولكنه أسهل في الإعداد والاستخدام.

هناك بعض الاختلافات الرئيسية بين ProGet و BaGet.

توجد أيضًا جميع اختلافات الميزات بين إصدارات ProGet.

الملخص

في هذه المقالة، تعلمت الكثير عن مجموعة متنوعة من أدوات وتقنيات NuGet. إذا كنت في حيرة بشأن أي خادم NuGet يجب استخدامه، يجب أن يكون لديك الآن المزيد من المعرفة لمساعدتك في اتخاذ تلك القرار.

تعلمت كيفية إعداد كل أداة NuGet للعمل مع نظام التشغيل Windows وتمت مراجعة العديد من الميزات لكل منها.