Δημιουργία έργου .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 είναι πολύ ευέλικτο στη διαχείριση των ρυθμίσεών του. Ως αρχηγός της ομάδας, μπορείτε να δημιουργήσετε και να διανείμετε Κοινή ομάδα ρυθμίσεις που θα χρησιμοποιηθούν από άλλους προγραμματιστές. Κοινή ομάδα οι ρυθμίσεις αποθηκεύονται σε ένα αρχείο με επέκταση .DotSettings. Το ReSharper θα επιλέξει αυτές τις ρυθμίσεις αυτόματα εάν το όνομα του αρχείου ταιριάζει με το όνομα λύσης του Visual Studio:

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

Επομένως, θα πρέπει να δημιουργήσετε αυτό το αρχείο στην αρχή εάν θέλετε τελικά να εφαρμόσετε ορισμένες ρυθμίσεις σε ολόκληρη την ομάδα. Ένα καλό παράδειγμα θα ήταν ο κανόνας χρήσης (ή μη χρήσης) var λέξη-κλειδί. Τα δικα σου Κοινή ομάδα Το αρχείο ρυθμίσεων μπορεί να έχει μόνο αυτόν τον κανόνα, ενώ άλλοι είναι η προτίμηση των προγραμματιστών. Αξίζει να σημειωθεί ότι με τον ίδιο τρόπο οι ρυθμίσεις ReSharper μπορούν να οριστούν σε επίπεδο ανά έργο, επειδή μπορεί να έχετε κάποιο κωδικό παλαιού τύπου που δεν μπορείτε να τροποποιήσετε (π.χ. αλλαγή στη χρήση var λέξη-κλειδί).

Εάν ονομάσατε αυτό το αρχείο σωστά, όπως φαίνεται στο παράδειγμα, τότε οποιαδήποτε νέα εμφάνιση του Visual Studio με μια νέα ρύθμιση ReSharper θα επιλέξει αυτό το αρχείο αυτόματα και θα επιβάλει τους κανόνες. Μην ξεχάσετε να δεσμεύσετε αυτό το αρχείο στον έλεγχο προέλευσης.

Κανόνες StyleCop

Όπως με τις ρυθμίσεις ReSharper, μπορείτε να μοιραστείτε τις ρυθμίσεις StyleCop. Εάν χρησιμοποιείτε το ReSharper, τότε πιθανότατα να έχετε εγκατεστημένο ένα plugin ενσωμάτωσης που θα αξιοποιεί το StyleCop από το ReSharper. Ωστόσο, το StyleCop αποθηκεύει τις ρυθμίσεις του ανεξάρτητα σε αρχεία με την ονομασία Settings.StyleCop. Ομοίως, μπορείτε να έχετε αυτό το αρχείο μαζί με το αρχείο λύσης και τα αρχεία έργου.

Εάν χρησιμοποιείτε StyleCop, μην ξεχάσετε να εκτελέσετε το εργαλείο διαμόρφωσης StyleCop και απενεργοποιήστε τους ελέγχους που δεν θέλετε να εκτελέσετε. Από προεπιλογή, όλοι οι έλεγχοι είναι ενεργοποιημένοι. Αποθηκεύστε νέες ρυθμίσεις σε αυτό το αρχείο και δεσμεύστε τον έλεγχο προέλευσης.

Αρχεία κειμένου

Εάν δημιουργείτε ένα δημόσιο προϊόν και πρόκειται να δημοσιεύσετε τον πηγαίο κώδικα, μην ξεχάσετε να δημιουργήσετε και να δεσμεύσετε αυτά τα αρχεία:

README.md LICENSE

Προτείνω να χρησιμοποιήσετε τη μορφή markdown για το README.md αρχείο, επειδή έγινε βιομηχανικό πρότυπο και υποστηρίζεται από δημόσιες υπηρεσίες ελέγχου πηγών όπως το GitHub, καθώς και εσωτερικούς διακομιστές όπως το BitBucket (πρώην Stash).

NuGet Προδιαγραφές

Εάν δημιουργείτε μια βιβλιοθήκη που πρόκειται να διανεμηθεί στο NuGet Gallery, τότε πιθανότατα θα πρέπει να δημιουργήσετε αρχεία προδιαγραφών πακέτων, όπως MyProject.nuspec. Προτιμώ να δημιουργώ αυτά τα αρχεία με μη αυτόματο τρόπο και να τα δεσμεύω στον έλεγχο προέλευσης. Τα πακέτα συνήθως εκδίδονται από μια από τις εργασίες συνεχούς ολοκλήρωσης (CI για σύντομο χρονικό διάστημα), αλλά και ανά πάσα στιγμή μπορείτε να δημιουργήσετε και να δημοσιεύσετε ένα πακέτο χειροκίνητα από την κονσόλα ως εξής:

nuget.exe pack MyLibrary.nuspec

Απλά μην ξεχάσετε να αυξήσετε την έκδοση του πακέτου πριν εκτελέσετε αυτήν την εντολή.

Ειδικά αρχεία CI

Όλοι χρησιμοποιούμε διαφορετικούς διακομιστές CI και όλοι έχουν διαφορετικά σενάρια διαμόρφωσης και ρυθμίσεις. Θα ήθελα απλώς να αναφέρω μερικές από τις κοινές προσθήκες που μπορείτε να προσθέσετε:

• NUnit ρυθμίσεις, οι οποίες καθορίζουν ποιες συγκροτήσεις περιέχουν δοκιμές που θα εκτελεστούν σε διακομιστή CI για συγκεκριμένες εργασίες. Όλες οι δοκιμές χωρίζονται πρακτικά σε μερικές κατηγορίες. Υπάρχουν δοκιμές μονάδας που πρέπει να εκτελείται σε κάθε έκδοση, δοκιμές απόδοσης που εκτελούνται κάθε βράδυ, και ενσωμάτωση οι δοκιμές εκτελούνται σε βάση ανά κυκλοφορία.
• NCover ρυθμίσεις, οι οποίες καθορίζουν ποια συγκροτήματα δοκιμών πρέπει να αναλυθούν για κάλυψη δοκιμών.
• SonarQube ρυθμίσεις, οι οποίες καθορίζουν τις μετρήσεις λογισμικού.
• Σενάρια εργασίας , όπως NAnt, PowerShell ή απλά αρχεία δέσμης Windows.

Ένα κατάλληλο πρόγραμμα εκκίνησης μειώνει το μελλοντικό τεχνικό χρέος και καθιστά τον πηγαίο κώδικα προϊόντος αναγνώσιμο και επαγγελματικό. Τιτίβισμα

Διαμόρφωση έργων

Αρχεία έργου, συγκεκριμένα .csproj ή .vbpro, περιέχουν όλες τις ρυθμίσεις που χρησιμοποιούνται από το Visual Studio και το MSBuild. Ωστόσο, δεν είναι όλα διαθέσιμα από το παράθυρο Project Properties. Για να επεξεργαστείτε αυτά τα αρχεία στο Visual Studio με μη αυτόματο τρόπο, πρέπει να κάνετε τα εξής:

• Κάντε δεξί κλικ σε ένα έργο σε προβολή Solution Explorer.
• Επιλέγω Εκφόρτωση έργου .
• Κάντε δεξί κλικ ξανά για να επιλέξετε ενέργεια Επεξεργασία xyz.csproj .
• Πλήρης επεξεργασία.
• Κάντε δεξί κλικ στο έργο ξανά και επιλέξτε Επαναφόρτωση έργου .

Εναλλακτικά, μπορείτε να ανοίξετε ένα αρχείο έργου στον αγαπημένο σας επεξεργαστή κειμένου, να το επεξεργαστείτε και να το αποθηκεύσετε. Όταν επιστρέφετε στο παράθυρο του Visual Studio, θα σας ζητηθεί να φορτώσετε ξανά το έργο που έχει αλλάξει.

Έλεγχος προειδοποιήσεων

Η δημιουργία λογισμικού υψηλής ποιότητας απαιτεί από εσάς να μην αγνοείτε ποτέ τις προειδοποιήσεις κατασκευής. Επομένως, πρέπει να ενεργοποιήσετε το μέγιστο επίπεδο προειδοποιήσεων και να αντιμετωπίζετε τυχόν προειδοποιήσεις ως σφάλματα. Λάβετε υπόψη ότι πρέπει να το κάνετε αυτό για όλες τις διαμορφώσεις build που έχετε, όπως το Debug και το Release. Ο καλύτερος τρόπος για να γίνει αυτό είναι να γράψετε τις ακόλουθες ρυθμίσεις στην κοινή ομάδα ιδιοτήτων:

4 true

Και βεβαιωθείτε ότι δεν έχετε τις ίδιες ρυθμίσεις σε άλλες ομάδες ιδιοτήτων. Διαφορετικά, θα παρακάμψουν τις αντίστοιχες ιδιότητες από την κοινή ομάδα.

FxCop

Η εκτέλεση του FxCop είναι απλώς πρακτική για κάθε κατασκευή. Οι περισσότερες ομάδες προτιμούν να τρέχουν το FxCop από καιρό σε καιρό (συνήθως πριν από την κυκλοφορία) για να βεβαιωθούν ότι δεν παρουσιάστηκαν σοβαρά σφάλματα. Ωστόσο, εάν θέλετε να κάνετε τον απόλυτο έλεγχο σε κάθε έκδοση, προσθέστε αυτήν την επιλογή:

true

Σημειώστε ότι το FxCop, όπως το StyleCop, έχει τις δικές του ρυθμίσεις οι οποίες μπορούν να τοποθετηθούν στον ριζικό φάκελο και να προστεθούν στον έλεγχο προέλευσης. Αυτές οι ρυθμίσεις χρησιμοποιούνται πιθανώς κατά την εκτέλεση του FxCop σε διακομιστές CI.

Τεκμηρίωση

Αυτό το μέρος αφορά το XmlDoc. Εάν δημιουργείτε ένα δημόσιο API, τότε θα πρέπει να δημιουργήσετε και να διατηρήσετε τεκμηρίωση API. Οι περισσότεροι προγραμματιστές ξεκινούν με την ανάπτυξη API (πραγματική κωδικοποίηση) και λίγο πριν από την κυκλοφορία ενεργοποιούν τη ρύθμιση του έργου Build / XML documentation file. Φυσικά, μετά από μια άλλη αναδημιουργία εμφανίζεται μια δέσμη σφαλμάτων, επειδή κάθε XmlDoc που λείπει οδηγεί σε σφάλμα κατασκευής. Για να το αποφύγετε αυτό, θα πρέπει να ενεργοποιήσετε την αναφερόμενη επιλογή από την αρχή.

Εάν είστε πολύ τεμπέλης για να γράψετε μια σωστή τεκμηρίωση ή δεν σας αρέσει να πληκτρολογείτε πάρα πολύ κείμενο, δοκιμάστε όργανα που αυτοματοποιούν αυτήν τη διαδικασία, όπως Ghostdoc .

Συμβάσεις κώδικα

Συμβάσεις κώδικα είναι ένα εξαιρετικό πλαίσιο της Microsoft Research, το οποίο σας επιτρέπει να εκφράσετε προϋποθέσεις, μετα-προϋποθέσεις και αναλλοίωτα αντικειμένων στον κώδικά σας για έλεγχο χρόνου εκτέλεσης, στατική ανάλυση και τεκμηρίωση. Το χρησιμοποίησα σε πολλά κρίσιμα έργα και βοήθησα πολύ, γι 'αυτό σας ενθαρρύνω να το δοκιμάσετε.

Εάν αποφασίσετε να χρησιμοποιήσετε συμβόλαια κώδικα, τότε είναι σημαντικό να ενεργοποιήσετε τις συμβάσεις από την αρχή, όταν μόλις δημιουργήσατε ένα νέο έργο. Η προσθήκη συμβολαίων στη μέση της ανάπτυξης είναι δυνατή, αλλά θα απαιτήσει αλλαγές μέσω πολλών τάξεων, ώστε οι επαφές να ταιριάζουν μεταξύ τους. Επομένως, μην ξεχάσετε να ενεργοποιήσετε όλες τις απαιτούμενες ρυθμίσεις (τουλάχιστον CodeContractsEnableRuntimeChecking) και βεβαιωθείτε ότι αυτές οι ρυθμίσεις εμφανίζονται στην κοινή ομάδα ιδιοτήτων.

Επιβολή StyleCop

Προηγουμένως μιλήσαμε για τη διαμόρφωση StyleCop για χρόνο ανάπτυξης. Ωστόσο, όταν το έργο σας είναι ενσωματωμένο σε διακομιστή CI, το ReSharper δεν έχει αποτέλεσμα εκεί και επομένως θα πρέπει να επιτρέψουμε την εκτέλεση της επικύρωσης StyleCop με το MSBuild.

Αυτό γίνεται συνήθως με χειροκίνητη τροποποίηση του αρχείου έργου. Πρέπει να ξεφορτώσετε το έργο στο Visual Studio, να επεξεργαστείτε το αρχείο έργου και, στη συνέχεια, να φορτώσετε ξανά το έργο:

false

Η ρύθμιση StyleCopTreatErrorsAsWarnings θα κάνει ό, τι λέει: θα σπάσει την οικοδόμησή σας σε οποιαδήποτε παραβίαση κανόνων StyleCop. Το στοιχείο εισαγωγής απαιτείται για το MSBuild να προσθέσει την εργασία StyleCop στην αλυσίδα build.

Μπορεί να έχετε παρατηρήσει τη διαδρομή προς 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 αρχείο στο χρόνο εκτέλεσης. Κρατήστε το υπό τον έλεγχο της πηγής σας:

user.config

Προφανώς, .gitignore το αρχείο πρέπει να εξαιρεθεί από τον έλεγχο προέλευσης και κάθε προγραμματιστής πρέπει να έχει ένα τοπικό αντίγραφο αυτού του αρχείου, διατηρώντας το απόρρητο της συμβολοσειράς σύνδεσης:

.gitignore

.gitignore

Για όσους χρησιμοποιούν το Git ως στοιχείο ελέγχου προέλευσης, είναι σημαντικό να προσθέσετε κάποια μοτίβα αρχείων στο README αρχείο. Ωστόσο, η έξυπνη κοινότητά μας έχει ήδη δημιουργήσει ένα γενικευμένο αρχείο, το οποίο μπορείτε να βρείτε εδώ: github.com/github/gitignore/blob/master/VisualStudio.gitignore .

Θα πρέπει να το λάβετε ως αναφορά README.md αρχειοθετήστε και προσθέστε απλώς τις εξατομικευμένες εξαιρέσεις σας που μπορεί επιπλέον να χρειαστείτε.

Διακριτικά GitHub

Μπορεί να έχετε δει ωραία σήματα να εμφανίζονται στο [![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)) σελίδα του έργου. Εάν δημοσιεύετε το έργο σας στο GitHub , εξετάστε το ενδεχόμενο να συνδέσετε το έργο σας σε δημόσιες υπηρεσίες για:

• Δημιουργία: για να δείξετε μια κατασκευή αποτυγχάνει ή περνά.
• Δοκιμή: για να δείτε την κάλυψη δοκιμής και την κατάσταση εκτέλεσης δοκιμής.
• Δημοσίευση: για να δείτε την τελευταία έκδοση του πακέτου NuGet.

Μπορείτε να βρείτε μια πλήρη λίστα με σήματα και σχετικές υπηρεσίες στη διεύθυνση ασπίδες .io . Μπορεί να βρείτε πολλά ενδιαφέροντα σήματα που είναι κατάλληλα για έργα ανοιχτού κώδικα.

Μόλις καταχωρήσετε το έργο σας σε μια επιλεγμένη υπηρεσία, θα σας δοθεί ένας σύνδεσμος για την εικόνα και ένας πλήρης σύνδεσμος markdown-syntax, τον οποίο μπορείτε να προσθέσετε στο .csproj αρχείο. Παρεμπιπτόντως, αυτός είναι ένας από τους λόγους για τους οποίους θα πρέπει να προτιμάτε το markdown Ρέτμε αρχεία.

Δείξτε σήματα markdown, από το έργο Roslyn:

MyCompany.MyProduct

Επικύρωση δομής αυτόματης λύσης

Ακόμα κι αν έχετε ορίσει όλες τις ρυθμίσεις που συζητήσαμε σε αυτό το άρθρο, αργά ή γρήγορα ένας από τους προγραμματιστές σας μπορεί να τις αλλάξει και να πραγματοποιήσει τις αλλαγές στο στοιχείο ελέγχου προέλευσης. Μερικές φορές αυτό συμβαίνει κατά λάθος και συχνά αυτές οι αλλαγές δεν εντοπίζονται κατά τον έλεγχο κώδικα. Εκτός από αυτά τα ατυχήματα, θα πρέπει να παρακολουθούμε τα ακόλουθα κοινά σφάλματα:

• Κακές αναφορές : όταν κάποιος αναφέρεται σε μια τοπική συνέλευση που άλλοι ίσως δεν έχουν, ή όταν κάποιος έχει διαγράψει ένα αρχείο από το δίσκο, ενώ ο σύνδεσμος προς αυτό το αρχείο παραμένει στο Install-Package SolutionInspector αρχείο. Αυτό θα σπάσει σίγουρα το build, αλλά μπορεί να συμβεί πολύ αργά μόλις προωθηθεί η αλλαγή και άλλοι την τράβηξαν. Αυτό είναι ιδιαίτερα σημαντικό για στατικά αρχεία ιστού, τα οποία δεν μπορείτε να επαληθεύσετε κατά τη διάρκεια της έκδοσης.
• Συνοχή ονομάτων : τα εργαλεία όπως το StyleCop μπορούν να ελέγχουν τον πηγαίο κώδικα C #, αλλά κανένα εργαλείο δεν μπορεί να επιβάλει κανόνες για αρχεία έργου ή ιδιότητες συναρμολόγησης. Ένα καλό παράδειγμα είναι αυτό: Θέλουμε να ονομάσουμε τα έργα ώστε να ταιριάζουν με το όνομα συναρμολόγησης εξόδου και θέλουμε τα ονόματα έργων να έχουν ένα κοινό πρόθεμα όπως ](http://www.w3.org/2001/XMLSchema-instance' xmlns:xsd='http://www.w3.org/2001/XMLSchema'>) 12.00 12.00 true MyCompany.MyProduct. true AVerySpecialProject1; AVerySpecialProject2; true true true true StyleCop.MSBuild.Targets true false .

Διαπίστωσα ότι η παρακολούθηση αυτών των σφαλμάτων στις Κριτικές κώδικα είναι επιρρεπής σε σφάλματα και πρέπει να είναι αυτοματοποιημένη. Έτσι έγραψα ένα απλό εργαλείο που εκτελεί αυτούς και πολλούς άλλους ελέγχους για να επαληθεύσω τη συνέπεια της λύσης. Συναντώ SolutionInspector . Αυτό είναι ανοιχτού κώδικα και διανέμεται με άδεια MIT. Μπορείτε να το δημιουργήσετε από τον πηγαίο κώδικα ή να το εγκαταστήσετε από το NuGet:

MinSolutionFormatVersion

Το εργαλείο ακολουθεί ολόκληρη τη δομή λύσεων και εφαρμόζει πολλούς κανόνες επικύρωσης. Οι κανόνες διαμορφώνονται από αρχεία XML, τοποθετούνται μαζί με άλλα αρχεία λύσεων. Για τον έλεγχο των ρυθμίσεων ανά έργο, απλά προσθέτετε το ίδιο αρχείο με διαφορετικές ρυθμίσεις στον αντίστοιχο φάκελο έργου.

Δεν απαιτείται αρχείο διαμόρφωσης από προεπιλογή. Σε αυτήν την περίπτωση, το εργαλείο θα εφαρμόσει όλους τους διαθέσιμους κανόνες και θα αποδώσει όλα τα ζητήματα στην κονσόλα.

Ακολουθεί το παράδειγμα του αρχείου διαμόρφωσης:

MaxSolutionFormatVersion

Αν και οι ρυθμίσεις είναι μάλλον περιγραφικές, θα εξηγήσω ορισμένες από αυτές:

• DetectMissingFiles / AllowBuildEvents θα εμποδίσει τους προγραμματιστές σας να αλλάξουν την έκδοση του Visual Studio.
• Properties είναι πολύ χρήσιμο για στατικό περιεχόμενο ιστού ή άλλα αρχεία εκτός κώδικα που προστίθενται στη λύση ή σε ένα έργο.

• |_+_|

  μπορεί να αποτρέψει την προσθήκη προσαρμοσμένων συμβάντων κατασκευής, τα οποία ενδέχεται να κάνουν περιττά πράγματα.

• |_+_|

  είναι το πιο ευέλικτο στοιχείο: μπορείτε να ελέγξετε τυχόν ιδιότητες σε σχέση με τις επιθυμητές τιμές, είτε αυτές είναι γνωστές ιδιότητες είτε προσαρμοσμένες.

συμπέρασμα

Έχουμε εξετάσει αρκετές τυπικές πρακτικές, αρχεία διαμόρφωσης και ρυθμίσεις έργου που μπορείτε να εφαρμόσετε κατά την έναρξη ενός νέου έργου. Κάτι τέτοιο στην αρχή θα μειώσει το μελλοντικό τεχνικό χρέος και θα κάνει τον πηγαίο κώδικα του προϊόντος σας να φαίνεται ωραίο και επαγγελματικό. Για έργα ανοιχτού κώδικα, αυτό είναι ιδιαίτερα σημαντικό, διότι οποιοσδήποτε συνεισφέρων θα γνώριζε τις προσδοκίες σας εξετάζοντας τις διαμορφώσεις λύσεων και τα αρχεία έργων.

Σχετίζεται με: .NET Core - Going Wild και Open Source. Microsoft, τι σε πήρε τόσο πολύ ;!