كيفية التمهيد وإنشاء مشاريع .NET

إنشاء مشروع .NET

يعد إنشاء مشروع .NET من البداية أمرًا بسيطًا مثل استخدام معالج Visual Studio. انتقل إلى File => New Project ، أو Add New Project إلى حل موجود. بمجرد إنشاء مشروع جديد ، يمكنك البدء في الترميز على الفور. ومع ذلك ، فإن إعدادات المشروع الافتراضية التي تنتجها المعالجات غير مقبولة للفرق المحترفة ، لأنهم يضعون مستوى منخفضًا جدًا على الجودة. علاوة على ذلك ، لا يمكن لأي معالجات معرفة خطوات الإعداد الأخرى التي تحتاج إلى تنفيذها في بيئة التطوير الخاصة بك.

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

هيكل

يعد وجود هيكل محدد جيدًا أمرًا حيويًا للمشاريع المعقدة. يؤدي ذلك إلى تحسين تجربة الالتحاق بالعمل عند انضمام الوافدين الجدد إلى فريق ، ويجعل حياتك أسهل عندما تدعم المشاريع القديمة. هناك نوعان من المؤشرات الرئيسية للهيكل الجيد:

• استخدام مجلدات الحلول والمشاريع
• تسمية متسقة

المجلدات

تعد مجلدات الحلول ، التي يشار إليها أحيانًا بالمجلدات الافتراضية ، أداة مفيدة جدًا لتجميع مشروعاتك. في طريقة عرض مستكشف الحلول ، انقر بزر الماوس الأيمن وحدد Add => New Solution Folder ، ثم اسحب أي من المشاريع الحالية وأفلتها في هذا المجلد الجديد. لا يتم عكس هذه المجلدات في نظام الملفات ، مما يسمح لك بالحفاظ على الهيكل المادي دون تغيير ، لذا فإن نقل المشاريع من مجلد حلول إلى آخر لا يؤدي إلى نقلها فعليًا.

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

يمكن أن يعمل Visual Studio مع حلول متعددة في نفس الوقت من خلال الاستفادة من الحلول الفردية المقسمة أو نماذج الحلول المتعددة . نادرًا ما يتم استخدامها ، لذلك لن أغطيها في هذه المقالة.

بخلاف مجلدات الحل ، تطابق مجلدات المشروع بنية المجلدات الفعلية ، وبالتالي فهي تظل مجلدات حقيقية على القرص. علاوة على ذلك ، يجب أن تتطابق مجلدات المشروع التي تحتوي على رمز C # مع مساحة اسم المشروع. هذا يجعل التنقل طبيعيًا جدًا. يمكنك أيضًا تمكين قاعدة ReSharper للتحذير من حالات عدم التطابق هذه.

تسمية

هناك عدد قليل من القواعد الموصى بها لتطبيقها فيما يتعلق بالتسمية:

• استخدم CamelCase.
• يجب أن يتطابق اسم المشروع مع اسم تجميع الإخراج الخاص به.
• يجب أن يحتوي المشروع الذي يحتوي على اختبارات آلية على اللاحقة .Tests .
• يجب أن تحتوي جميع أسماء المشاريع على بادئة مشتركة ، مثل Company.Product .

هناك القليل من القواعد المعقولة كذلك. يجب أن تقرر بنفسك متى تقوم بتطبيقها بناءً على الفطرة السليمة (وقواعد اللغة الإنجليزية بالطبع):

• استخدم الموضوعات بصيغة الجمع عندما تحتوي حاوية (مشروع أو مجلد) على مثيلات متعددة من نفس النوع (مثل Tests أو System.Collections ).
• استخدم صيغة المفرد عندما تحتوي الحاوية بأكملها على رمز يتعلق بكيان واحد (مثل System.Collections.ObjectModel`).
• للاختصارات القصيرة ، استخدم الأحرف الكبيرة مثل System.IO .
• للاختصارات الطويلة ، استخدم CamelCase مثل Modules.Forex. .

قاعدة عامة: يجب ألا يزيد الاختصار القصير عن ثلاثة أحرف.

تكوين الحل

يعد تكوين الحل أمرًا بسيطًا مثل توفير جميع ملفات البنية الأساسية التي تحتاجها لبيئتك. على الرغم من أنه يمكن إضافة بعضها لاحقًا (مثل ملفات تكامل CI) ، فمن الأفضل أن يكون لديك القليل من الملفات في البداية.

إعدادات ReSharper

إذا كنت مطور .NET محترفًا ، فمن المحتمل جدًا أن تستخدم ReSharper. ReSharper مرن للغاية في إدارة إعداداته. بصفتك قائد فريق ، يمكنك إنشاء وتوزيع إعدادات Team Shared التي سيتم استخدامها من قبل المطورين الآخرين. يتم تخزين الإعدادات المشتركة للفريق في ملف بامتداد .DotSettings . سيختار ReSharper هذه الإعدادات تلقائيًا إذا كان اسم الملف يطابق اسم حل Visual Studio:

 MyCompany.MyProduct.sln MyCompany.MyProduct.sln.DotSettings

لذلك ، يجب عليك إنشاء هذا الملف في البداية إذا كنت تريد في النهاية تطبيق بعض الإعدادات على الفريق بأكمله. من الأمثلة الجيدة على ذلك قاعدة استخدام (أو عدم استخدام) var keyword. يمكن أن يحتوي ملف إعدادات Team Shared في قاعدة واحدة فقط ، بينما يفضل المطورون قاعدة أخرى. من الجدير بالذكر أنه بنفس الطريقة التي يمكن بها ضبط إعدادات ReSharper على مستوى كل مشروع ، لأنه قد يكون لديك بعض التعليمات البرمجية القديمة التي لا يمكنك تعديلها (مثل التغيير لاستخدام var keyword).

إذا قمت بتسمية هذا الملف بشكل صحيح ، كما هو موضح في المثال ، فإن أي مثيل جديد لبرنامج Visual Studio مع إعداد ReSharper جديد سيختار هذا الملف تلقائيًا ويفرض القواعد. لا تنسى إلزام هذا الملف بالتحكم بالمصادر.

قواعد StyleCop

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

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

ملفات نصية

إذا كنت تقوم ببناء منتج عام وستنشر الكود المصدري ، فلا تنس إنشاء هذه الملفات والتزامها أيضًا:

 README.md LICENSE

أوصي باستخدام تنسيق markdown لملف README.md ، لأنه أصبح معيارًا صناعيًا ومدعومًا بخدمات التحكم في المصادر العامة مثل GitHub ، بالإضافة إلى الخوادم الداخلية مثل BitBucket (Stash سابقًا).

مواصفات NuGet

إذا كنت تقوم ببناء مكتبة سيتم توزيعها في معرض NuGet ، فأنت على الأرجح بحاجة إلى إنشاء ملفات مواصفات الحزمة ، مثل MyProject.nuspec . أفضل إنشاء هذه الملفات يدويًا وإلزامها بالتحكم بالمصادر. عادةً ما يتم إصدار الحزم بواسطة إحدى مهام التكامل المستمر (CI اختصارًا) ، ولكن أيضًا في أي وقت يمكنك إنشاء حزمة ونشرها يدويًا من وحدة التحكم على النحو التالي:

 nuget.exe pack MyLibrary.nuspec

فقط لا تنس زيادة إصدار الحزمة قبل تنفيذ هذا الأمر.

ملفات محددة CI

نستخدم جميعًا خوادم CI مختلفة ، ولديهم جميعًا برامج نصية وإعدادات تكوين مختلفة. أود أن أذكر فقط بعض الإضافات الشائعة التي قد تفكر في إضافتها:

• إعدادات NUnit ، والتي تحدد التجميعات التي تحتوي على اختبارات يتم تنفيذها على خادم CI لوظائف معينة. يتم تقسيم جميع الاختبارات عمليا إلى فئات قليلة. هناك اختبارات وحدة يجب إجراؤها على كل إصدار ، واختبارات أداء يتم إجراؤها ليلاً ، ويتم تنفيذ اختبارات التكامل على أساس كل إصدار.
• إعدادات NCover ، التي تحدد تجميعات الاختبار التي يجب تحليلها لتغطية الاختبار.
• سيتم جمع إعدادات SonarQube ، التي تحدد مقاييس البرنامج.
• نصوص المهام ، مثل NAnt أو PowerShell أو ملفات Windows الدفعية ببساطة.

تكوين المشاريع

تحتوي ملفات المشروع ، مثل .csproj أو .vbpro ، على جميع الإعدادات المستخدمة بواسطة Visual Studio و MSBuild. ومع ذلك ، لا تتوفر جميعها من نافذة خصائص المشروع. لتحرير هذه الملفات في Visual Studio يدويًا ، يجب عليك القيام بما يلي:

• انقر بزر الماوس الأيمن فوق مشروع في طريقة عرض "مستكشف الحلول".
• حدد Unload Project .
• انقر بزر الماوس الأيمن مرة أخرى لاختيار الإجراء تحرير xyz.csproj .
• التحرير الكامل.
• انقر بزر الماوس الأيمن فوق المشروع مرة أخرى ، واختر إعادة تحميل المشروع .

بدلاً من ذلك ، يمكنك فتح ملف مشروع في محرر النصوص المفضل لديك وتعديله وحفظه. عندما تعود إلى نافذة Visual Studio ، سيُطلب منك إعادة تحميل المشروع الذي تم تغييره.

التحكم في التحذيرات

يتطلب إنشاء برنامج عالي الجودة ألا تتجاهل تحذيرات الإنشاء مطلقًا. لذلك ، يجب تمكين الحد الأقصى لمستوى التحذيرات والتعامل مع أي تحذيرات على أنها أخطاء. لاحظ أنه يجب عليك القيام بذلك لجميع تكوينات البناء لديك ، مثل Debug و Release. أفضل طريقة للقيام بذلك هي كتابة الإعدادات التالية إلى مجموعة الخصائص العامة:

 <WarningLevel>4</WarningLevel> <TreatWarningsAsErrors>true</TreatWarningsAsErrors>

وتأكد من عدم وجود نفس الإعدادات في مجموعات الخصائص الأخرى. وإلا ، فسيتم تجاوز الخصائص المقابلة من المجموعة المشتركة.

FxCop

يعد تشغيل FxCop عمليًا فقط في كل بناء. تفضل معظم الفرق تشغيل FxCop من وقت لآخر (عادة قبل الإصدار) للتأكد من عدم وجود أخطاء جسيمة. ومع ذلك ، إذا كنت تريد إجراء فحص نهائي لكل بنية ، فأضف هذا الخيار:

 <RunCodeAnalysis>true</RunCodeAnalysis>

لاحظ أن FxCop ، مثل StyleCop ، له إعداداته الخاصة التي يمكن وضعها في المجلد الجذر وإضافتها إلى التحكم في المصدر. من المحتمل استخدام هذه الإعدادات عند تشغيل FxCop على خوادم CI.

توثيق

هذا الجزء عن XmlDoc. إذا كنت تقوم ببناء واجهة برمجة تطبيقات عامة ، فيجب عليك إنشاء وثائق API والحفاظ عليها. يبدأ معظم المطورين بتطوير واجهة برمجة التطبيقات (الترميز الفعلي) ، وقبل الإصدار مباشرة يقومون بتمكين إعداد المشروع Build / XML documentation file . بطبيعة الحال ، بعد عملية إعادة بناء أخرى ، تظهر مجموعة من الأخطاء ، لأن كل XmlDoc مفقود ينتج عنه خطأ في البناء. لتجنب ذلك ، يجب تمكين الخيار المذكور في البداية.

إذا كنت كسولًا جدًا بحيث لا تستطيع كتابة وثائق مناسبة ، أو لا تحب كتابة الكثير من النصوص ، فجرب الأدوات التي تعمل على أتمتة هذه العملية مثل GhostDoc.

عقود الكود

تعد Code Contracts إطارًا ممتازًا من Microsoft Research ، والذي يسمح لك بالتعبير عن الشروط المسبقة والظروف اللاحقة وثوابت الكائن في التعليمات البرمجية الخاصة بك لفحص وقت التشغيل والتحليل الثابت والتوثيق. لقد استخدمت هذا في العديد من المشاريع الهامة ، وقد ساعدني كثيرًا لذا أشجعك على تجربته.

إذا قررت استخدام Code Contracts ، فمن المهم تمكين العقود في البداية ، عندما تكون قد أنشأت للتو مشروعًا جديدًا. من الممكن إضافة العقود في منتصف التطوير ، ولكنها ستتطلب تغييرات من خلال العديد من الفئات ، لجعل جهات الاتصال متطابقة مع بعضها البعض. لذلك ، لا تنس تمكين جميع الإعدادات المطلوبة (على الأقل CodeContractsEnableRuntimeChecking ) وتأكد من ظهور هذه الإعدادات في مجموعة الملكية المشتركة.

StyleCop إنفاذ

تحدثنا سابقًا عن تكوين StyleCop لوقت التطوير. ومع ذلك ، عندما يكون مشروعك مبنيًا على خادم CI ، فلن يكون لـ ReSharper أي تأثير هناك ، وبالتالي يجب علينا تمكين التحقق من صحة StyleCop للتشغيل مع MSBuild.

يتم ذلك عادة عن طريق التعديل اليدوي لملف المشروع. تحتاج إلى تفريغ المشروع في Visual Studio وتحرير ملف المشروع ثم إعادة تحميل المشروع:

 <PropertyGroup> <!— add this to the common property group (common to Debug/Release/etc) —> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </PropertyGroup> <!— add this Import in the very bottom —> <Import Project="$(ProgramFiles)\MSBuild\Microsoft\StyleCop\v4.3\Microsoft.StyleCop.targets">

سيفعل إعداد StyleCopTreatErrorsAsWarnings ما يقوله: سوف يكسر التصميم الخاص بك على أي انتهاك لقاعدة StyleCop. عنصر الاستيراد مطلوب من أجل MSBuild لإضافة مهمة StyleCop إلى سلسلة البناء.

ربما لاحظت المسار إلى Program Files . نظرًا لأن المطورين قد يكون لديهم إصدارات مختلفة من StyleCop مثبتة ، تفضل بعض الفرق الاحتفاظ بنسخة خاصة من تثبيت StyleCop نفسه تحت تحكم المصدر. في هذه الحالة ، سيكون المسار نسبيًا. هذا أيضًا يجعل إعداد أجهزة CI أسهل ، حيث لا تحتاج إلى تثبيت StyleCop محليًا.

معلومات التجميع

سيحتوي كل مشروع .NET تم إنشاؤه بواسطة معالج Visual Studio على ملف AssemblyInfo.cs يتم ملؤه تلقائيًا (انظر المجلد الفرعي للخصائص ) والذي يحتوي على بعض سمات Assembly ، ولكن لا يمكن لأي معالج ملء جميع سمات Assembly نيابة عنك. تأكد من أن لديك على الأقل هذه السمات مأهولة:

• AssemblyTitle
• AssemblyDescription
• AssemblyCompany
• AssemblyProduct
• AssemblyCopyright
• AssemblyVersion

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

يمكنك أيضًا ملء خاصية أخرى في البداية:

 InternalsVisibleTo

تجعل هذه الخاصية الفئات والواجهات الداخلية مرئية للتجميع المحدد. يستخدم هذا بشكل عام للاختبارات الآلية التي ستقوم بإنشائها لمشروعك.

سلاسل الاتصال

كيفية إدارة سلاسل الاتصال هو سؤال شائع جدًا في Stack Overflow. تكمن المشكلة في كيفية جعل سلاسل الاتصال فريدة لكل مطور أو وظيفة CI ، وعدم كشف تفاصيل الاتصال أثناء نشر كود المصدر.

في App.config (لتطبيقات سطح المكتب) أو Web.config (لتطبيقات الويب) ، حدد الإعداد التالي الذي سيتم تحميل ملف user.config في وقت التشغيل. احتفظ بهذا تحت تحكم المصدر الخاص بك:

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <connectionStrings configSource="user.config"></connectionStrings> </configuration>

على ما يبدو ، يجب استبعاد ملف user.config من التحكم بالمصادر ، ويجب أن يمتلك كل مطور نسخة محلية من هذا الملف ، مع الحفاظ على خصوصية سلسلة الاتصال:

 <connectionStrings> <add name="test" connectionString="Server=.;Database=...;"/> </connectionStrings>

.gitignore

بالنسبة لأولئك الذين يستخدمون Git كعنصر تحكم بالمصادر ، من المهم إضافة بعض أنماط الملفات إلى ملف .gitignore . ومع ذلك ، فقد قام مجتمعنا الذكي بالفعل ببناء ملف معمم يمكن العثور عليه هنا: github.com/github/gitignore/blob/master/VisualStudio.gitignore.

يجب أن تأخذها كملف مرجعي .gitignore وأن تضيف ببساطة الاستبعادات المخصصة التي قد تحتاجها أيضًا.

شارات GitHub

ربما تكون قد شاهدت شارات جميلة المظهر تظهر على صفحة مشروع README . إذا كنت تنشر مشروعك على GitHub ، ففكر في توصيل مشروعك بالخدمات العامة من أجل:

• المبنى: لإظهار فشل بناء أو مروره.
• الاختبار: لإظهار تغطية الاختبار وحالة تنفيذ الاختبار.
• النشر: لإظهار أحدث إصدار من حزمة NuGet.

يمكن العثور على قائمة كاملة بالشارات والخدمات ذات الصلة على shields.io. قد تجد العديد من الشارات الممتعة المفيدة لمشاريع مفتوحة المصدر.

بمجرد تسجيل مشروعك في خدمة محددة ، سيتم إعطاؤك رابطًا للصورة ورابط تعليمي كامل ، يمكنك إضافته إلى ملف README.md الخاص بك. بالمناسبة ، هذا هو أحد الأسباب التي تجعلك تفضل تخفيض السعر لملفات المستند التمهيدي .

عينة شارات تخفيض السعر من مشروع روزلين:

[![Build Status]([http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/badge/icon)](http://dotnet-ci.cloudapp.net/job/roslyn_master_win_dbg_unit32/)) [![Join the chat at [https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)](https://gitter.im/dotnet/roslyn](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/dotnet/roslyn?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge))

التحقق التلقائي من بنية الحل

على الرغم من أنك قمت بتعيين جميع الإعدادات التي ناقشناها في هذه المقالة ، فقد يقوم أحد مطوريك عاجلاً أم آجلاً بتغييرها وتنفيذ التغييرات في التحكم بالمصادر. يحدث هذا أحيانًا عن طريق الخطأ ، وغالبًا لا يتم اكتشاف هذه التغييرات أثناء مراجعة الكود. بخلاف هذه الحوادث ، يجب أن نراقب الأخطاء الشائعة التالية:

• مراجع سيئة : عندما يشير شخص ما إلى تجميع محلي ربما لا يمتلكه الآخرون ، أو عندما يقوم شخص ما بحذف ملف من القرص ، بينما يظل الرابط إلى هذا الملف في ملف .csproj . سيؤدي هذا إلى كسر البنية بالتأكيد ، ولكن قد يحدث بعد فوات الأوان بمجرد دفع التغيير ، وسحبه الآخرون. هذا مهم بشكل خاص لملفات الويب الثابتة ، والتي لا يمكنك التحقق منها أثناء الإنشاء.
• تناسق التسمية : يمكن لأدوات مثل StyleCop التحكم في التعليمات البرمجية المصدر لـ C # ، ولكن لا توجد أدوات يمكنها فرض قواعد لملفات المشروع أو خصائص التجميع. وخير مثال على ذلك: نريد تسمية المشاريع لتتطابق مع اسم تجميع المخرجات ، ونريد أن يكون لأسماء المشاريع بادئة مشتركة مثل MyCompany.MyProduct .

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

 Install-Package SolutionInspector

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

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

هذا مثال على ملف التكوين:

 <?xml version="1.0" encoding="utf-8"?> <Settings xmlns:xsi="[http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">](http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">) <SolutionSettings> <MinSolutionFormatVersion>12.00</MinSolutionFormatVersion> <MaxSolutionFormatVersion>12.00</MaxSolutionFormatVersion> <DetectMissingFiles>true</DetectMissingFiles> <ProjectNamePrefix>MyCompany.MyProduct.</ProjectNamePrefix> <ProjectNameIsFileName>true</ProjectNameIsFileName> <IgnoredProjects> AVerySpecialProject1; AVerySpecialProject2; </IgnoredProjects> </SolutionSettings> <ProjectSettings> <DetectMissingFiles>true</DetectMissingFiles> <AllowBuildEvents>true</AllowBuildEvents> <AssemblyNameIsProjectName>true</AssemblyNameIsProjectName> <RootNamespaceIsAssemblyName>true</RootNamespaceIsAssemblyName> <RequiredImports>StyleCop.MSBuild.Targets</RequiredImports> <Properties> <TreatWarningsAsErrors>true</TreatWarningsAsErrors> <StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings> </Properties> </ProjectSettings> </Settings>

على الرغم من أن الإعدادات وصفية إلى حد ما ، إلا أنني سأشرح بعضًا منها:

• MinSolutionFormatVersion / MaxSolutionFormatVersion المطورين من تبديل إصدار Visual Studio.
• DetectMissingFiles مفيدة جدًا لمحتوى الويب الثابت أو الملفات غير البرمجية الأخرى المضافة إلى الحل أو المشروع.
• يمكن أن يمنع AllowBuildEvents من إضافة أحداث بناء مخصصة ، والتي قد تفعل أشياء غير ضرورية.
• Properties هي العنصر الأكثر مرونة: يمكنك التحقق من أي خصائص مقابل القيم المطلوبة ، سواء كانت تلك خصائص معروفة أو مخصصة.

خاتمة

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