PROGRAMUL DE STUDIU CALCULATOARE FORMA DE ÎNVĂȚĂMÂNT IF LUCRARE DE DIZERTAȚIE COORDONATOR ȘTIINȚIFIC PROF. DR. ING. CORNELIA AURORA GYŐRÖDI ABSOLVENT… [610705]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU CALCULATOARE
FORMA DE ÎNVĂȚĂMÂNT IF

LUCRARE DE DIZERTAȚIE

COORDONATOR ȘTIINȚIFIC
PROF. DR. ING. CORNELIA AURORA GYŐRÖDI

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI
TEHNOLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU CALCULATOARE
FORMA DE ÎNVĂȚĂMÂNT IF

Comparație între
.NET Framework și .NET Core

COORDONATOR ȘTIINȚIFIC
PROF. DR. ING. CORNELIA AURORA GYŐRÖDI

ABSOLVENT: [anonimizat]
2020

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL DE CALCULATOARE ȘI TEHNOLOGIA INFORMATIEI

TEMA

Lucrare de Finalizare a studiilor a student: [anonimizat]: George COSMA
1). Tema lucrării de finalizare a studiilor: Comparație între .Net Framework și .Net Core
2). Termenul pentru predarea lucrării: 03.07.20 20
3). Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor: Computer
Desktop: Procesor Intel(R) Core(TM) i7-4702MQ CPU @ 2.2 GHz, 2.19 GHz, 8 GB RAM,
placa video NVIDI A GeForce GTX 960 SO -Windows 10 , Router Wireless, Legatură stabilă
la internet(WAN și LAN), cont student: [anonimizat] , Visual Studio 2019.
4). Conținutul lucrării de finalizare a studiilor: Introducere, Capitolul I. Despre .Net
Framework, Capitolul II. Despre .Net Core , Capitolul III. Comparații între .Net Framework și
.Net Core , Capitolul IV. Teste și exemple de performanță , Capitolul V. Concluzii,
Bibliografie.
5).Material grafic: Prezentare PowerPoint.
6). Locul de documentare pentru elaborarea lucr ării: Biblioteca Universității din Oradea,
Internet.
7). Data emiterii temei: 03.2.2020 .

COORDONATOR ȘTIINȚIFIC
PROF. DR. ING. CORNELIA AURORA GYŐRÖDI

Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………………………….. …….. 1
Capitolul 1. Despre .NET Framework ………………………….. ………………………….. ………………………….. 2
1.1. Structura .NET Framework ………………………….. ………………………….. ………………………….. ….. 2
2.2. Componenta Common Language Runtime (CLR) ………………………….. ………………………….. … 3
2.2.1 Executabilele CLR ………………………….. ………………………….. ………………………….. ……………. 4
2.3. Fișiere executabile portabile .NET ………………………….. ………………………….. …………………….. 4
2.4. Metadata ………………………….. ………………………….. ………………………….. ………………………….. . 5
Capitolul 2. Despre .NET Core ………………………….. ………………………….. ………………………….. ………. 6
2.1. Structura .NET Core ………………………….. ………………………….. ………………………….. …………… 6
2.2. ASP.NET Core 1.x ………………………….. ………………………….. ………………………….. ……………… 7
2.3 ASP.NET Core 2.x ………………………….. ………………………….. ………………………….. ……………… 7
2.4. ASP.NET Core 3.x ………………………….. ………………………….. ………………………….. ……………… 8
2.5. De ce să alegem .NET Core ………………………….. ………………………….. ………………………….. …. 8
Capitolul 3. Comparații între .NET Framework și .NET Core ………………………….. ………………………. 9
3.1. Alegerea framework -ului potrivit ………………………….. ………………………….. ………………………. 9
3.2. Portarea din .NET Framework în .NET Core ………………………….. ………………………….. ……… 13
3.3. Diferențe la nivel de structură a proiectelor ………………………….. ………………………….. ……….. 14
Capitolul 4. Teste și exemple de performanță ………………………….. ………………………….. ………………. 21
4.1. Teste de performanță ………………………….. ………………………….. ………………………….. ……… 21
4.2. Exe mple de sintaxă ………………………….. ………………………….. ………………………….. ……….. 23
Capitolul 5. Concluzii ………………………….. ………………………….. ………………………….. …………………. 35
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ….. 36

1
Introducere

Framework -ul .NET este un cadru de dezvoltare care oferă o nouă interfață de
programare pentru serviciile și API -urile Windows și integrează o serie de tehnologii care au
apărut de la Microsoft la sfârșitul anilor 1990. Platforma .NET constă din patru grupuri de
produse se parate: instrumente de dezvoltare și biblioteci, servicii Web, servere specializate și
dispozitive.
Instrumentele de dezvoltare și bibliotecile sunt un set de limbi, inclusiv C #, J # și
VB.NET; un set de instrumente de dezvoltare, inclusiv Visual Studio .NET; o bibliotecă de
clase cuprinzătoare pentru construirea de servicii web și aplicații web și Windows; precum și
Common Runtime Language (CLR). Aceste componente formează colectiv cea mai mare
parte a .NET Framework.
Serviciile web reprezintă o ofertă de servicii web comerciale, în special inițiativa
.NET Services; contra cost, dezvoltatorii pot utiliza aceste servicii în construirea aplicațiilor
care le necesită. Serverele specializate sunt un set de servere de întreprindere .NET, inclusiv
SQL Server, Exchange Server, BizTalk Server și așa mai departe. Acestea oferă
funcționalități specializate pentru stocarea relațională de date, e -mail și comerțul B2B.
Dispozitivele sunt alcătuite din dispozitive non -compatibile .NET, de la telefoane mobile la
casete de joc. [2]
NET Core este open source (licență MIT) și a fost contribuit la Fundația .NET de
Microsoft în 2014. Acum este unul dintre cele mai active proiecte .NET Foundation. Poate fi
adoptat în mod liber de către persoane fizice și companii, inclusiv în scopuri personale,
academice sau comerciale.
Mai multe companii folosesc .NET Core ca parte a aplicațiilor, instrumentelor,
platformelor noi și serviciilor de găzduire. Unele dintre aceste companii aduc contribuții
semnificative la .NET Core pe GitHub și oferă îndrumări cu privire la direcția produsului ca
parte a grupului de direcție tehnică .NET Foundation [3]

2
Capitolul 1 . Despre .NET Framework
1.1. Structura .NET Framework

.NET Framework se află deasupra sistemului de operare, care poate avea câteva
versiuni diferite de Windows și constă dintr -un număr de componente. .NET este, în esență, o
aplicație de sistem care rulează pe Windows, așa cum putem vedea în figura 1 -1.

Figura 1 -1 [2]
Cea mai importantă componentă a cadrului este CLR. Programatorii Java, ar trebui să
gândească CLR ca echivalentul .NET pentru Java Virtual Machine (JVM). În caz contrar,
gândiți -vă la CLR ca la inima și sufletul arhitecturii .NET. La un nivel înalt, CLR activează
obiectele, efectuează verificări de securitate asupra ace stora, le pune în memorie, le e xecută și
le colectează gunoiul (garbage -collector).
Conceptual, CLR și JVM sunt similare, prin faptul că sunt ambele infrastructură de
execuție care abstractizează diferențele de bază ale platformei. Cu toate acestea, în tim p ce
JVM acceptă oficial numai limbajul Java, CLR acceptă orice limbă decât poate fi
reprezentată în limbajul său comun intermediar (CIL). JVM execută bytecode, astfel încât, în
principiu, poate suporta și multe limbi.
În figura 2 -1, stratul de deasupra C LR este un set de clase de bază cadru. Acest set de
clase este similar cu setul de clase găsite în STL, MFC, ATL sau Java. Aceste clase acceptă
funcționalități rudimentare de intrare și ieșire, manipularea șirurilor, gestionarea securității,

3
comunicații de rețea, managementul thread -urilor, gestionarea textului, funcționalitatea
reflecției, funcționalitatea colecțiilor, precum și alte funcții.
În partea de sus a claselor de bază cadru este un set de clase care extind clasele de
bază pentru a sprijini gestio narea datelor și manipularea XML. Aceste clase, numite
ADO.NET, acceptă gestionarea persistentă a datelor – date care sunt stocate în bazele de date
backend. Alături de clasele de date, .NET Framework acceptă o serie de clase pentru a ne
permite să manipul ăm datele XML și să efectuăm căutări XML și traduceri XML.
Clasele din trei tehnologii diferite (inclusiv servicii web, formulare web și formulare
Windows) extind clasele de bază cadru și clasele de date și XML. Serviciile web includ o
serie de clase care sprijină dezvoltarea componentelor ușoare distribuite, care funcționează
chiar și în fața firewall -urilor și a software -ului NAT. Aceste componente acceptă plug -and-
play pe Internet, deoarece serviciile web folosesc HTTP și SOAP standard.
Formularele Web (Web Forms) , tehnologia cheie din spatele ASP.NET, includ o serie
de clase care ne permit să dezvoltăm rapid aplicații Web Graphical User Interface (GUI).
Dacă dezvoltăm în prezent aplicații web cu Visual Interdev, ne putem gândi la Formularele
Web ca o fac ilitate care ne permite să dezvoltăm interfațe web GUI utilizând aceeași abordare
drag-and-drop ca și cum am dezvolta GUI -urile în Visual Basic. Pur și simplu controlați
glisarea și fixarea pe Formularul nostru Web, faceți dublu clic pe un control și scrie ți codul
pentru a răspunde la evenimentul asociat.
Windows Forms acceptă un set de clase care ne permit să dezvoltăm aplicații native
GUI Windows. Ne putem gândi la aceste clase în mod colectiv ca la o versiune mult mai
bună a MFC în C ++, deoarece susțin o dezvoltare a GUI mai ușoară și mai puternică și oferă
o interfață comună, consistentă, care poate fi utilizată în toate limbile.
2.2. Componenta Common Language Runtime (CLR)

Cea mai importantă componentă a .NET Framework este Common Language
Runtime (CLR). CLR -ul organizează și execută codul scris în limbaje .NET și stă la baza
arhitecturii .NET.

4
2.2.1 Executabilele CLR

Executabilele .NET sunt diferite față de executabilele tipice Windows în ideea în care,
ele nu transportă doar cod și date dar și meta date.
Hello World în C#
Împrumutând sintaxe de la Java și C++, C# este un limbaj simplu orientat spre obiecte
pe care Mi crosoft l -a folosit pentru a scrie mare parte din clasele și uneltele de bază ale .NET.
Pentru programatorii de Java, întelegerea codului C# nu are trebui să reprezinte probleme. În
următoarele rânduri vom expune un exemplu simplu pentru clasa Main în limb ajul C#.
using System;
public class MainApp
{
public static void Main()
{
Console.WriteLine(“C# Hello, world!”);
}
}
C# este similar Java deoarece nu are conceptul de fișiere antet. Definirea și
implementarea claselor sunt stocate în acelasi fișier .cs.
2.3. Fișiere executabile portabile .NET

Un fișier executabil Windows, EXE sau DLL, trebuie să se conformeze unui format
de fișier numit PE file format, care este un derivat din Common Object File Format (COFF).
Sistemul de operare Windows stie cum să încarce și să ruleze fișiere executabile EXE sau
DLL deoarece înțelege formatul de fișier PE. Așadar, orice compilator care dorește să
genereze fișiere executabile în Windows, trebuie să respecte regula PE/COFF.
Un fișier standard PE pentru Windows este divizat în mai multe secțiuni începând cu
head er-ul MS -DOS, urmat de header -ul PE, header -ul opțional și la final de un număr de
secțiuni cu imagini native incluzând fișiere de tip .text, .data, .rdata, sau .rsrc .

5
Așa cu m sugerează și figura 1 -2, extensiile pe care Microsoft le -a adăugat fo rmatului
de bază PE include header -ul CLR și datele CLR. Header -ul CLR stochează în mare parte
adrese virtuale relative (RVA) spre locații care conțin informații pertinente care ajută CLR -ul
să organizeze execuția programului. Porțiunea pentru datele CLR conține met a date și coduri
IL, ambele determinând cum vor fi executate programele. Compilatoarele care țintesc CLR -ul
trebuie să emită atât header -ul CLR și datele in fișierul PE generat, altfel fișierul PE rezultat
nu va rula sub CLR.

Figura 1 -2 [2]
2.4. Metadat a

Meta datele (Metadata) reprezintă informații, care pot fi citite de către mașină, despre
anumite resurse. Astfel de informații pot include date despre conținut, format, dimensiune sau
alte caracteristici ale sursei de date. În .NET, meta datele includ t ipuri de definiții, informații
privind versiunea, referințe către ansanble externe sau alte informații standardizate.
Pentru ca doua sisteme, componente sau obiecte să poată să comunice între ele, cel
puțin una dintre ele trebuie să cunoască anumite infor mații despre cealaltă. În COM, aceste
informații reprezintă interfața de specificații care este implementată de un furnizor de
componente și utilizat de consumatorii acestuia.
Tipurile de librării sunt extrem de bogate în COM, însă sunt criticate des dato rită
lipsei de standardizare a acestora. Dezvoltatorii .NET au inventat un nou mecanism pentru

6
captarea tipurilor de informații. Astfel, în locul utilizării termenului de tip librărie de tipuri
(type -library), au apărut meta datele (metadata). [2]

Capitolul 2 . Despre .NET Core

2.1. Structura .NET Core

.NET Core a fost construit ca un produs foarte similar, dar unic în raport cu alte
produse .NET. Acesta a fost proiectat pentru a permite o adaptare largă la noile platforme și
sarcini de muncă. Are mai multe porturi de sistem de operare și CPU disponibile și poate fi
portat la multe altele.
Produsul este împărțit în mai multe bucăți, permițând diverselor piese să fie adaptate
la noile platforme în diferite momente. Bibliotecile de fundație specifice runtime și platformă
trebuie portate ca unitate. Bibliotecile cu platformă agnostică ar trebui să funcționeze așa cum
este pe toate platformele, prin construcție.
Există o tendință de proiect pentru reducerea implementărilor specifice platformei
pentru a crește eficiența dezvoltatorilor, preferând codul C # neutru de platformă ori de câte
ori un algoritm sau API poate fi implementat integral sau parțial în acest mod. [3]
.NET Core acceptă patru scenarii multi -platformă: aplicații web ASP.NET Core,
aplicați i de linie de comandă, biblioteci și aplicații Universal Windows Platform. În prezent,
nu implementează Windows Forms sau WPF care redă GUI standard pentru software -ul
desktop pe Windows. .NET Core 3 acceptă tehnologiile desktop WinForms, WPF și UWP.
.NET Core acceptă utilizarea pachetelor NuGet. Spre deosebire de .NET Framework, care
este deservit folosind Windows Update, .NET Core se bazează pe managerul său de pachete
pentru a primi actualizări.
Este format din CoreCLR, o implementare completă a timpului de execuție a
Common Language Runtime, care a provenit de la Microsoft ca mașină virtuală pentru
gestionarea execuției programelor .NET și include un compilator just -in-time numit RyuJIT.
.NET Core conține, de asemenea, CoreRT, .NET Native runtime optimiz at pentru a fi integrat
în binare native AIL compilate.

7
.NET Core include și CoreFX, care este o furcă parțială a bibliotecilor standard .NET
Framework. În timp ce .NET Core împărtășește un subset de API -uri .NET Framework, vine
cu propria API care nu face parte din .NET Framework. O variantă a bibliotecii .NET Core
este utilizată pentru UWP.
Interfața de linie de comandă .NET Core oferă un punct de intrare de execuție pentru
sistemele de operare și oferă servicii dezvoltatorilor cum ar fi compilarea și ges tionarea
pachetelor. [4]

2.2. ASP .NET Core 1.x

Cea mai importantă realizare adusă de eforturile depuse în scopul dezvoltării soluțiilor
de tip open -source a fost publicarea ASP.NET Core 1.0 în anul 2016. A reprezentat o
reimplementare complete a ASP.NET Framework care era utilizat începând cu anul 2002 și
care a evoluat cu modificări substanțiale la nivelul arhitecturii nucleului.
Noul framework a unit toate tehnologiile anterioare pentru dezvoltarea de aplicații
web precum MVC, Web API și Web Pages într -un singur modul de programare cunoscut ca
și MVC6. Noul modul a introdus și o componentă bogată și de tip cross -platfom numită .NET
Core, livrată cu toate uneltele enunțate anterior, o platformă de compilare (Roslyn), o rutină
cross -platform (CoreCLR) și un compilator îmbunătățit x64 Just -In-Time (RyuJIT). [7]

2.3 ASP .NET Core 2.x

Un nou mare pas a fost făcut în 2017, la momentul lansării ASP.NET Core 2.0. Noua
versiune a adus un număr mare de îmbunătățiri de interfață, mare majoritate țintind spre
stand ardizarea API -urilor distribuite în .NET Framework, .NET Core și .NET Standard
pentru a le face compatibile cu vechile tehnologii.
Datorită acestor eforturi, mutarea proiectelor dezvoltate în .NET Framework spre
.NET Core a devenit mult mai simplă oferind dezvoltatorilor posibilitatea de a adapta codul
sursă la noua paradigmă fără a -și pierde know -how-ul existent.

8
Au fost introduse de asemenea și alte îmbunătățiri de securitate și performanță dar și
noi funcționalități pentru SignalR, o librărie open -source care simplifică adăugarea
funcționalităților de comunicare în timp real pentru aplicațiile de tip .NET Core. Au fost
adăugate și librării de clase Razor, o îmbunătățire a SDK -ului Razor care permite
dezvoltatorilor să construiască view -uri și pagini în clase reutilizabile, librării pentru Identity
UI, funcționalitatea de scaffolding, suport pentru GDPR prin API -uri orientate spre
privatizarea datelor cu caracter personal. [7]

2.4. ASP .NET Core 3.x

ASP.NET Core 3 a fost lansat în luna Septembrie 2019 și a adus cu aceasta un nou
pachet de îmbunătățiri de performanță și securitate dar și noi funcționalități pentru suportul
pentru aplicații desktop (însă doar pentru Windows) cu capacități puternice de i mportare
pentru Windows Forms și Windows Presentation Foundation (WPF).
De asemenea include suport și pentru C# 8, acces la noi API -uri care aduc
îmbunătățiri semnificative de performanță, suport integrat pentru JSON, câteva îmbunătățiri
semnificative pe parte de securitate prin namespace -ul System.Security.Cryptography.
.NET Core 3 a introdus de asemenea și Blazor, un framework gratuit și open -source
care le permite dezvoltatorilor să creeze aplicații web prin intermediul C# și HTML.
Ca și dimensiune, S DK-ul .NET Core 3 este mult mai mic decât versiunea anterioară,
datorită faptului că au fost eliminate pachetele inutile care nu -și mai aveau rostul în noua
versiune. [7]

2.5. De ce să alegem .NET Core

Ce avantaje aduce .NET Core în prezent și motivele pentru care poate fi ales ca și
framework de dezvoltare a aplicațiilor web se regăsesc în lista următoare:
 Performan ță: Noua versiune de .NET Core este extrem de rapidă pe orice sistem de
operare

9
 Integrarea : Este compatibil cu orice framework de client -side inclusiv Angular,
React sau Vue.js
 Abordare Cross -Platform : Aplicațiile dezvoltate în .NET Core pot să ruleze pe orice
sistem de operare la fel de bine (Windows, macOS sau Linux)
 Găzduirea : Aplicațiile rea lizate cu .NET Core pot să fie găzduite pe orice server. Fie
o mașină cu sistem de operare Windows și IIS sau cu sistem de operare Linux și
Apache sau Nginx, de la containere Docker până la edge -case, găzduiri pe mașini
locale.
 Dependency Injection : Frame work -ul suportă un model de design cu dependency
injection integrat, care furnizează un număr mare de avantaje în timpul dezvoltării
precum dependințe reduse, cod reutilizabil, citirea mult mai ușoară a codului și
testarea
 O conductă HTTP modulară: Middlew are-ul .NET Core le facilitează
dezvoltatorilor control granular asupra conductei HTTP, care poate fi redus până la
nucleus sau îmbogățit cu funționalități puternice și cu posibilități mari de configurare
pentru internaționalizarea, autentificarea prin ter țe părți, caching, routarea și altele.
 Open source: Tot framework -ul .NET Core a fost lansat ca și open source și se
bazează foarte mult pe suportul comunității, astfel fiind verificat și îmbunătățit de sute
de dezvoltatori în fiecare zi
 Execuție side -by-side: Suportă rularea simultană a mai multor versiuni a unei
aplicații sau componente pe aceeași mașină. Asta înseamnă că putem să avem mai
multe versiuni de CLR și mai multe versiuni ale aplicației sau a componentelor, toate
rulând pe aceeași mașină. Este un mare avantaj pentru dezvoltatori, și oferă un mult
mai mare control. [7]
Capitolul 3 . Comparații între .NET Framework și .NET Core

3.1. Alegerea framework -ului potrivit

.NET a fost anunțat pentru prima dată de Microsoft în 2000 și apoi a evoluat de acolo.
Framework -ul .NET a fost implementarea principală .NET produsă de Microsoft în acea
perioadă de aproape două decenii.
Diferențele majore între .NET Core și .NET Framework:

10
 Modele de aplicații – .NET Core nu acceptă toate modelele de aplicații .NET
Framework. În special, nu acceptă formularele web ASP.NET și ASP.NET
MVC, dar acceptă ASP.NET Core MVC. A fost anunțat că .NET Core 3 va
suporta WPF și Windows Forms
 API-uri – .NET Core conține un subset mare de biblioteci .NET Framework
Base Class, cu o factorizare diferită (numele asamblărilor sunt diferite;
membrii expuși la tipuri diferă în cazuri cheie). Aceste diferențe necesită
modificări ale sursei portului .NET Core în unele cazuri (a se vedea microsoft
/ dotnet -apiport). .NET Cor e implementează specificația .NET Standard API.
 Subsisteme – .NET Core implementează un subset de subsisteme din .NET
Framework, cu scopul unei implementări și a unui model de programare mai
simple. De exemplu, Code Access Security (CAS) nu este acceptat, în timp ce
reflectarea este acceptată.
 Platforme – .NET Framework acceptă Windows și Windows Server în timp ce
.NET Core acceptă și macOS și Linux.
 Open Source – .NET Core este open source, în timp ce un subset de numai
citire a .NET Framework este open so urce.

În timp ce .NET Core este unic și are diferențe semnificative față de .NET Framework
și alte implementări .NET, este simplu să partajați cod între aceste implementări, folosind
tehnici de partajare sursă sau binare.
Deoarece .NET Core acceptă instal area cot la cot, iar timpul său de rulare este
complet independent de .NET Framework, acesta poate fi instalat pe mașini cu .NET
Framework instalat fără probleme. [4]

11

Figura 3 -1 [1]

Microsoft acceptă atât runtime, cât .NET core și .NET Framework pentru crearea de
aplicații cu .NET și, de asemenea, împărtășesc o mulțime de aceleași API -uri partajate care se
numește .NETStandard.
.NET Framework acceptă aplicații Windows și Web. ASP.NET MVC este utilizat
pentru a construi aplicații Web în .NET Framework. Fo losind .NET Framework putem folosi
Windows Forms, UWP și WPF pentru a dezvolta aplicații de desktop Windows și aplicații
bazate pe server în .NET Framework. .NET Core este noul cadru .NET cu mai multe
platforme și open -source pentru a dezvolta aplicații pe ntru toate sistemele de operare majore,
inclusiv Mac, Linux și Windows.
.NET Core acceptă numai UWP și ASP.NET Core. ASP.NET Core este utilizat pentru
a construi aplicații web bazate pe browser și, în prezent, nu acceptă o aplicație desktop cu
interfața de utilizator. Programatorii pot dezvolta aplicații și biblioteci în C #, VB.NET și F #
în ambele perioade de rulare. [1]

12

Figura 3 -2 [1]
Microsoft .NET Framework este o opțiune mai bună dacă:
 Nu sunt eți dispuși să învățați o tehnologie nouă.
 Sunteți un expert în aplicația noastră existentă și doriți să explorați mai multe
funcționalități pe aceeași aplicație.
 Aveți deja o echipă talentată actuală, cu expertiză cadru .NET și dezvoltând
software gata de producție.
 Aveți nevoie de un mediu constant pentru a lucra.
 Aveți versiuni mai apropiate .NET Framework.
 Nu doriți să petreceți timp cu actualizări și modificări constante.
 Crearea de aplicații desktop pentru clientul Windows folosind Windows
Forms sau WPF.
Microsoft .NET Core este o opțiune mai bună dacă:
 Nu vă este teamă să învețați și să actualizați lucruri noi.
 Doriți să dezvoltați aplicații pe sistemele de operare Windows, Linux și Mac
folosind .NET Core.
 Nu vă este frică să rupeți și să remediați lucrurile, deoarece ASP.NET Core nu
este pe deplin dezvo ltat.
 Sunteți u n dezvol tator care învață doar .NET și lucrează cu open source. [1]

Următorul tabel ne poate ajuta să luăm decizia corectă :

13

Figura 3 -3 [1]
3.2. Portarea din .NET Framework în .NET Core

Dacă avem un cod care rulează pe .NET Framework, s-ar putea să fim interesați să
rulăm și codul nostru pe .NET Core. Iată o prezentare generală a procesului de portare și o
listă a instrumentelor pe care le -am putea găsi utile atunci când portăm codul nostru la .NET
Core. [5]
Următorul proces ne poate ajuta în portarea proiectului nostru spre .NET Core:
1. Identificați și țineți cont de dependențele noastre de terți. Acest pas implică
înțelegerea care sunt dependențele noastre de la terți, cum depindem de ele, cum să
verificăm dacă funcționează și pe .NET Co re și pașii pe care îi putem face dacă nu.
Acoperă, de asemenea, modul în care ne putem migra dependențele în formatul
PackageReference care este utilizat în .NET Core.
2. Retargetați toate proiectele pe care dorim să le portăm pentru a viza .NET Framework
4.7.2 sau mai nou. Acest pas asigură că putem folosi alternative API pentru ținte
specifice .NET Framework atunci când .NET Core nu acceptă o anumită API.
3. Utilizați .NET Portability Analyzer pentru a analiza ansamblările noastre și pentru a
dezvolta un plan de port în funcție de rezultatele sale. Instrumentul API Portability
Analyzer analizează ansamblurile noastre compilate și generează un raport care arată
un rezumat al portabilității la nivel înalt și o defalcare a fiecărui API pe care îl
utilizăm care nu este disponibil pe .NET Core. Putem folosi acest raport alături de o
analiză a bazei noastre de coduri pentru a dezvolta un plan pentru modul în care vom
transmite codul nostru.

14
4. Portarea codului . Deoarece portarea la .NET Core este o schimbare atât de importantă
pentru baza dvs. de coduri, este foarte recomandat să ne portăm testele, astfel încât să
putem rula teste pe măsură ce le portăm codul. MSTest, xUnit și NUnit acceptă toate
.NET Core.
5. Executarea planului de portare.

3.3. Diferențe la nivel de s tructură a proiectelor

Cea mai bună metodă de a afla ce e nou într -o anumită tehnologie, este să o compari
cu versiunile anterioare. Vom analiza diferențele dintre două proiecte de tip MVC .NET Core
și .NET Framework prin compararea a două aplicații simpl e și punerea în evidență a
diferențelor de structură a proiectelor. [8]

Integrarea .NET Core MVC și Web API

În figura 3 -4 se pot observa diferențele în momentul selectării tipului de aplicație
dorită. Astfel că, .NET Framework ne va oferi posibilitatea de a selecta modelul MVC sau
Web API sau chiar ambele. Acest lucru se datorează faptului că tehnologiile utilizate pentru
dezvoltarea MVC și Web API nu au fost aceleași.
Pe de altă parte, tipul de proiect MVC pentru .NET Core include automat și tipul Web
API. În figura de mai jos se poate observa faptul că acea căsuță este defibată.

15

Figura 3 -4 [8]

Diferențe la nivel de structură a soluției

Figura 3 -5 reprezintă ferestrele de explorare a soluțiilor pentru ambele tipuri de
proiecte .NET Core și .NET Framework.
În partea stângă se poate observa că .NET Core nu are un fișier Web.config și nici
Global.asax. Pentru configurarea setărilor, date de autentificare și execuția specifică de la
începutul lansării aplicației există în schimb fișierele appsettings.json. [8]

16

Figura 3 -5 [8]
ASP.NET Core țintește pe deplin .NET și .NET Core

.NET Core este platformă de dezvoltare cu scop general, dezvoltată de Microsoft și de
comunitatea .NET de pe GitHub. Este cross -platform, rulează pe Windows, macOS și Linux
și poate fi folosit pe orice dispozitiv, servicii cloud sau soluții integrate inter net-of-things.
Dezvoltarea aplicațiilor în .NET Core poate fi realizată din orice mediu software de
dezvoltare precum Visual Studio Code, Vim, Atom sau Sublime. [8]

ASP.NET Core nu are nevoie de IIS pentru găzduire

Scopul ASP.NET Core este de a fi multi plă platformă folosind .NET Core. Având în
vedere acest lucru, Microsoft a decis să găzduiască aplicații ASP.NET Core nu numai pe IIS,
ci pot fi găzduite de sine stătător sau pot utiliza serverul web Nginx pe Linux. Kestrel va fi un
server web intern pentr u procesarea cererilor. [8]

17
Folderul wwwroot pentru fișiere statice

Folderul wwwroot reprezintă rădăcina reală a aplicației web atunci când rulează pe un
server web. Fișierele statice precum config.json, care nu sunt în wwwroot, nu vor fi niciodată
accesibile și nu este necesară crearea de reguli speciale pentru a bloca accesul la fișierele
sensibile.
Aceste fișiere statice pot fi HTML simplu, Javascript, CSS, imagini, bibliotecă etc.

Figura 3 -6 [8]
În plus față de avantajele de securitate, folderu l wwwroot simplifică și sarcini
comune, cum ar fi pachetul și minificarea, care acum pot fi mai ușor încorporate într -un
proces de construire standard și automatizate folosind instrumente precum Grunt. Numele
folderului „wwwroot” poate fi schimbat și el. [8]

18

Noi abordări privind dependințele pachetelor server -side și client -side

Orice dezvoltator .NET ar fi familiar că folderul Referințe conține toate DLL -urile,
pachetele NuGet pentru .NET Framework. Profitați de experiența de lucru în Visual Studio
IDE și implementați aplicații ASP.NET Core fie pe Windows, Linux sau Mac folosind .NET
Core.
Managementul său lateral al dependențelor Server. Gestionarea dependenței din
partea clientului este mai importantă, deoarece partea clientului are mai multe pachete diferite
față de server.
Partea clientului va avea cu siguranță jQuery, Bootstrap, grohărie, orice cadre
Javascript precum AngularJS, Backbone etc, imagini, fișiere de stil. Gestionarea pachetelor
din partea clientului în comunitatea open source are două nume „LibMan” (recent lansat) și
„NPM”. Ele fac parte din „Dependențe”.

Figura 3 -7 [8]

19

Pachetele server -side economisesc spațiu în .NET Core

Am folosit managerul de pachete NuGet pentru a adăuga o referință la ansambluri,
bibliotecă, framework sau orice pachete terțe. Acestea ar fi fost descărcate din NuGet care
creează folderul „Pachetele” în structura proiectului.
30 de aplicații ASP.NET, toate folosesc pachete NuGet pentru a face referințe la
dependențe costante de aproximativ 70 MB spațiu pe dis c, astfel încât ajungem aproape să
folosim spațiu pe disc de 2 GB pentru stocarea pachetelor, chiar dacă toate sunt la fel. Unii
dezvoltatori SMART cunosc această problemă, au unele soluții proprii.
ASP.NET Core a venit cu stocarea tuturor pachetelor legat e de dezvoltarea sa în
folderul Utilizatori și, în timp ce creează aplicații ASP.NET Core, Visual Studio le va face
referire din folderul Utilizatori.
Această caracteristică se numește Runtime Store pentru .NET Core 2 Acum, chiar
dacă aveți 100 de aplicați i de bază ASP.NET Core, toate fac referințe din dotnet în folderul
Utilizatori, care este aproape de doar câteva MB.

Integrarea Dependency Injection (DI)

Dependența de injecție (DI) realizează un cod slab cuplat și mai testabil, este foarte
important pen tru că ajută la testarea unității de scriere. În aplicațiile ASP.NET MVC 5/4 sau
clasice bazate pe ASPX, obișnuim să avem containere DI separate utilizate ca Unity,
AutoFac, StructureMap etc.
Acum, în aplicațiile ASP.NET Core, injecția de dependență este î ncorporată, adică
nicio durere de cap de configurare pentru DI. Creați doar câteva servicii și pregătiți -vă să
folosiți DI.
De fapt, aplicația Core MVC de exemplu are DI integrat, deschidem „Startup.cs” și
căutăm metoda „ConfigureServices (IServiceCollecti on services)”.

20
Scopul său principal este configurarea serviciilor precum EF, Autentificare, adăugarea
de MVC și servicii personalizate scrise de mână precum IEmailServer și ISmsSender. [8]
Funcționalitatea de stocare a “secretelor”

De multe ori păstrăm da te sensibile în timpul activității noastre de dezvoltare în cadrul
arborelui de proiect, deseori împărtășim în mod greșit aceste secrete cu altele prin partajarea
codului, adăugându -l accidental TFS (sursa de control).
Din când în când, am fi putut experim enta acest lucru. Aplicațiile bazate pe ASP.NET
Core au acum un concept al Secretelor utilizatorului; Instrumentul Secret Manager oferă un
mecanism mai general de stocare a datelor sensibile pentru lucrările de dezvoltare în afara
arborelui de proiect.
Instrumentul Secret Manager nu criptează secretele stocate și nu trebuie tratat ca un
magazin de încredere. Este doar în scop de dezvoltare.
Există multe diferențe în comparație cu ASP.NET MVC 5/4, dar fără a scrie un singur
cod dacă putem găsi aceste diferen țe, atunci înseamnă că Microsoft a avansat mult în ceea ce
privește transformarea sa în Open Source. [8]

21

Capitolul 4. Teste și exemple de performanță

Există multe aspecte interesante pentru .NET Core: open source, cross platform, x –
copy implementabilă și nu numai. În următoarele rânduri vom aborda câteva dintre testele de
exemplele de îmbunătățiri de performanță.
4.1. Teste de performanță

Colectarea adreselor
Rularea unei cereri către baza de date SQL pentru a aduce 20 de înregistrări.

Figura 4 -1

Colectarea adreselor și convertirea în TXT
Rularea unei cereri către baza de date SQL pentru a aduce 97.000 de înregistrări și pentru a le
transforma în format .txt.

Figura 4 -2

22

Colectarea adreselor și convertirea în JSON
Rularea unei cereri către baza de date SQL pentru a aduce 97.000 de înregistrări și pentru a le
serializa în format JSON.

Figura 4 -3
Citirea unui fișier PDF de 7MB
Citirea unui fișier de 7MB amplasat în folderol App_Data

Figura 4 -4

Figura 4 -5 reprezintă codul sursă pentru cele două comenzi scrise în .NET Framework
respectiv .NET Core. Ambele metode au rolul de a citi fișierul PDF salvat în folderul
App_Data și de a returna timpii de execuție ca și răspuns.

23

Figura 4 -5

4.2. Exemple de sintaxă

Așa cum am enunțat de mai multe ori și în rândurile anterioare, unul dintre cele mai
mari beneficii și avantaje ale .NET Core este performanța. În continuare, vor urma câtev a
exemple de cod și sintaxă care vor surprinde îmbunătățirile de performanță aduse de .NET
Core.

Colecții (Collections)
Colecțiile sunt baza oricărei aplicații și există o multitudine de colecții disponibile în
bibliotecile .NET. Nu fiecare operațiune din fiecare colecție a fost făcută mai repede, dar
mulți au. Unele dintre aceste îmbunătățiri se datorează eliminării cheltu ielilor generale, cum
ar fi simplificarea operațiunilor pentru a permite o mai bună linie, reducerea numărului de
instrucțiuni ș.a.

24
De exemplu, luați în considerare acest mic exemplu cu o Queue <T>:

Figura 4 -6
Un pull -request venit din partea unui contribuitor la dezvoltarea .NET Core open –
source a eliminat din Enqueue și Dequeue o operație relativ scumpă a modulului care a
dominat costurile acestor operațiuni.
Astfel, acest cod de pe .NET Framework produce următorul rezultat :
00:00:00.9392595
00:00:00.9390453
00:00:00.9455784
00:00:00.9508294
00:00:01.0107745

Pe când, .NET Core produce următorul rezultat:
00:00:00.5514887
00:00:00.5662477
00:00:00.5627481

25
00:00:00.5685286
00:00:00.5262378
Așa cum se poate observa, rezultatele respective denotă o v iteză de 2 ori mai mare în
cazul .NET Core.

LINQ
În codul aplicației, adesea colecțiile merg mână în mână cu Language Integrated
Query (LINQ), care a înregistrat și mai multe îmbunătățiri. Mulți dintre operatorii din LINQ
au fost rescriși în întregime pentru .NET Core pentru a reduce numărul și dimensiunea
alocărilor, reduce complexitatea algoritmică și, în general, elimină munca inutilă.
De exemplu, metoda Enumerable.Concat este utilizată pentru a crea un singur
IEnumerable <T> care dă mai întâi toate elementele unuia dintre cele enumerabile și apoi
toate elementele unei secunde. Implementarea sa în .NET 4.7 este simplă și ușor de înțeles,
reflectând exact această afirmație de comportament:

Figura 4 -7

Acest lucru este la fel de bun cum vă puteți așt epta când cele două secvențe sunt
enumerabile simple precum cele produse de un iterator în C #. Dar dacă, în schimb, codul
aplicației ar arăta în felul următor ?

Figura 4 -8

26
De fiecare dată când cedăm dintr -un iterator, revenim din metoda MoveNext a
enume rătorului. Asta înseamnă că dacă renunțăm la un element din enumerarea unui alt
iterator, returnăm din cele două metode MoveNext, iar trecerea la următorul element necesită
apelarea în ambele metode MoveNext. Cu cât avem mai multe apeluri , cu atât operațiu nea
durează mai mult, mai ales că fiecare dintre aceste operațiuni implică mai multe apeluri de
interfață (MoveNext ș i Current). Aceasta înseamnă reprezintă concatenarea mai multor
enumerabile care vor crește exponențial și nu liniar cu numărul de enumerab ile implicate.
Un pull -request al unui contribuitor la .NET Core open -source a rezolvat această
problem iar diferența este evidentă în următorul exemplu, care concatenează 10.000 de
enumerabile a câte 10 elemente fiecare:

Figura 4 -9
Rezultatul este că, r ularea acestei metode în .NET Framework durează aproximativ
4.12 secunde în timp ce rularea aceleași metode în .NET Core durează 0.14 secunde, ceea ce
înseamnă o îmbunătățire de 30 de ori.

27
Compresia (Compression)
Exemplele prezentate până acum, de colecții și LINQ, au fost despre manipularea
datelor în memorie. Există desigur multe alte forme de manipulare a datelor, inclusiv
transformări care sunt puterni c legate de procesoare . S-au făcut investiții și în îmbunătățirea
acestor operațiuni.
Un exempl u-cheie este compresia prin DeflateStream, din care reies mai multe
modi ficări de performanță . De exemplu, în .NET 4.7, zlib (o bibliotecă nativă de compresie)
este utilizat pentru comprimarea datelor, dar pentru o decomprimare a datelor se folosește o
implementare ges tionată relativ neoptimizată; Pull -request -ul dotnet / corefx # 2906 a
adăugat .NET Core suport pentru utilizarea z lib și pentru decompresie. Și pull -request -ul
dotnet / corefx # 5674 a fost activat folosind o versiune mai optimizată de zlib p rodusă de
Intel. Să în considerare acest exemplu, care creează doar o serie mare de date (destul de
compresibile):

Figura 4 -10

28
În .NET Framework, pentru această operație de compresie / decompresie, rezultatul
obținut este:
00:00:00.7977190
În timp ce în .NET Core, rezultatul este :
00:00:00.1926701

Criptografia (Cryptography)
O altă sursă comună de calcul într -o aplicație .NET este utilizarea operațiunilor
criptografice. Îmbunătățiri pot fi văzute și aici.
De exemplu, în .NET 4.7, SHA256.Create returnea ză un tip SHA256 implementat în
cod gestionat, iar în timp ce codul gestionat poate fi făcut să funcționeze foarte repede, pentru
calcule foarte corelate, este încă greu să concurezi cu procesarea brută și optimizarea
compilatorului. disponibil pentru codu l scris în C / C ++.
În schimb, pentru .NET Core 2.0, SHA256.Create returnează o implementare bazată
pe sistemul de operare de bază, de ex. folosind CNG pe Windows sau OpenSSL pe Unix.
Impactul poate fi observat în acest exemplu simplu care conține un tablou de octeți de 100
MB:

29

Figura 4 -11
În .NET Framework, rezultatul obținut este :
00:00:00.7576808
În timp ce, în .NET Core avem :
00:00:00.4032290
Așadar, avem parte de o nouă îmbunătățire de performanță, care nu a necesitat nicio
modificare în cod.

Math
Operațiunile matematice sunt, de asemenea, o sursă mare de calcul, în special atunci
când este vorba de un număr mare. Prin pull-request -uri precum dotnet / corefx # 2182, s-au
făcut unele îmbunătățiri substanțiale la diverse operațiuni pe BigInteger. Să luăm în
considerare următorul exemplu:

30

Figura 4 -12
Pentru acest calcul, .NET Framework are următorul rezultat:
00:00:05.6024158
În timp ce pentru .NET Core, rezultatul este următorul :
00:00:01.2707089

Acesta este un alt exemplu excelent de dezvoltat or care se ocupă foarte mult de o
anumită zonă de .NET și care ajută la îmbunătățirea nevoilor proprii și a t uturor celor care o
pot folosi.
Chiar și unele operații matematice pe tipurile integrale de bază au fost îmbunătățite.
De exemplu, s ă luăm în considerare:

31

Figura 4 -13
Pull-request -ul #8125 a înlocuit method DivRem, cu o implementare mai rapidă astfel
că pe .NET Framework, rezultatul este:
00:00:01.4143100
În timp ce pe .NET Core, acesta este :
00:00:00.7469733
Avem a șadar o îmbunătățire de 2 ori.

Serializarea (Serialization)
Serializarea binară este un alt domeniu al .NET care poate fi destul de intens pentru
procesor / date / memorie. BinaryFormatter este o componentă care a fost lăsată inițial din
.NET Core, dar reapare în .NET Core 2.0 în sprijinul codului existent care are nevoie de el (în
general, alte forme de serializare sunt recomandate pentru noul cod) .
Componenta este aproape un port identic al codului din .NET 4.7, cu excepția
corecțiilor tactice care i -au fost făcute de atunci, în special în jurul performanței.

32
De exemplu, pull-request -ul # 17949 este o soluție de o linie care mărește
dimensiunea ma ximă la care un anumit tablou are voie să crească, dar că o modificare poate
avea un impact substanțial asupra debitului, permițând o O (N) algoritmul care să funcționeze
mult mai mult decât ar fi avut anterior, înainte de a trece la un algoritm O (N ^ 2). Acest lucru
este evident în următorul exemplu de cod:

Figura 4 -14
Pentru .NET Framework rezultatul rulării acestei metode este
76.677144
În timp ce pentru .NET Core rezultatul este
6.4044694

33
Îmbunătățirea oferă o putere de 12 ori mai mare. Cu alte cuvinte, metoda poate procesa mult
mai multe date într -un mod mult mai eficient.

Procesarea textului (Text Processing)
O altă formă foarte obișnuită de calcul în aplicațiile .NET este procesarea textului și
un număr mare de îmbunătățiri au intrat aici, la diferite niveluri ale stivei.
Luăm în considerare Regex. Acest tip este utilizat în mod obișnuit pentru validarea și
analizarea datelor din textul introdus. Iată un exemplu care folosește Regex.IsMatch pentru a
potrivi în mod repetat numere de telefon:

Figura 4 -15
Pentru .NET Framework rezultatele arată în felul următor
Elapsed=00:00:05.4367262 Gen0=820 Gen1=0 Gen2=0
În timp ce pentru .NET Core, rezultatul este
Elapsed=00:00:04.0231373 Gen0=248

34
Aceasta este o îmbunătățire de ~ 25% a debitului și o reduce re de ~ 70% a colecțiilor
de alocare / gunoi, din cauza unei mici modificări în pull -request -ul # 231 care a făcut o
corecție a modului în care sunt memorate în cache unele date.
Un alt exemplu de procesare a textului este în diferite forme de codificare și decodare,
cum ar fi decodarea URL prin WebUtility.UrlDecode. Adesea se întâmplă în metode de
decodare ca aceasta, intrarea nu are de fapt nevoie de nici o decodare, dar intrarea este încă
trecută prin decodificator în cazul în care o face. Datorită pull-request -ului # 7671, acest caz a
fost optimizat. Deci, de exemplu, cu acest program:

Figura 4 -16
Pentru .NET Framework, rezultatele arată astfel
Elapsed=00:00:01.6742583 Gen0=648
În timp ce pentru .NET Core, ele sunt
Elapsed=00:00:01.2255288 Gen0=133

35

Capitolul 5 . Concluzii

În concluzie, atât .NET Framework și cât și .NET Core sunt platforme puternice de
dezvoltare a software -ului și ambele au avantajele și dezavantaje le lor. Scopul principal este
să determinăm care este cel mai potrivit pentru nevoile noastre, în funcție de proiectul pe care
îl vom construi.
Dacă avem nevoie de o soluție de ultimă generație care să ruleze cat mai rapid, ne
dorim ca aceasta să poată rul a pe orice sistem de operare precum Windows, Linux sau
macOS, și dorim să ne bazăm pe suportul unei întregi comunități de dezvoltatori, atunci
varianta cea mai potrivită este .NET Core.

36

Bibliografie

[1] https://www.amarinfotech.com/difference -between -net-core-2-0-vs-net-framework.html
[2] .NET Framework Essentials – Thuan Thai and Hoang Q. Lam –
https://books.google.ro/books?hl=en&lr=&id=74mxhEyaK s8C&oi=fnd&pg=PR11&dq=.n
et+framework&ots=l4WE2wnA1y&sig=qX4FE1 –
gDCz2aFR9QwzPGDvHnV4&redir_esc=y#v=onepage&q=.net%20framework&f=false
[3] https://docs.microsoft.com/en -us/dotnet/core/about
[4] https://en.wikipedia.org/wiki/.NET_Core
[5] https://docs.microsoft.com/en -us/dotnet/core/porting/index
[6] https://docs.microsoft.com/en -us/dotnet/standard/choosing -core-framework -server
[7] https://books.google.ro/books?id=tRrRDwAAQBAJ&printsec=frontcover&dq=.net+core&hl=en&s
a=X&ved=0ahUKEwjwx7ba3YjqAhXqsosKHahmBZ0Q6AEIKDAA#v=onepage&q=.net%20core&f=fal
se
[8] https://www.mithunvp.com/difference -between -asp-net-mvc6 -asp-net-mvc5/