Creați un proiect .NET

Pentru a crea un proiect .NET de la zero este la fel de simplu ca și utilizarea expertului Visual Studio. Accesați File => New Project, sau Add New Project la o soluție existentă. Odată ce a fost creat un nou proiect, puteți începe codificarea imediat. Cu toate acestea, setările implicite ale proiectului produse de vrăjitori sunt greu de acceptat pentru echipele profesionale, deoarece stabilesc un nivel prea scăzut al calității. Mai mult, nici un vrăjitor nu poate ști despre alți pași de configurare pe care trebuie să îi efectuați în mediul dvs. de dezvoltare.

În acest articol, vă voi prezenta câteva setări importante pe care ar trebui să le activați imediat ce creați un proiect nou, ceea ce este important pentru a reduce la minimum o datorie tehnică viitoare. De asemenea, vom analiza câteva practici obișnuite Dezvoltatori .NET se aplică atunci când sunt structurate soluții și proiecte noi. Chiar dacă nu aplicați unele dintre aceste idei, este plăcut să învățați și să obțineți o imagine de ansamblu a ceea ce fac majoritatea echipelor.

Structura

A avea o structură bine definită este vital pentru proiectele complexe. Acest lucru îmbunătățește experiența de îmbarcare atunci când noii veniți se alătură unei echipe și vă ușurează viața atunci când susțineți proiecte vechi. Există doi indicatori cheie ai unei bune structuri:

• Utilizarea folderelor de soluții și proiecte
• Denumire consecventă

Dosare

Dosare de soluții , uneori denumit dosare virtuale , sunt un instrument foarte util pentru a vă grupa proiectele. În Solution Explorer vizualizați clic dreapta și selectați Add => New Solution Folder, apoi glisați și plasați oricare dintre proiectele existente în acest nou folder. Aceste foldere nu sunt reflectate în sistemul de fișiere, permițându-vă să păstrați structura fizică neschimbată, astfel încât mutarea proiectelor dintr-un folder de soluții în altul nu le mută fizic.

Nu este necesar să aveți prefixe numerotate, dar face ca folderele să apară ordonate chiar în Solution Explorer fereastră.

Visual Studio poate lucra cu mai multe soluții în același timp, utilizând pârghia Soluție unică partiționată sau Multisoluție modele. Sunt rareori folosite, așa că nu le voi acoperi în acest articol.

Spre deosebire de Dosare de soluții , Dosare proiect se potrivesc cu structura folderelor fizice și, prin urmare, persistă ca foldere reale pe disc. Mai mult, folderele de proiect care conțin un cod C # trebuie să se potrivească cu cele ale proiectului spațiu de nume . Acest lucru face ca navigarea să fie destul de naturală. Puteți chiar activa o regulă ReSharper pentru a avertiza asupra unor astfel de nepotriviri.

Denumire

Există câteva reguli recomandate de aplicat legate de denumire:

• Utilizare CamelCase .
• Un nume de proiect trebuie să se potrivească cu numele ansamblului de ieșire.
• Un proiect care conține teste automate ar trebui să aibă sufixul .Tests.
• Toate numele proiectelor ar trebui să aibă un prefix comun, cum ar fi Company.Product.

Există și câteva reguli rezonabile. Ar trebui să decideți singuri când să le aplicați pe baza bunului simț (și a gramaticii engleze, desigur):

• Utilizați subiecți în plural atunci când un container (proiect sau folder) conține mai multe instanțe de același tip (de ex. Tests Sau System.Collections).
• Utilizați forma singulară atunci când întregul container conține cod despre o singură entitate (de exemplu, System.Collections.ObjectModel`).
• Pentru abrevieri scurte, utilizați majuscule, cum ar fi System.IO face.
• Pentru abrevieri lungi, utilizați CamelCase ca Modules.Forex..

O regulă generală: o abreviere scurtă nu trebuie să depășească trei caractere.

Configurarea soluției

Configurarea unei soluții este la fel de simplă precum furnizarea tuturor fișierelor de infrastructură de care aveți nevoie pentru mediul dvs. Deși unele dintre ele pot fi adăugate ulterior (cum ar fi fișiere de integrare CI), puține fișiere pe care le-ați avea mai bine la început.

Setări ReSharper

Dacă sunteți dezvoltator profesionist .NET, atunci este foarte probabil să utilizați ReSharper. ReSharper este foarte flexibil în gestionarea setărilor sale. Ca lider de echipă, puteți crea și distribui Echipa partajată setări care vor fi utilizate de alți dezvoltatori. Echipa partajată setările sunt stocate într-un fișier cu extensie .DotSettings. ReSharper va alege automat aceste setări dacă numele fișierului se potrivește cu numele soluției Visual Studio:

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

Prin urmare, ar trebui să creați acest fișier chiar de la început dacă doriți în cele din urmă să aplicați unele setări întregii echipe. Un bun exemplu ar fi regula utilizării (sau neutilizării) var cuvânt cheie. Ta Echipa partajată fișierul de setări poate avea doar această regulă, în timp ce altele sunt preferința dezvoltatorilor. Merită menționat că în același mod setările ReSharper pot fi setate la un nivel pe proiect, deoarece este posibil să aveți un cod vechi pe care nu îl puteți modifica (de exemplu, schimbați pentru a utiliza var cuvânt cheie).

Dacă ați denumit corect acest fișier, așa cum se arată în exemplu, atunci orice nouă instanță a Visual Studio cu o nouă configurare ReSharper va alege automat acest fișier și va aplica regulile. Nu uitați să transferați acest fișier la controlul sursă.

Reguli StyleCop

La fel ca și setările ReSharper, puteți partaja setările StyleCop. Dacă utilizați ReSharper, probabil că aveți instalat un plugin de integrare care va folosi StyleCop de la ReSharper. Cu toate acestea, StyleCop își stochează setările independent în fișiere numite Settings.StyleCop. În mod similar, puteți avea acest fișier împreună cu fișierul soluției și fișierele de proiect.

Dacă utilizați StyleCop, nu uitați să rulați instrumentul de configurare StyleCop și să dezactivați verificările pe care nu doriți să le efectuați. În mod implicit, toate verificările sunt activate. Salvați setările noi în acest fișier și vă angajați în controlul sursă.

Fișiere text

Dacă construiți un produs public și urmează să publicați codul sursă, nu uitați să creați și să comiteți și aceste fișiere:

README.md LICENSE

Vă recomand să utilizați formatul de reducere pentru README.md fișier, deoarece a devenit un standard industrial și susținut de serviciile de control al sursei publice precum GitHub, precum și de servere interne precum BitBucket (fostul Stash).

Specificații NuGet

Dacă construiți o bibliotecă care urmează să fie distribuită în NuGet Gallery, atunci este foarte probabil să creați fișiere de specificații ale pachetelor, cum ar fi MyProject.nuspec. Prefer să creez aceste fișiere manual și să le trimit la controlul sursă. Pachetele sunt de obicei eliberate de una dintre lucrările dvs. de integrare continuă (CI pe scurt), dar și în orice moment puteți crea și publica manual un pachet de pe consolă după cum urmează:

nuget.exe pack MyLibrary.nuspec

Nu uitați să incrementați versiunea pachetului înainte de a executa această comandă.

Fișiere specifice CI

Cu toții folosim diferite servere CI și toți au scripturi și setări de configurare diferite. Aș menționa doar câteva dintre adăugările obișnuite pe care le puteți lua în considerare:

• NUnit setări, care specifică ce ansambluri conțin teste care trebuie executate pe serverul CI pentru anumite lucrări. Toate testele sunt practic împărțite în câteva categorii. Sunt teste unitare care ar trebui să ruleze la fiecare versiune, teste de performanță care sunt executate noaptea și integrare testele sunt executate pe bază de eliberare.
• NCover setări, care specifică ce ansambluri de testare ar trebui analizate pentru acoperirea testului.
• SonarQube vor fi colectate setările, care determină valorile software.
• Scripturi de locuri de muncă , cum ar fi NAnt, PowerShell sau pur și simplu fișiere batch Windows.

Un proiect bootstrappat în mod corespunzător scade datoria tehnică viitoare și face codul sursă al produsului lizibil și cu aspect profesional. Tweet

Configurarea proiectelor

Fișiere de proiect, și anume .csproj sau .vbpro, conțin toate setările utilizate de Visual Studio și MSBuild. Cu toate acestea, nu toate sunt disponibile din fereastra Proprietăți proiect. Pentru a edita manual aceste fișiere în Visual Studio, trebuie să faceți următoarele:

• Faceți clic dreapta pe un proiect în vizualizarea Solution Explorer.
• Selectați Descărcați proiectul .
• Faceți din nou clic dreapta pentru a alege acțiunea Editați xyz.csproj .
• Editarea completă.
• Faceți din nou clic dreapta pe proiect și alegeți Reîncărcați proiectul .

Alternativ, puteți deschide un fișier de proiect în editorul de text preferat, îl puteți edita și salva. Când reveniți la fereastra Visual Studio, vi se va solicita să reîncărcați proiectul modificat.

Controlul avertismentelor

Construirea unui software de înaltă calitate necesită să nu ignorați niciodată avertismentele de construire. Prin urmare, ar trebui să activați nivelul maxim de avertismente și să tratați orice avertismente ca erori. Rețineți că ar trebui să faceți acest lucru pentru toate configurațiile de construcție pe care le aveți, cum ar fi Debug și Release. Cel mai bun mod de a face acest lucru este să scrieți următoarele setări în grupul de proprietăți comune:

4 true

Și asigurați-vă că nu aveți aceleași setări în alte grupuri de proprietăți. În caz contrar, acestea vor suprascrie proprietățile corespunzătoare din grupul comun.

FxCop

Rularea FxCop este doar practic de realizat la fiecare versiune. Majoritatea echipelor preferă să ruleze FxCop din când în când (de obicei înainte de lansare) pentru a se asigura că nu au fost introduse erori severe. Cu toate acestea, dacă doriți să efectuați o verificare finală la fiecare versiune, adăugați această opțiune:

true

Rețineți că FxCop, la fel ca StyleCop, are propriile setări care pot fi plasate în folderul rădăcină și adăugate la controlul sursă. Aceste setări sunt utilizate probabil atunci când rulați FxCop pe serverele CI.

Documentație

Această parte este despre XmlDoc. Dacă creați un API public, atunci ar trebui să creați și să întrețineți documentația API. Majoritatea dezvoltatorilor încep cu dezvoltarea API-ului (codare efectivă) și chiar înainte de lansare, activează setarea proiectului Build / XML documentation file. Bineînțeles, după o altă reconstrucție, apar o grămadă de erori, deoarece fiecare XmlDoc lipsă are ca rezultat o eroare de compilare. Pentru a evita acest lucru, ar trebui să activați opțiunea menționată chiar de la început.

Dacă vă este lene să scrieți o documentație adecvată sau nu vă place să scrieți prea mult text, încercați instrumente care automatizează acest proces, cum ar fi Ghostdoc .

Contracte de cod

Contracte de cod este un cadru excelent de la Microsoft Research, care vă permite să exprimați condiții prealabile, postcondiții și invarianți de obiecte în codul dvs. pentru verificarea timpului de rulare, analiza statică și documentare. Am folosit acest lucru în multe proiecte critice și a ajutat foarte mult, așa că vă încurajez să încercați.

Dacă decideți să utilizați contracte de cod, atunci este important să activați contractele chiar de la început, când tocmai ați creat un nou proiect. Adăugarea de contracte în mijlocul dezvoltării este posibilă, dar va necesita modificări prin mai multe clase, pentru ca contactele să se potrivească. Deci, nu uitați să activați toate setările necesare (cel puțin CodeContractsEnableRuntimeChecking) și asigurați-vă că aceste setări apar în grupul de proprietăți comune.

Aplicarea StyleCop

Anterior am vorbit despre configurația StyleCop pentru timpul de dezvoltare. Cu toate acestea, atunci când proiectul dvs. este construit pe un server CI, ReSharper nu are efect acolo și, prin urmare, ar trebui să activăm validarea StyleCop pentru a rula cu MSBuild.

Acest lucru se face de obicei prin modificarea manuală a fișierului de proiect. Trebuie să descărcați proiectul în Visual Studio, să editați fișierul de proiect și apoi să încărcați proiectul înapoi:

false

Setarea StyleCopTreatErrorsAsWarnings va face ceea ce spune: vă va rupe construcția cu privire la orice încălcare a regulii StyleCop. Elementul de import este necesar pentru ca MSBuild să adauge sarcina StyleCop în lanțul de construire.

Este posibil să fi observat calea către Program Files. Deoarece dezvoltatorii pot avea instalate diferite versiuni StyleCop, unele echipe preferă să păstreze o copie privată a aceleiași instalații StyleCop sub controlul sursei. În acest caz, calea va fi relativă. Acest lucru facilitează și configurarea mașinilor CI, deoarece nu este nevoie să instalați StyleCop la nivel local.

AssemblyInfo

Fiecare proiect .NET creat de expertul Visual Studio va avea AssemblyInfo.cs fișier completat automat (vezi Proprietăți subfolder) care conține o parte din Assembly atribute, dar niciun vrăjitor nu poate umple toate Assembly atribute pentru tine. Asigurați-vă că aveți cel puțin aceste atribute populate:

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

Acest minim minim este necesar pentru toate ansamblurile pe care urmează să le distribuiți. Un motiv practic din spatele acestui fapt este NuGet: dacă utilizați crearea automată a specificațiilor NuGet din fișierul de asamblare selectat, acest instrument va obține informațiile necesare din aceste proprietăți.

De asemenea, puteți completa încă o proprietate încă de la început:

InternalsVisibleTo

Această proprietate face ca clasele și interfețele interne să fie vizibile pentru ansamblul specificat. Acest lucru este utilizat în general pentru testele automate pe care urmează să le creați pentru proiectul dvs.

Șiruri de conexiune

Cum să te descurci șiruri de conexiune este o întrebare foarte populară pe Stack Overflow. Problema este cum să faceți șirurile de conexiune unice pentru fiecare dezvoltator sau o lucrare CI și să nu expuneți detaliile conexiunii în timp ce publicați codul sursă.

În App.config (pentru aplicații desktop) sau Web.config (pentru aplicații web), efectuați următoarea setare care se va încărca user.config fișier în timp de execuție. Păstrați acest lucru sub controlul sursei:

user.config

Aparent, .gitignore fișierul ar trebui exclus din controlul sursă și fiecare dezvoltator ar trebui să aibă o copie locală a acestui fișier, păstrând confidențialitatea șirului de conexiune:

.gitignore

.gitignore

Pentru cei care utilizează Git ca control sursă, este important să adăugați câteva modele de fișiere la README fişier. Cu toate acestea, comunitatea noastră inteligentă a construit deja un fișier generalizat, care poate fi găsit aici: github.com/github/gitignore/blob/master/VisualStudio.gitignore .

Ar trebui să o luați ca referință README.md fișier și pur și simplu adăugați excluderile personalizate de care este posibil să aveți nevoie.

Insigne GitHub

S-ar putea să fi văzut apariții de ecusoane frumoase pe [![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)) pagina proiectului. Dacă vă publicați proiectul pe GitHub , luați în considerare conectarea proiectului dvs. la serviciile publice pentru:

• Clădire: a arăta o construcție eșuează sau trece.
• Testare: pentru a arăta acoperirea testului și starea de execuție a testului.
• Publicare: pentru a afișa cea mai recentă versiune a pachetului NuGet.

O listă completă de ecusoane și servicii conexe poate fi găsită pe scuturi.io . Este posibil să găsiți multe ecusoane interesante, care sunt bune pentru proiectele Open Source.

Odată ce v-ați înregistrat proiectul cu un serviciu selectat, vi se va oferi un link către imagine și un link complet de sintaxă de reducere, pe care îl puteți adăuga la .csproj fişier. Apropo, acesta este unul dintre motivele pentru care ar trebui să preferați reducerea Citește-mă fișiere.

Exemple de insigne de reducere, din proiectul Roslyn:

MyCompany.MyProduct

Validarea automată a structurii soluției

Chiar dacă ați setat toate setările pe care le-am discutat în acest articol, mai devreme sau mai târziu, unul dintre dezvoltatorii dvs. le poate schimba și poate efectua modificările controlului sursă. Uneori, acest lucru se întâmplă din greșeală și adesea aceste modificări nu sunt surprinse în timpul revizuirii codului. În afară de aceste accidente, ar trebui să fim atenți la următoarele erori frecvente:

• Referințe proaste : când cineva face referire la o asamblare locală pe care alții poate nu o au, sau când cineva a șters un fișier de pe disc, în timp ce legătura cu acel fișier rămâne în Install-Package SolutionInspector fişier. Acest lucru va sparge construcția cu siguranță, dar se poate întâmpla prea târziu odată ce schimbarea este împinsă, iar alții au tras-o. Acest lucru este crucial în special pentru fișierele web statice, pe care nu le puteți verifica în timpul construirii.
• Coerența numirii : instrumentele precum StyleCop pot controla codul sursă C #, dar niciun instrument nu poate aplica reguli pentru fișierele de proiect sau proprietățile ansamblului. Un exemplu bun este următorul: Vrem să numim proiectele pentru a se potrivi cu numele ansamblului de ieșire și vrem ca numele proiectelor să aibă un prefix comun, cum ar fi ](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 .

Am constatat că urmărirea acestor erori în Code Reviews este predispusă la erori și ar trebui automatizată. Așa că am scris un instrument simplu care efectuează aceste verificări și multe alte verificări pentru a verifica coerența soluției. Întâlni SolutionInspector . Acesta este Open Source și distribuit sub licență MIT. Puteți să-l construiți din codul sursă sau să-l instalați din NuGet:

MinSolutionFormatVersion

Instrumentul parcurge întreaga structură a soluției și aplică multe reguli de validare. Regulile sunt configurate prin fișiere XML, plasate împreună cu alte fișiere soluție. Pentru a controla setările pe bază de proiect, pur și simplu adăugați același fișier cu setări diferite în folderul de proiect corespunzător.

În mod implicit nu este necesar niciun fișier de configurare. În acest caz, instrumentul va aplica toate regulile disponibile și va da consolă toate problemele.

Iată exemplul fișierului de configurare:

MaxSolutionFormatVersion

Deși setările sunt destul de descriptive, voi explica câteva dintre ele:

• DetectMissingFiles / AllowBuildEvents va împiedica dezvoltatorii dvs. să comute versiunea Visual Studio.
• Properties este foarte util pentru conținutul web static sau alte fișiere non-cod adăugate la soluție sau la un proiect.

• |_+_|

  poate împiedica adăugarea de evenimente de construcție personalizate, care pot face lucruri inutile.

• |_+_|

  este cel mai flexibil element: puteți verifica orice proprietăți comparativ cu valorile dorite, indiferent dacă acestea sunt proprietăți cunoscute sau personalizate.

Concluzie

Am analizat mai multe practici standard, fișiere de configurare și setări de proiect pe care le puteți aplica atunci când începeți un proiect nou. Dacă faceți acest lucru chiar de la început, veți reduce datoria tehnică viitoare și veți face codul sursă al produsului să arate frumos și profesional. Pentru proiectele Open Source, acest lucru are o importanță deosebită, deoarece orice colaborator ar cunoaște așteptările dvs. examinând configurațiile soluției și fișierele de proiect.

Legate de: .NET Core - Going Wild și Open Source. Microsoft, ce ți-a luat atât de mult ?!