Izradite .NET projekt

Stvoriti .NET projekt od nule jednostavno je kao i pomoću čarobnjaka Visual Studio. Idite na File => New Project ili Add New Project postojećem rješenju. Jednom kada je stvoren novi projekt, možete odmah započeti s kodiranjem. Međutim, zadane postavke projekta koje su izradili čarobnjaci teško su prihvatljive za profesionalne timove, jer postavljaju prenisku granicu kvalitete. Štoviše, niti jedan čarobnjak ne može znati o drugim koracima postavljanja koje trebate izvršiti u vašem određenom razvojnom okruženju.

U ovom članku provest ću vas kroz nekoliko važnih postavki koje biste trebali omogućiti čim izradite novi projekt, što je važno da biste umanjili budući tehnički dug. Također ćemo pregledati neke uobičajene prakse .NET programeri primjenjuju se kada strukturiraju rješenja i nove projekte. Čak i ako neke od ovih ideja ne primjenjujete, lijepo je naučiti i dobiti pregled onoga što većina timova radi.

Struktura

Imati dobro definiranu strukturu od vitalne je važnosti za složene projekte. To poboljšava iskustvo ukrcaja kada se novopridošle pridružuju timu i olakšava vam život kada podržavate stare projekte. Dva su ključna pokazatelja dobre strukture:

• Korištenje mapa rješenja i projekata
• Dosljedno imenovanje

Mape

Mape rješenja , ponekad se naziva i virtualne mape , vrlo su zgodan instrument za grupiranje vaših projekata. U Istraživač rješenja jednostavno kliknite desnom tipkom miša i odaberite Add => New Solution Folder, a zatim povucite i ispustite bilo koji od postojećih projekata u ovu novu mapu. Te se mape ne zrcale u datotečnom sustavu, što vam omogućuje da fizičku strukturu zadržite nepromijenjenom, pa ih premještanje projekata iz jedne mape rješenja u drugu ne premješta fizički.

.net core 2.0 web api

Imati numerirane prefikse nije potrebno, ali čine da mape izgledaju poredane točno u Istraživač rješenja prozor.

Visual Studio može istodobno raditi s više rješenja istovremeno iskorištavanjem Pregradno jedno rješenje ili Više rješenja modeli. Rijetko se koriste, pa ih neću obrađivati ​​u ovom članku.

Za razliku od Mape rješenja , Mape projekata odgovaraju strukturi fizičkih mapa i stoga ostaju stvarne mape na disku. Štoviše, mape projekta koje sadrže C # kôd trebaju se podudarati s projektima prostor imena . To navigaciju čini prilično prirodnom. Možete čak omogućiti pravilo ReSharper da upozorava na takve neusklađenosti.

Imenovanje

Postoji nekoliko preporučenih pravila koja se primjenjuju u vezi s imenovanjem:

• Koristiti CamelCase .
• Naziv projekta trebao bi odgovarati nazivu izlaznog sklopa.
• Projekt koji sadrži automatizirane testove trebao bi imati sufiks .Tests.
• Svi nazivi projekata trebaju imati zajednički prefiks, na primjer Company.Product.

Malo je i razumnih pravila. Trebali biste sami odlučiti kada ćete ih primijeniti na temelju zdravog razuma (i engleske gramatike, naravno):

• Upotrijebite predmete u množini kada spremnik (projekt ili mapa) sadrži više primjeraka iste vrste (npr. Tests Ili System.Collections).
• Upotrijebite oblik jednine kada cijeli spremnik sadrži kôd o jednom entitetu (npr. System.Collections.ObjectModel`).
• Za kratke kratice koristite velika slova poput System.IO čini.
• Za duge kratice koristite CamelCase poput Modules.Forex..

Osnovno pravilo: kratka kratica ne smije biti duža od tri znaka.

Konfiguriranje rješenja

Konfiguriranje rješenja jednostavno je kao pružanje svih infrastrukturnih datoteka koje su vam potrebne za vaše okruženje. Iako se neke od njih mogu dodati kasnije (poput datoteka za integraciju s CI-jem), malo bi datoteka bilo bolje da ih imate na samom početku.

Postavke ReSharper

Ako ste profesionalni .NET programer, tada vrlo vjerojatno koristite ReSharper. ReSharper je vrlo fleksibilan u upravljanju svojim postavkama. Kao vođa tima možete stvarati i distribuirati Tim podijeljen postavke koje će koristiti drugi programeri. Tim podijeljen postavke se pohranjuju u datoteku s nastavkom .DotSettings. ReSharper će automatski odabrati ove postavke ako se naziv datoteke podudara s nazivom rješenja Visual Studio:

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

Stoga biste trebali stvoriti ovu datoteku na samom početku ako na kraju želite primijeniti neke postavke na cijeli tim. Dobar primjer bi bilo pravilo upotrebe (ili nekorištenja) var ključna riječ. Vaš Tim podijeljen datoteka postavki može imati samo ovo jedno pravilo, dok su druga preferencije programera. Vrijedno je spomenuti da se na isti način mogu postaviti postavke ReSharper-a na razini pojedinog projekta, jer možda imate neki naslijeđeni kôd koji ne možete izmijeniti (npr. Promijeniti u ključnu riječ var).

Ako ste ispravno imenovali ovu datoteku, kao što je prikazano u primjeru, tada će svaka nova instanca Visual Studija sa svježim postavkama ReSharpera automatski odabrati ovu datoteku i primijeniti pravila. Ne zaboravite predati ovu datoteku izvornoj kontroli.

Pravila StyleCop-a

Jednako kao i postavke ReSharper, možete dijeliti postavke StyleCopa. Ako koristite ReSharper, vjerojatno vam je instaliran dodatak za integraciju koji će koristiti StyleCop iz ReSharpera. Međutim, StyleCop pohranjuje svoje postavke neovisno u datoteke s nazivom Settings.StyleCop. Slično tome, ovu datoteku možete imati zajedno s datotekama rješenja i datotekama projekta.

Ako koristite StyleCop, ne zaboravite pokrenuti alat za konfiguriranje StyleCop i onemogućiti provjere koje ne želite izvršiti. Prema zadanim postavkama omogućene su sve provjere. Spremite nove postavke u ovu datoteku i predajte se izvornoj kontroli.

Tekstualne datoteke

Ako gradite javni proizvod i namjeravate objaviti izvorni kod, ne zaboravite stvoriti i urediti i ove datoteke:

g.co/express/hello

README.md LICENSE

Preporučujem upotrebu formata umanjenja za README.md datoteku, jer je postala industrijski standard i podržana je službama za kontrolu javnih izvora poput GitHub-a, kao i internim poslužiteljima kao što je BitBucket (bivši Stash).

NuGet specifikacije

Ako gradite knjižnicu koja će se distribuirati u galeriji NuGet, tada ćete vrlo vjerojatno trebati stvoriti datoteke sa specifikacijama paketa, poput MyProject.nuspec. Više volim ručno stvarati ove datoteke i predati ih izvornoj kontroli. Pakete obično izdaje jedan od vaših zadataka za kontinuiranu integraciju (kratki CI), ali također u bilo kojem trenutku možete ručno izraditi i objaviti paket s konzole na sljedeći način:

nuget.exe pack MyLibrary.nuspec

Samo nemojte zaboraviti povećati verziju paketa prije izvršavanja ove naredbe.

CI datoteke

Svi koristimo različite CI poslužitelje i svi imaju različite konfiguracijske skripte i postavke. Spomenuo bih samo neke od uobičajenih dodataka koje biste mogli dodati:

• NUnit postavke, koje određuju koji sklopovi sadrže testove koji se trebaju izvršiti na CI poslužitelju za određene poslove. Svi testovi su praktički podijeljeni u nekoliko kategorija. Tamo su jedinični testovi koji bi se trebao izvoditi na svakoj gradnji, ispitivanja performansi koji se izvršavaju svake noći, i integracija testovi se izvršavaju na osnovi izdanja.
• NCover postavke, koje određuju koje ispitne sklopove treba analizirati radi pokrivanja testom.
• SonarQube postavke koje određuju softverske mjerne podatke.
• Skripte za posao , kao što su NAnt, PowerShell ili jednostavno Windows batch datoteke.

Odgovarajući bootstrapped projekt smanjuje budući tehnički dug i čini izvorni kod proizvoda čitljivim i profesionalnog izgleda. Cvrkut

Konfiguriranje projekata

Datoteke projekta, naime .csproj ili .vbpro, sadrže sve postavke koje koriste Visual Studio i MSBuild. Međutim, nisu svi dostupni u prozoru Svojstva projekta. Da biste ručno uredili ove datoteke u Visual Studiju, trebali biste učiniti sljedeće:

• Desnom tipkom miša kliknite projekt u prikazu Solution Explorer.
• Odaberi Istovar projekta .
• Ponovno pritisnite desnu tipku miša za odabir akcije Uredi xyz.csproj .
• Kompletna montaža.
• Desnom tipkom miša kliknite projekt i odaberite Ponovno učitaj projekt .

Možete i otvoriti datoteku projekta u omiljenom uređivaču teksta, urediti je i spremiti. Kad se vratite na prozor Visual Studija, od vas će se zatražiti da ponovo učitate promijenjeni projekt.

Kontrola upozorenja

Izgradnja visokokvalitetnog softvera zahtijeva da nikada ne ignorirate upozorenja o gradnji. Stoga biste trebali omogućiti maksimalnu razinu upozorenja i sva upozorenja tretirati kao pogreške. Imajte na umu da biste to trebali učiniti za sve konfiguracije gradnje koje imate, kao što su otklanjanje pogrešaka i izdanje. Najbolji način za to je upisivanje sljedećih postavki u zajedničku grupu svojstava:

4 true

I pobrinite se da nemate iste postavke u drugim grupama svojstava. U suprotnom, poništit će odgovarajuća svojstva iz zajedničke grupe.

FxCop

Pokretanje FxCopa samo je praktično za svaku gradnju. Većina timova preferira pokretanje FxCopa s vremena na vrijeme (obično prije izdanja) kako bi se osiguralo da nisu uvedene ozbiljne pogreške. Međutim, ako želite izvršiti konačnu provjeru svake gradnje, dodajte ovu opciju:

true

Imajte na umu da FxCop, kao i StyleCop, ima vlastite postavke koje se mogu smjestiti u korijensku mapu i dodati u izvornu kontrolu. Te se postavke vjerojatno koriste kada se FxCop izvodi na CI poslužiteljima.

Dokumentacija

Ovaj je dio o XmlDocu. Ako gradite javni API, trebali biste stvoriti i održavati API dokumentaciju. Većina programera započinje s razvojem API-ja (stvarno kodiranje), a neposredno prije izdanja omogućuju postavku projekta Build / XML documentation file. Naravno, nakon nove obnove pojavljuje se gomila pogrešaka, jer svaki nedostajući XmlDoc rezultira pogreškom gradnje. Da biste to izbjegli, spomenutu opciju trebali biste omogućiti na samom početku.

Ako ste lijeni za pisanje odgovarajuće dokumentacije ili ne volite tipkati previše teksta, isprobajte instrumente koji automatiziraju ovaj postupak, kao što je Ghostdoc .

Kodni ugovori

Kodni ugovori izvrstan je okvir tvrtke Microsoft Research koji vam omogućuje da izrazite preduvjete, postuslove i invarijante objekta u svom kodu za provjeru vremena izvođenja, statičku analizu i dokumentaciju. Ovo sam koristio u mnogim kritičnim projektima i puno mi je pomoglo pa vas potičem da isprobate.

Ako se odlučite za upotrebu Ugovora s kodom, tada je važno omogućiti Ugovore na samom početku, kada ste tek kreirali novi projekt. Dodavanje ugovora u sredini razvoja moguće je, ali zahtijevat će promjene kroz mnoge klase kako bi se Kontakti međusobno podudarali. Dakle, ne zaboravite omogućiti sve potrebne postavke (barem CodeContractsEnableRuntimeChecking) i pobrinite se da se te postavke pojave u zajedničkoj grupi svojstava.

Izvršenje StyleCop-a

Prije smo govorili o StyleCop konfiguraciji za vrijeme razvoja. Međutim, kada je vaš projekt izgrađen na CI poslužitelju, ReSharper tamo nema učinka i stoga bismo trebali omogućiti provjeru StyleCop-a s MSBuild-om.

To se obično radi ručnom izmjenom datoteke projekta. Morate iskrcati projekt u Visual Studiju, urediti datoteku projekta i zatim učitati projekt natrag:

false

Postavka StyleCopTreatErrorsAsWarnings učinit će što kaže: razbit će vašu nadogradnju na bilo kojem kršenju pravila StyleCop. Element uvoza potreban je da bi MSBuild dodao zadatak StyleCop lancu gradnje.

Možda ste primijetili put do Program Files. Budući da programeri mogu imati instalirane različite verzije StyleCopa, neki timovi više vole držati privatnu kopiju iste instalacije StyleCop pod kontrolom izvora. U tom će slučaju put biti relativan. To također olakšava postavljanje CI strojeva jer ne trebate instalirati StyleCop lokalno.

AssemblyInfo

Svaki .NET projekt koji je stvorio čarobnjak Visual Studio imat će AssemblyInfo.cs datoteka se automatski popunjava (vidi Svojstva podmapa) koja sadrži neke od Assembly atributa, ali nijedan čarobnjak ne može ispuniti sve Assembly atribute za vas. Obavezno popunite barem ove atribute:

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

gestalt principi percepcije oblika

Ovaj minimum je potreban za sve sklopove koje ćete distribuirati. Praktični razlog toga je NuGet: Ako koristite automatsko stvaranje NuGet specifikacije iz odabrane datoteke sklopa, ovaj će alat izvući potrebne podatke iz ovih svojstava.

Na samom početku možete popuniti još jedno svojstvo:

InternalsVisibleTo

Ovo svojstvo čini interne klase i sučelja vidljivima navedenom sklopu. To se obično koristi za automatizirane testove koje ćete stvoriti za svoj projekt.

Spojni nizovi

Kako upravljati nizovi veze je vrlo popularno pitanje na Stack Overflowu. Problem je u tome kako napraviti nizove veza jedinstvenim za svakog programera ili CI posao, a ne izlagati detalje veze tijekom objavljivanja izvornog koda.

U App.config (za stolne programe) ili Web.config (za web aplikacije), napravite sljedeću postavku koja će se učitavati user.config datoteka u vrijeme izvođenja. Držite ovo pod kontrolom izvora:

user.config

Očigledno, .gitignore datoteka bi trebala biti izuzeta iz kontrole izvora, a svaki programer trebao bi imati lokalnu kopiju ove datoteke, čuvajući privatnost niza veze:

.gitignore

.gitignore

Za one koji koriste Git kao izvornu kontrolu, važno je dodati neke uzorke datoteka u README datoteka. Međutim, naša pametna zajednica već je izgradila generaliziranu datoteku koju možete pronaći ovdje: github.com/github/gitignore/blob/master/VisualStudio.gitignore .

Trebali biste to uzeti kao referencu README.md datoteku i jednostavno dodajte svoja prilagođena izuzimanja koja će vam možda dodatno trebati.

Značke GitHub-a

Možda ste vidjeli značke lijepog izgleda kako se pojavljuju na [![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)) stranica projekta. Ako svoj projekt objavljujete na GitHub , razmislite o povezivanju svog projekta s javnim uslugama za:

• Zgrada: pokazati da gradnja ne uspijeva ili prolazi.
• Testiranje: za prikaz pokrivenosti i statusa izvršavanja testa.
• Objavljivanje: za prikaz najnovije verzije paketa NuGet.

Cjelovit popis znački i srodnih usluga možete pronaći na štitovi.io . Možda ćete pronaći mnogo zanimljivih znački korisnih za projekte otvorenog koda.

Nakon što svoj projekt registrirate za odabranu uslugu, dobit ćete vezu do slike i potpunu vezu sintakse oznake, koje možete dodati u svoj .csproj datoteka. Usput, ovo je jedan od razloga zašto biste više voljeli umanjenje Pročitaj me datoteke.

Uzorak znački umanjenja iz projekta Roslyn:

MyCompany.MyProduct

koji su alati za vizualizaciju podataka

Automatska provjera valjanosti strukture rješenja

Iako ste postavili sve postavke o kojima smo raspravljali u ovom članku, prije ili kasnije jedan od vaših programera može ih promijeniti i izvršiti promjene na kontroli izvora. Ponekad se to dogodi pogreškom, a često se te promjene ne ulove tijekom pregleda koda. Osim ovih nesreća, trebali bismo paziti na sljedeće uobičajene pogreške:

• Loše reference : kada se netko poziva na lokalni skup koji drugi možda nemaju, ili kad je netko izbrisao datoteku s diska, dok veza do te datoteke ostaje u Install-Package SolutionInspector datoteka. To će sigurno prekinuti izradu, ali može se dogoditi prekasno kad se promjena pogura i drugi je povuku. To je posebno važno za statičke web datoteke koje ne možete provjeriti tijekom izrade.
• Konzistentnost imenovanja : alati poput StyleCop-a mogu kontrolirati izvorni kod C #, ali niti jedan alat ne može provesti pravila za projektne datoteke ili svojstva sklopa. Dobar primjer je sljedeći: Želimo imenovati projekte tako da odgovaraju nazivu izlaznog sklopa, a želimo da nazivi projekata imaju zajednički prefiks poput ](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 .

Otkrio sam da je promatranje ovih pogrešaka u Code Reviewu sklono pogreškama i da bi ga trebalo automatizirati. Stoga sam napisao jednostavan alat koji provodi ove i mnoge druge provjere kako bi provjerio dosljednost rješenja. Upoznajte SolutionInspector . Ovo je otvoreni izvor i distribuira se pod licencom MIT. Možete ga izraditi iz izvornog koda ili instalirati iz NuGet-a:

MinSolutionFormatVersion

Alat prolazi kroz cijelu strukturu rješenja i primjenjuje mnoga pravila provjere valjanosti. Pravila su konfigurirana XML datotekama, smještenim zajedno s ostalim datotekama rješenja. Da biste kontrolirali postavke na osnovi svakog projekta, jednostavno dodajte istu datoteku s različitim postavkama u odgovarajuću mapu projekta.

Prema zadanim postavkama nije potrebna konfiguracijska datoteka. U tom će slučaju alat primijeniti sva dostupna pravila i na konzolu donijeti sve probleme.

Evo primjera konfiguracijske datoteke:

MaxSolutionFormatVersion

Iako su postavke prilično opisne, objasnit ću neke od njih:

• DetectMissingFiles / AllowBuildEvents spriječit će vaše programere da prebace verziju Visual Studija.
• Properties je vrlo koristan za statički web sadržaj ili druge datoteke bez koda dodane u rješenje ili projekt.

• |_+_|

  može spriječiti dodavanje prilagođenih događaja gradnje koji mogu učiniti nepotrebne stvari.

• |_+_|

  je najfleksibilniji element: možete provjeriti bilo koja svojstva prema željenim vrijednostima, bilo da su to poznata svojstva ili prilagođena.

Zaključak

Pregledali smo nekoliko standardnih praksi, konfiguracijskih datoteka i postavki projekta koje možete primijeniti prilikom pokretanja novog projekta. Ako to učinite na samom početku, smanjili biste budući tehnički dug i učinit će da vaš izvorni kod izgleda lijepo i profesionalno. Za projekte otvorenog koda to je od posebne važnosti, jer bi svaki suradnik proučavao konfiguracije rješenja i datoteke projekata znao vaša očekivanja.

Povezano: .NET Core - divljanje i otvoreni izvor. Microsoft, što ti je toliko trebalo ?!