Notă: În acest articol, utilizarea termenilor "build", "continuous build", "compile" și "generate" nu este riguroasă, doar să știți ce înseamnă.
În primul rând, dacă vrei să construiești continuu, trebuie să folosești linia de comandă.
Dar comenzile din dotnet core par să fie puțin mai simple decât cele ale proiectului dotnet framework.
Pentru că comanda build a dotnetcore estedotnet msbuild xxxxx.csproj/yyyyy.sln
Iar comanda build a framework-ului dotnet este.../msbuild.exe xxxx.csproj/yyyyy.sln, și cel mai confuz lucru dintre ei (în principal oamenii care nu au căzut niciodată într-o groapă, lasă-l baltă) este acestamsbuild.exeUnde este exact?msbuild.exe？ La urma urmei, după instalarea SDK-ului dotnet framework sau a diferitelor versiuni de Visual Studio în Windows, vor fi multemsbuild.exe, oamenii nu înțeleg pe care să o folosească.
Să începem cu cum să construiești un proiect dotnet framework în Windows, pentru a nu lăsa complexitatea proiectului să afecteze ideea principală; aici credem că vrem să construim un proiect simplu de consolă, similar cu Hello World.
În concluzie, mediul:
Aparat de dezvoltare, Windows PC;
Mașina de publicare, Windows Server;
Proiect, un proiect simplu de consolă Dot Net Framework. (Folosesc versiunea 4.5.2 aici)
pe
Este cel mai bine să inițiezi un nou proiect pe o mașină de dezvoltare cu management de cod, cum ar fi git, astfel încât proiectul să poată fi clonat pe alte mașini cu rețea.
Orice ai scrie în proiect pe mașina de dezvoltare, atâta timp cât poate fi compilat. De exemplu, hello world.
În plus, se recomandă să adaugi o mică dependență de pachetul nuget proiectului și să alegi ce dorești, cum ar fi referințele log4net.
Încearcă să compilezi proiectul pe mașina de dezvoltare.
(După multe încercări, s-a confirmat că linia de comandă ar trebui să folosească msbuild.exe C:\windows\Microsoft .NET\Framework\v4.xxx\msbuild.exe la compilarea proiectului.) Totuși, tipul specific de proiect se bazează tot pe tip, alege dacă alegi Framework64 sau nu 64, fie că este v4.xxx sau 3.x, 2.x, acest sens este foarte simplu, dacă nu îl înțelegi, va fi neajutorat)
Dacă proiectul se află pe calea C:\projects\test, atunci comanda compilată ar trebui să fie:
sau
Desigur, s-ar putea să fie nevoie să aduci și alți parametri precum /p:Configuration=Release /p:plotform="Orice CPU", în funcție de situație.
4. Pe mașina de testare, git clonează proiectul și încearcă să compileze proiectul cu aceeași comandă.
5. Dacă nu reușești, trebuie să continui să încerci msbuild.exe, calea, parametrii etc. corecti, atâta timp cât nu există probleme în mediu, cu siguranță vei reuși.
6. Totuși, apare o întrebare foarte enervantă: ce se întâmplă cu dependențele de nuget-uri? Acum, nu am probleme evidente la compilare, dar cum știu unde să găsesc pachetul Nuget?
Această întrebare m-a ținut în minte mult timp.
Accesează site-ul oficial al NuGet și descarcă fișierul nuget.exe.
După încercare, acest fișier este plasat în proiect (adică în același director cu fișierul SLN sau CSPROJ) și executatnuget.exe restaurareComandă să primești pachetul Nuget necesar. Aceasta este experiența pe care am avut-o după multe încercări)
Ei bine, poți adăuga o acțiune în script și executa comanda nuget.exe restore de fiecare dată.
Ar fi, de asemenea, puțin mai convenabil să adaugi nuget.exe la variabila de mediu (fără explicații) și apoi să o executi de fiecare dată.
7. În final, am testat și am constatat că proiectul poate fi compilat cu succes prin astfel de operațiuni și comenzi pe mașina de publicare.
Aceasta este aproape de succesul suprem.
De fapt, pentru cei care înțeleg ce sunt jekin-urile, acesta este sfârșitul problemei, iar restul poate fi făcut singur.
Mai jos
1. Accesează site-ul oficial Jekins, descarcă, instalează, lansează Jekins, înregistrează un cont, fără explicații. Pentru proiectele dotnet, trebuie să instalezi pluginurile msbuild, mstest și mstestrunner.
2. Configurația globală Jenkins msbuild.
3. Creează un proiect nou și configurează-l
4. Construiește proiectul.
Practic, construcția este reușită și este ușor de depanat chiar dacă nu este reușită.
De fapt, despre folosirea jekin-urilor, mai multe dintre ele sunt învățate de unul însuți și încercate de multe ori să le înțelegem.
Supliment:
1. Dacă VS-ul poate fi compilat cu succes, dar există un prompt de sintaxă nesuportat în linia de comandă.
Atunci este posibil ca dezvoltatorul să compileze cu reguli de sintaxă mai avansate (deși proiectul se bazează pe .NET framework 4.5.2), cum ar fi C# 6.0
Mașina de lansare a instalat doar .NET framework 4.5.2, deci nu suportă unele dintre cele mai noi sintaxe.
Așadar, în acest caz, instalează cel mai recent SDK pe mașina de lansare.
Așa cum se vede în figură.
Descărcare SDK pe site-ul oficial Microsoft:https://www.microsoft.com/net/download/visual-studio-sdks
Descarcă SDK-ul corespunzător.
SDK-ul include deja Runtime.
2. Dacă jobul lui Jekins trebuie să folosească comanda bat din windows pentru a efectua o serie de operații, atunci folosirea "Referă-te la lista variabilelor de mediu disponibile" a lui Jenkins va fi utilă.
Scrie-l ca "%WORKSPACE%"
3. Dacă există spațiu în cale, cum ar fi C:\Program Files (x86)\Microsoft.NET, este necesar să se adauge ghilimele duble pe ambele părți ale variabilei.
Ca:
|
Postat pe 22.11.2018 10:29:09
|
|
|
|
