.NET Core - szybki przewodnik
.NET Core to najnowsza platforma programistyczna ogólnego przeznaczenia obsługiwana przez firmę Microsoft. Działa na różnych platformach i został przeprojektowany w taki sposób, aby .NET był szybki, elastyczny i nowoczesny. Jest to jeden z głównych wkładów firmy Microsoft. Programiści mogą teraz tworzyć aplikacje na Androida, iOS, Linux, Mac i Windows z .NET, wszystko w Open Source.
W tym samouczku omówimy .NET Core i kilka nowych innowacji, w tym aktualizacje .NET Framework, .NET Standard i aktualizacje Universal Windows Platform itp.
Charakterystyka platformy .NET Core
Poniżej przedstawiono główne cechy platformy .NET Core -
Otwarte źródło
NET Core to implementacja typu open source, korzystająca z licencji MIT i Apache 2.
.NET Core to projekt .NET Foundation i jest dostępny w serwisie GitHub.
Jako projekt open source promuje bardziej przejrzysty proces rozwoju i promuje aktywną i zaangażowaną społeczność.
Wieloplatformowy
Aplikację zaimplementowaną w .NET Core można uruchomić, a jej kod ponownie wykorzystać niezależnie od platformy docelowej.
Obecnie obsługuje trzy główne systemy operacyjne (OS)
Windows
Linux
MacOS
Obsługiwane systemy operacyjne (OS), procesory i scenariusze aplikacji będą z czasem rosły, dostarczane przez firmę Microsoft, inne firmy i osoby prywatne.
Elastyczne wdrażanie
Istnieją dwa typy wdrożeń dla aplikacji .NET Core -
Wdrożenie zależne od struktury
Samodzielne wdrażanie
W przypadku wdrożenia zależnego od platformy Twoja aplikacja jest zależna od wersji systemu .NET Core dla całego systemu, na której jest zainstalowana aplikacja i zależności innych firm.
W przypadku samodzielnego wdrażania wersja .NET Core używana do tworzenia aplikacji jest również wdrażana wraz z aplikacją i zależnościami innych firm i może działać równolegle z innymi wersjami.
Narzędzia wiersza poleceń
Wszystkie scenariusze dotyczące produktów można wykonywać z poziomu wiersza poleceń.
Zgodny
.NET Core jest kompatybilny z .NET Framework, Xamarin i Mono, poprzez bibliotekę .NET Standard Library
Modułowe
NET Core jest wydawany za pośrednictwem NuGet w mniejszych pakietach zestawu.
.NET Framework to jeden duży zestaw zawierający większość podstawowych funkcji.
NET Core jest udostępniana jako mniejsze pakiety zorientowane na funkcje.
To modułowe podejście umożliwia deweloperom optymalizację aplikacji poprzez uwzględnienie tylko tych pakietów NuGet, których potrzebują w swojej aplikacji.
Korzyści wynikające z mniejszej powierzchni aplikacji obejmują ściślejsze zabezpieczenia, mniejszą obsługę, lepszą wydajność i niższe koszty w modelu płatności za to, z czego korzystasz.
Platforma .NET Core
Platforma .NET Core zawiera następujące główne części -
.NET Runtime - Zapewnia system typów, ładowanie zestawu, garbage collector, natywną współpracę i inne podstawowe usługi.
Fundamental Libraries - Zestaw bibliotek strukturalnych, które zapewniają prymitywne typy danych, typy kompozycji aplikacji i podstawowe narzędzia.
SDK & Compiler - Zestaw narzędzi SDK i kompilatorów języka, które umożliwiają podstawowe środowisko programistyczne, dostępne w zestawie .NET Core SDK.
‘dotnet’ app host- Służy do uruchamiania aplikacji .NET Core. Wybiera środowisko uruchomieniowe i hostuje środowisko uruchomieniowe, udostępnia zasady ładowania zestawu i uruchamia aplikację. Ten sam host jest również używany do uruchamiania narzędzi SDK w bardzo podobny sposób.
W tym rozdziale omówimy różne zależności, które należy wdrożyć i uruchomić. Należą do nich aplikacje .NET Core na komputerach z systemem Windows, które zostały opracowane przy użyciu programu Visual Studio.
Obsługiwane wersje systemu Windows
NET Core jest obsługiwany w następujących wersjach systemu Windows -
- Windows 7 z dodatkiem SP1
- Windows 8.1
- Windows 10
- Windows Server 2008 R2 z dodatkiem SP1 (pełny serwer lub Server Core)
- Windows Server 2012 SP1 (pełny serwer lub Server Core)
- Windows Server 2012 R2 SP1 (pełny serwer lub Server Core)
- Windows Server 2016 (pełny serwer, Server Core lub Nano Server)
Zależności
Jeśli używasz aplikacji .NET Core w wersjach systemu Windows starszych niż Windows 10 i Windows Server 2016, będzie ona również wymagać pakietu redystrybucyjnego Visual C ++.
Ta zależność jest instalowana automatycznie, jeśli używasz instalatora .NET Core.
Jeśli instalujesz platformę .NET Core za pomocą skryptu instalatora lub wdrażasz samodzielną aplikację .NET Core, musisz ręcznie zainstalować pakiet redystrybucyjny Visual C ++ dla programu Visual Studio 2015.
W przypadku komputerów z systemem Windows 7 i Windows Server 2008 należy upewnić się, że instalacja systemu Windows jest aktualna i zawiera również poprawkę KB2533623 zainstalowaną za pośrednictwem usługi Windows Update.
Wymagania wstępne dotyczące programu Visual Studio
Aby tworzyć aplikacje .NET Core przy użyciu zestawu .NET Core SDK, możesz użyć dowolnego wybranego edytora.
Jeśli jednak chcesz tworzyć aplikacje .NET Core w systemie Windows przy użyciu programu Visual Studio, możesz użyć następujących dwóch wersji -
Visual Studio 2015
Visual Studio 2017 RC
Projekty utworzone w programie Visual Studio 2015 będą domyślnie oparte na projekcie project.json, podczas gdy projekty utworzone w programie Visual Studio 2017 RC będą zawsze oparte na programie MSBuild.
W tym rozdziale omówimy konfigurację środowiska .NET Core. Jest to znaczące przeprojektowanie platformy .NET Framework. Aby używać platformy .NET Core w aplikacji, możesz użyć dwóch wersji -
- Visual Studio 2015
- Visual Studio 2017 RC
Visual Studio 2015
Aby korzystać z programu Visual Studio 2015, musisz mieć zainstalowane następujące elementy -
- Microsoft Visual Studio 2015 Update 3
- Microsoft .NET Core 1.0.1 - wersja zapoznawcza narzędzi VS 2015 2
Firma Microsoft udostępnia bezpłatną wersję programu Visual Studio, która zawiera również SQL Server i można ją pobrać z witryny https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx i Microsoft .NET Core 1.0.1 - VS 2015 Tooling Preview 2 można pobrać z witryny https://www.visualstudio.com/downloads/
Możesz również postępować zgodnie ze wskazówkami dotyczącymi instalacji pod następującym adresem URL https://www.microsoft.com/net/core/#windowsvs2017
Instalacja programu Visual Studio 2015
Wykonaj następujące kroki, aby zainstalować program Visual Studio 2015 -
Step 1- Po zakończeniu pobierania uruchom instalator. Zostanie wyświetlone następujące okno dialogowe.
Step 2 - Kliknij Install aby rozpocząć proces instalacji.
Step 3 - Po zakończeniu instalacji zostanie wyświetlone następujące okno dialogowe.
Step 4 - Zamknij to okno dialogowe iw razie potrzeby uruchom ponownie komputer.
Step 5- Otwórz program Visual Studio z menu Start; pojawi się następujące okno dialogowe. Ładowanie może zająć kilka minut i ostatecznie zostanie użyte po raz pierwszy.
Step 6 - Po załadowaniu zobaczysz następujący ekran.
Step 7 - Po zakończeniu instalacji programu Visual Studio zamknij program Visual Studio i uruchom Microsoft .NET Core - VS 2015 Tooling Preview 2.
Step 8 - Zaznacz pole wyboru i kliknij Zainstaluj.
Step 9 - Po zakończeniu instalacji zostanie wyświetlone następujące okno dialogowe.
Możesz teraz uruchomić aplikację przy użyciu platformy .NET Core.
Visual Studio 2017
W tym samouczku będziemy używać programu Visual Studio 2015, ale jeśli chcesz korzystać z programu Visual Studio 2017, eksperymentalna wersja narzędzi .NET Core dla programu Visual Studio jest zawarta w programie Visual Studio 2017 RC i możesz zobaczyć wytyczne dotyczące instalacji tutaj https://www.microsoft.com/net/core/#windowsvs2017
Visual Studio 2015 zapewnia w pełni funkcjonalne środowisko programistyczne do tworzenia aplikacji .NET Core. W tym rozdziale będziemy tworzyć nowy projekt w programie Visual Studio. Po zainstalowaniu narzędzi programu Visual Studio 2015 możesz rozpocząć tworzenie nowej aplikacji .NET Core.
w New Project W oknie dialogowym na liście szablonów rozwiń węzeł Visual C # i wybierz .NET Core, a powinieneś zobaczyć następujące trzy nowe szablony projektów
- Biblioteka klas (.NET Core)
- Aplikacja konsolowa (.NET Core)
- Aplikacja sieci Web ASP.NET Core (.NET Core)
W środkowym okienku w oknie dialogowym Nowy projekt wybierz opcję Aplikacja konsoli (.NET Core) i nadaj jej nazwę „FirstApp”, a następnie kliknij przycisk OK.
Program Visual Studio otworzy nowo utworzony projekt, aw oknie Eksploratora rozwiązań zobaczysz wszystkie pliki, które znajdują się w tym projekcie.
Aby sprawdzić, czy aplikacja konsoli .NET core działa, dodajmy następujący wiersz.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
namespace FirstApp {
public class Program {
public static void Main(string[] args) {
Console.WriteLine("Hello guys, welcome to .NET Core world!");
}
}
}
Teraz uruchom aplikację. Powinieneś zobaczyć następujące dane wyjściowe.
NET Core obsługuje standardowe liczbowe integralne i zmiennoprzecinkowe prymitywy. Obsługuje również następujące typy -
System.Numerics.BigInteger, który jest typem całkowitym bez górnej ani dolnej granicy.
System.Numerics.Complex to typ reprezentujący liczby zespolone.
Zestaw typów wektorów z włączoną funkcją Single Instruction Multiple Data (SIMD) w przestrzeni nazw System.Numerics.
Typy całkowe
NET Core obsługuje zarówno liczby całkowite ze znakiem, jak i bez znaku o różnych zakresach długości od jednego bajtu do ośmiu bajtów. Wszystkie liczby całkowite są typami wartości.
Poniższa tabela przedstawia typy całkowite i ich rozmiar;
Rodzaj | Podpisano / niepodpisano | Rozmiar (bajty) | Minimalna wartość | Maksymalna wartość |
---|---|---|---|---|
Bajt | Bez podpisu | 1 | 0 | 255 |
Int16 | Podpisano | 2 | -32,768 | 32,767 |
Int32 | Podpisano | 4 | -2,147,483,648 | 2,147,483,647 |
Int64 | Podpisano | 8 | -9,223,372,036,854,775,808 | 9.223.372.036.854.775.807 |
SByte | Podpisano | 1 | -128 | 127 |
UInt16 | Bez podpisu | 2 | 0 | 65,535 |
UInt32 | Bez podpisu | 4 | 0 | 4.294.967.295 |
UInt64 | Bez podpisu | 8 | 0 | 18,446,744,073,709,551,615 |
Każdy typ całkowity obsługuje standardowy zestaw operatorów arytmetycznych, porównania, równości, konwersji jawnej i niejawnej konwersji.
Możesz również pracować z pojedynczymi bitami w wartości całkowitej, używając klasy System.BitConverter.
Typy zmiennoprzecinkowe
NET Core zawiera trzy pierwotne typy zmiennoprzecinkowe, które są pokazane w poniższej tabeli.
Rodzaj | Rozmiar (bajty) | Minimalna wartość | Maksymalna wartość |
---|---|---|---|
Podwójnie | 8 | −1,79769313486232e308 | 1.79769313486232e308 |
Pojedynczy | 4 | −3.402823e38 | 3.402823e38 |
Dziesiętny | 16 | −79.228.162.514.264.337.593,5 43.950.335 | 79,228,162,514,264,337,593,543,9 50,335 |
Każdy typ zmiennoprzecinkowy obsługuje standardowy zestaw operatorów arytmetycznych, porównania, równości, jawnej konwersji i niejawnej konwersji.
Możesz także pracować z pojedynczymi bitami w wartościach Double i Single, używając klasy BitConverter.
Struktura Decimal ma swoje własne metody, Decimal.GetBits i Decimal.Decimal (Int32 ()), służące do pracy z poszczególnymi bitami wartości dziesiętnej, a także własny zestaw metod do wykonywania dodatkowych operacji matematycznych.
BigInteger
System.Numerics.BigInteger jest niezmiennym typem, który reprezentuje dowolnie dużą liczbę całkowitą, której wartość w teorii nie ma górnej ani dolnej granicy.
Metody typu BigInteger są ściśle równoległe do metod innych typów całkowitych.
Złożony
Typ System.Numerics.Complex reprezentuje liczbę zespoloną, tj. Liczbę składającą się z części liczby rzeczywistej i części urojonej
Obsługuje standardowy zestaw operatorów arytmetycznych, porównawczych, równości, konwersji jawnej i niejawnej konwersji, a także metody matematyczne, algebraiczne i trygonometryczne.
SIMD
Przestrzeń nazw Numerics zawiera zestaw typów wektorów z obsługą SIMD dla platformy .NET Core.
SIMD umożliwia zrównoleglenie niektórych operacji na poziomie sprzętowym, co skutkuje ogromną poprawą wydajności aplikacji matematycznych, naukowych i graficznych, które wykonują obliczenia na wektorach.
Typy wektorowe z obsługą SIMD w .NET Core obejmują następujące -
Typy System.Numerics.Vector2, System.Numerics.Vector3 i System.Numerics.Vector4, które są dwu-, trzy- i czterowymiarowymi wektorami typu Single.
Struktura Vector <T>, która umożliwia tworzenie wektorów dowolnego pierwotnego typu liczbowego. Pierwotne typy liczbowe obejmują wszystkie typy liczbowe w przestrzeni nazw System, z wyjątkiem Decimal.
Dwa typy macierzy, System.Numerics.Matrix3 × 2, które reprezentują macierz 3 × 2; i System.Numerics.Matrix4 × 4, co reprezentuje macierz 4 × 4.
Typ System.Numerics.Plane, który reprezentuje trójwymiarową płaszczyznę, oraz typ System.Numerics.Quaternion, który reprezentuje wektor używany do kodowania trójwymiarowych obrotów fizycznych.
W tym rozdziale zajmiemy się koncepcją czyszczenia pamięci, która jest jedną z najważniejszych funkcji platformy kodu zarządzanego .NET. Moduł odśmiecania pamięci (GC) zarządza alokacją i zwalnianiem pamięci. Moduł odśmiecania służy jako automatyczny menedżer pamięci.
Nie musisz wiedzieć, jak przydzielać i zwalniać pamięć ani zarządzać okresem życia obiektów, które używają tej pamięci
Alokacja jest dokonywana za każdym razem, gdy deklarujesz obiekt za pomocą słowa kluczowego „new” lub umieszczasz w ramce typ wartości. Alokacje są zazwyczaj bardzo szybkie
Gdy nie ma wystarczającej ilości pamięci do przydzielenia obiektu, GC musi zebrać i usunąć pamięć bezużyteczną, aby udostępnić pamięć dla nowych alokacji.
Ten proces jest znany jako garbage collection.
Zalety zbierania śmieci
Usługa Garbage Collection zapewnia następujące korzyści -
Nie musisz ręcznie zwalniać pamięci podczas tworzenia aplikacji.
Efektywnie alokuje również obiekty na zarządzanej stercie.
Gdy obiekty nie są już używane, odzyskuje te obiekty poprzez wyczyszczenie ich pamięci i zachowuje pamięć dostępną dla przyszłych alokacji.
Zarządzane obiekty automatycznie uzyskują czystą zawartość na początku, więc ich konstruktorzy nie muszą inicjować każdego pola danych.
Zapewnia również bezpieczeństwo pamięci, upewniając się, że obiekt nie może używać zawartości innego obiektu.
Warunki wyrzucania elementów bezużytecznych
Wyrzucanie elementów bezużytecznych występuje, gdy spełniony jest jeden z następujących warunków.
System ma mało pamięci fizycznej.
Pamięć używana przez przydzielone obiekty na zarządzanej stercie przekracza dopuszczalny próg. Ten próg jest stale dostosowywany w trakcie procesu.
Plik GC.Collectmetoda jest wywoływana iw prawie wszystkich przypadkach nie musisz wywoływać tej metody, ponieważ moduł odśmiecania pamięci działa w sposób ciągły. Ta metoda jest używana głównie w wyjątkowych sytuacjach i testach.
Pokolenia
NET ma 3 generacje, a każda generacja ma swoją własną stertę, która jest używana do przechowywania przydzielonych obiektów. Istnieje podstawowa zasada, że większość obiektów jest albo krótkotrwała, albo długowieczna.
Pierwsza generacja (0)
W generacji 0 obiekty są najpierw przydzielane.
W tej generacji obiekty często nie istnieją po pierwszej generacji, ponieważ nie są już używane (poza zakresem) do czasu następnego czyszczenia pamięci.
Generację 0 można szybko zebrać, ponieważ powiązana z nią sterta jest niewielka.
Generacja druga (1)
W Generacji 1 obiekty mają miejsce drugiej szansy.
Obiekty, które są krótkotrwałe, ale przetrwały kolekcję generacji 0 (często oparte na przypadkowym czasie), przechodzą do generacji 1.
Kolekcje generacji 1 są również szybkie, ponieważ powiązany z nimi stos jest również niewielki.
Pierwsze dwa sterty pozostają małe, ponieważ obiekty są zbierane lub promowane do sterty następnej generacji.
Trzecia generacja (2)
W generacji 2 żyją wszystkie długie obiekty, a ich stos może urosnąć do bardzo dużego.
Obiekty tej generacji mogą przetrwać długi czas i nie ma stosu następnej generacji, który mógłby dalej promować obiekty.
Garbage Collector posiada dodatkową stertę dla dużych obiektów zwaną Large Object Heap (LOH).
Jest zarezerwowany dla obiektów, które mają 85 000 bajtów lub więcej.
Duże obiekty nie są przydzielane do pryzm pokoleniowych, ale są przydzielane bezpośrednio do LOH
Kolekcje generacji 2 i LOH mogą zająć zauważalny czas w przypadku programów, które działają przez długi czas lub działają na dużych ilościach danych.
Wiadomo, że duże programy serwerowe mają stosy w dziesiątkach GB.
GC wykorzystuje różnorodne techniki, aby skrócić czas blokowania wykonywania programu.
Podstawowym podejściem jest wykonanie jak największej ilości operacji usuwania elementów bezużytecznych w wątku w tle w sposób, który nie koliduje z wykonywaniem programu.
GC udostępnia również programistom kilka sposobów wpływania na jego zachowanie, co może być bardzo przydatne w celu poprawy wydajności.
W tym rozdziale poznamy proces wykonywania .NET Core i porównamy go z .NET Framework. Zarządzany proces wykonywania obejmuje następujące kroki.
- Wybór kompilatora
- Kompilowanie kodu do MSIL
- Kompilowanie MSIL do kodu natywnego
- Uruchomiony kod
Wybór kompilatora
Jest to wielojęzyczne środowisko wykonawcze, które obsługuje szeroką gamę typów danych i funkcji językowych.
Aby uzyskać korzyści zapewniane przez środowisko uruchomieniowe języka wspólnego, należy użyć co najmniej jednego kompilatora języka, który jest przeznaczony dla środowiska uruchomieniowego.
Kompilowanie kodu do MSIL
Kompilowanie tłumaczy kod źródłowy na język pośredni firmy Microsoft (MSIL) i generuje wymagane metadane.
Metadane opisują typy w kodzie, w tym definicje każdego typu, podpisy elementów członkowskich każdego typu, elementy członkowskie, do których odwołuje się kod, oraz inne dane używane przez środowisko uruchomieniowe w czasie wykonywania.
Środowisko wykonawcze lokalizuje i wyodrębnia metadane z pliku, a także z bibliotek klas frameworka (FCL) w razie potrzeby podczas wykonywania.
Kompilowanie MSIL do kodu natywnego
W czasie wykonywania kompilator just-in-time (JIT) tłumaczy MSIL na kod natywny.
Podczas tej kompilacji kod musi przejść proces weryfikacji, który sprawdza MSIL i metadane, aby dowiedzieć się, czy kod można określić jako bezpieczny dla typów.
Działający kod
Środowisko uruchomieniowe języka wspólnego zapewnia infrastrukturę umożliwiającą wykonanie oraz usługi, które mogą być używane podczas wykonywania.
Podczas wykonywania kod zarządzany otrzymuje usługi, takie jak wyrzucanie elementów bezużytecznych, zabezpieczenia, współdziałanie z kodem niezarządzanym, obsługę debugowania w wielu językach oraz ulepszoną obsługę wdrażania i wersjonowania.
Proces wykonywania kodu .NET Core
Teraz porównajmy sposób wykonywania kodu w .NET Core w porównaniu z .NET Framework. W .NET Core istnieje wiele zamienników tych składników, które są częścią .NET Framework.
W .NET Core mamy teraz nową serię kompilatorów, podobnie jak Roslyn dla C # i VB.
Możesz również skorzystać z nowego kompilatora F # 4.1, jeśli chcesz używać F # z .NET Core.
W rzeczywistości te narzędzia są różne i możemy używać Roslyn również z .NET Framework, jeśli używamy C # 6 lub nowszego, ponieważ kompilator C # może obsługiwać tylko do C # 5.
W .NET Core nie mamy bibliotek klas frameworków (FCL), więc używany jest inny zestaw bibliotek i teraz mamy CoreFx.
CoreFx to reimplementacja bibliotek klas dla platformy .NET Core.
Mamy również nowy czas wykonywania z .NET Core znany jako CoreCLR i wykorzystuje kompilator JIT.
Teraz pytanie brzmi, dlaczego mamy reimplementację wszystkich tych komponentów, które już mamy w .NET Framework.
Więc odpowiedź jest taka sama, jak dlaczego Microsoft wdrożył .NET Core.
Kolejną kwestią dotyczącą platformy .NET Core jest tworzenie i wdrażanie aplikacji, która jest modułowa. Zamiast instalować całe oprogramowanie .NET Framework, Twoja aplikacja może teraz zainstalować tylko to, co jest wymagane. Przejdźmy do studia wizualnego i zobaczmy modułowość.
Oto nasza prosta aplikacja .NET Core w Eksploratorze rozwiązań. Rozwińmy References, a zobaczysz odniesienie do .NETCoreApp
Wewnątrz .NETCoreApp zobaczysz odwołanie do pakietu NuGet; pozwól nam go rozszerzyć.
Zobaczysz całą serię odwołań do pakietu NuGet. Jeśli pracujesz w .NET Framework, wiele z tych przestrzeni nazw będzie wyglądać znajomo, ponieważ jesteś do tego przyzwyczajony, korzystając z .NET Framework.
.NET Framework jest podzielony na wiele różnych części i ponownie zaimplementowany z CoreFx; elementy te są dalej rozprowadzane jako pojedyncze opakowania.
Teraz, jeśli rozwiniesz NETStandard.Library, zobaczysz dodatkowe odwołania. Zauważysz nawet Konsolę System.Console, której używamy w tej aplikacji.
Teraz nie musisz wprowadzać wszystkiego do środowiska .NET Framework, ale po prostu wprowadź to, czego potrzebujesz do swojej aplikacji.
Są też inne korzyści; na przykład moduły te można w razie potrzeby aktualizować indywidualnie.
Modułowość zapewnia korzyści w zakresie wydajności, a aplikacja może działać szybciej, zwłaszcza aplikacja ASP.NET Core.
W tym rozdziale omówimy pliki projektu .NET Core i sposoby dodawania istniejących plików do projektu.
Rozumiemy prosty przykład, w którym mamy już utworzone pliki; musimy dodać te pliki w naszym projekcie FirstApp.
Oto implementacja Student.cs plik
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
namespace FirstApp {
public class Student {
public int ID { get; set; }
public string LastName { get; set; }
public string FirstMidName { get; set; }
public DateTime EnrollmentDate { get; set; }
}
}
Oto implementacja Course.cs plik.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
namespace FirstApp {
public class Course {
public int CourseID { get; set; }
public string Title { get; set; }
public int Credits { get; set; }
}
}
Zapiszmy teraz te trzy pliki na dysku i w folderze źródłowym projektu.
Jeśli znasz .NET, a ta była tradycyjną aplikacją konsoli .NET Framework, ważne jest, aby zrozumieć, jak dodać te pliki do projektu w programie Visual Studio.
Najpierw musisz przeciągnąć pliki do eksploratora rozwiązań, aby skopiować je do folderu projektu, ponieważ projekt wymaga odwołania do tych plików.
Jedną z zalet platformy .NET Core jest podejście przyjęte z plikiem projektu (project.json); możemy po prostu upuścić pliki w katalogu głównym naszego projektu, a wtedy zostaną one automatycznie uwzględnione w naszym projekcie.
Nie musimy ręcznie odwoływać się do plików, jak robiliśmy to w przeszłości w przypadku tradycyjnej aplikacji .NET Framework w programie Visual Studio.
Otwórzmy teraz katalog główny twojego projektu.
Skopiujmy teraz wszystkie trzy pliki do katalogu głównego twojego projektu.
Możesz teraz zobaczyć wszystkie pliki skopiowane do folderu głównego.
Przejdźmy teraz do Visual Studio; pojawi się następujące okno dialogowe.
Kliknij Yes to All aby ponownie załadować swój projekt.
Teraz zauważysz, że pliki są automatycznie dołączane do twojego projektu.
W tym rozdziale omówimy, jak dodawać pakiety do aplikacji .NET Core i jak znaleźć konkretny pakiet. Możemy przejść bezpośrednio do NuGet i dodać pakiet, ale tutaj zobaczymy kilka innych miejsc.
Przejdźmy teraz do kodu źródłowego .NET Core, który znajduje się tutaj - https://github.com/dotnet/corefx
W repozytorium CoreFx otwórz plik src folder -
Zobaczysz całą listę folderów odpowiadających różnym pakietom. Wyszukajmy teraz Json -
Istnieje inny sposób znalezienia pakietu, prawdopodobnie znasz różne typy, jeśli znasz .NET Framework, ale składanie pakietów w .NET Core jest zupełnie inne i nie będziesz wiedział, gdzie te pakiety się znajdują.
Jeśli znasz typ, możesz wyszukać odwrotne wyszukiwanie pakietów za pomocą https://packagesearch.azurewebsites.net/
Tutaj możesz wprowadzić dowolny typ pakietu, który chcesz znaleźć. Następnie ta witryna przeskanuje NuGet i znajdzie odpowiednie pakiety.
Wyszukajmy teraz DataContractJson.
Zobaczysz teraz, że otrzymujemy ten sam pakiet; kliknijmy na pakiet.
Zobaczysz teraz stronę NuGet; Musisz potwierdzić, że potrzebujesz tego pakietu. Możesz dodać to do swojej aplikacji na kilka sposobów.
Otwórzmy plik project.json.
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
}
To jest nowy format projektu i wewnątrz tego pliku zobaczysz sekcję zależności. Dodajmy nową zależność, jak pokazano poniżej.
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"System.Runtime.Serialization.Json": "4.0.2"
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
}
Teraz, jeśli spojrzysz na swoje referencje, zobaczysz to System.Runtime.Serialization.Json pakiet zostanie dodany do twojego projektu.
Innym sposobem jest przejście do Menedżera NuGet i przeglądanie pakietu, który chcesz dodać.
W tym rozdziale omówimy sposób tworzenia aplikacji UWP przy użyciu platformy .NET Core. Platforma UWP jest również znana jako aplikacja UWP systemu Windows 10. Ta aplikacja nie działa w poprzednich wersjach systemu Windows, ale będzie działać tylko w przyszłych wersjach systemu Windows.
Poniżej przedstawiono kilka wyjątków, w których platforma UWP będzie działać płynnie.
Jeśli chcesz uruchomić go lokalnie, musisz mieć Windows 10, możesz również programować na Windows 8 i wtedy będziesz musiał uruchomić go na Emulatorze, ale zachęcamy do korzystania z Windows 10.
W przypadku aplikacji UWP potrzebny będzie również zestaw SDK systemu Windows 10. Otwórzmy Instalatora programu Visual Studio 2015, a następnie zmodyfikujmy Visual Studio.
Na stronie wyboru funkcji przewiń w dół, a zobaczysz Universal Windows App Development Tools, zaznacz tę opcję, jak pokazano poniżej.
Tutaj możesz zobaczyć różne wersje SDK i najnowszą aktualizację narzędzi, kliknij Dalej.
Teraz kliknij Install przycisk.
Po zakończeniu instalacji konieczne będzie ponowne uruchomienie systemu.
Zaimplementujmy teraz platformę UWP, wykonując następujące kroki.
Najpierw uruchom program Visual Studio 2015.
Kliknij menu Plik i wybierz Nowy → Projekt; pojawi się okno dialogowe Nowy projekt. Możesz zobaczyć różne typy szablonów w lewym panelu okna dialogowego.
W lewym panelu możesz zobaczyć widok drzewa, teraz wybierz szablon uniwersalny z Templates → Visual C # → Windows.
W środkowym okienku wybierz szablon Pusta aplikacja (uniwersalny system Windows).
Nadaj nazwę projektowi, wpisując UWPFirstApp w polu Nazwa i kliknij OK.
Zostanie wyświetlone okno dialogowe wersji docelowej / wersji minimalnej. Domyślne ustawienia są odpowiednie dla tego samouczka, więc wybierz OK, aby utworzyć projekt.
Tutaj mamy jeden projekt, który może być przeznaczony dla wszystkich urządzeń z systemem Windows 10, a zauważysz, że zarówno .NET Core, jak i UWP upraszczają kierowanie na wiele celów.
Po otwarciu nowego projektu jego pliki są wyświetlane po prawej stronie okienka Eksplorator rozwiązań. Aby wyświetlić pliki, może być konieczne wybranie karty Eksplorator rozwiązań zamiast karty Właściwości.
Chociaż Pusta aplikacja (uniwersalne okno) jest minimalnym szablonem, nadal zawiera wiele plików. Te pliki są niezbędne dla wszystkich aplikacji platformy UWP używających języka C #. Każdy projekt utworzony w programie Visual Studio zawiera pliki.
Aby zobaczyć działający przykład, otwórzmy MainPage.XAML i dodaj następujący kod.
<Page
x:Class = "UWPFirstApp.MainPage"
xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x = "http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local = "using:UWPFirstApp"
xmlns:d = "http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc = "http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable = "d">
<Grid Background = "{ThemeResource ApplicationPageBackgroundThemeBrush}">
<StackPanel HorizontalAlignment = "Center">
<TextBlock Text = "Hello, world!"
Margin = "20"
Width = "200"
HorizontalAlignment = "Left"/>
<TextBlock Text = "Write your name."
Margin = "20"
Width = "200"
HorizontalAlignment = "Left"/>
<TextBox x:Name = "txtbox"
Width = "280"
Margin = "20"
HorizontalAlignment = "Left"/>
<Button x:Name = "button" Content = "Click Me"
Margin = "20"
Click = "button_Click"/>
<TextBlock x:Name = "txtblock"
HorizontalAlignment = "Left"
Margin = "20"/>
</StackPanel>
</Grid>
</Page>
Poniżej znajduje się zdarzenie kliknięcia przycisku w C #.
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Runtime.InteropServices.WindowsRuntime;
using Windows.Foundation;
using Windows.Foundation.Collections;
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Controls.Primitives;
using Windows.UI.Xaml.Data;
using Windows.UI.Xaml.Input;
using Windows.UI.Xaml.Media;
using Windows.UI.Xaml.Navigation;
// The Blank Page item template is documented at
// http://go.microsoft.com/fwlink/?LinkId=402352&clcid=0x409
namespace UWPHellowWorld {
/// <summary>
/// An empty page that can be used on its own or navigated to within a Frame.
/// </summary>
public sealed partial class MainPage : Page {
public MainPage() {
this.InitializeComponent();
}
private void button_Click(object sender, RoutedEventArgs e) {
if (txtbox.Text != "")
txtblock.Text = "Hello: " + txtbox.Text;
else
txtblock.Text = "You have not write your name";
}
}
}
Uruchommy teraz powyższy kod na komputerze lokalnym, a zobaczysz następujące okno. Teraz wpisz dowolną nazwę w polu tekstowym i naciśnijClick Me przycisk.
W tym rozdziale omówimy, czym jest MSBuild i jak działa z .NET Core. MSBuild to platforma kompilacji dla programów Microsoft i Visual Studio. W aplikacji UWP, jeśli otworzysz folder projektu, zobaczysz pliki project.json i * .csproj.
Ale jeśli otworzysz naszą poprzednią aplikację .NET Core Console, zobaczysz pliki project.json i * .xproj.
System kompilacji .NET Core lub system kompilacji project.json nie jest wystarczający dla potrzeb platformy UWP; z tego powodu platforma UWP nadal używa systemu budowania * .csproj (MSBuild).
Ale project.json zostanie usunięta, jeśli chodzi o system kompilacji.
Teraz, jeśli chcesz dodać kilka istniejących plików do aplikacji UWP, tak jak dodaliśmy w aplikacji Console, musisz dodać te pliki do folderu projektu. Ponadto należy również uwzględnić w projekcie w Eksploratorze rozwiązań.
Rozważmy teraz następujące pliki; skopiuj te pliki do folderu projektu.
Wróćmy do programu Visual Studio i otwórz Eksplorator rozwiązań.
Teraz widać, że samo kopiowanie plików nie jest wystarczające w przypadku aplikacji UWP, bo w Solution Explorer tych plików nie widzimy.
Teraz musimy również dołączyć te pliki, klikając Show All Files ikonę, jak zaznaczono na powyższym zrzucie ekranu, a zobaczysz teraz wszystkie pliki w folderze projektu.
Te dwa pliki nadal nie są zawarte w naszym projekcie. Aby dołączyć te pliki, wybierz te pliki i kliknij prawym przyciskiem myszy dowolny plik, a następnie wybierzInclude in Project.
Teraz te pliki są również dołączone. Jedną z dobrych rzeczy, które można przewidzieć, jest podejście project.json polegające na usuwaniu plików dla * .csproj w przyszłej wersji narzędzi SKD, a także do programu Visual Studio.
W tym rozdziale omówimy odniesienia między naszą aplikacją Console i naszą aplikacją UWP. Jeśli spojrzysz na odwołania w Eksploratorze rozwiązań aplikacji konsoli, zobaczysz .NETCoreApp, jak pokazano poniżej.
.NETCoreApp to nowa platforma przeznaczona dla aplikacji .NET Core. Teraz, jeśli spojrzysz pod Odnośniki aplikacji UWP, będzie wyglądać nieco inaczej, jak pokazano poniżej.
Głównym tego powodem jest to, że tutaj w UWP mamy * .csproj, więc wracamy do starego stylu odwołań i możemy kierować tylko jedną platformę z tym typem projektu.
Odniesienia są jednak podobne. Teraz widać, że w aplikacji platformy UWP odwołanie do pakietu NuGet Miscrosoft.NETCore.UniversalWindowsPlatform jest podobne do odwołania do Microsoft.NETCore.App NuGet w aplikacji konsoli.
Zarówno Miscrosoft.NETCore.UniversalWindowsPlatform, jak i Microsoft.NETCore.App są metapakietami, co oznacza, że składają się z innych pakietów.
W aplikacji Console możemy drążyć i przeglądać inne pakiety wewnątrz Microsoft.NETCore.App, ale nie możemy zrobić tego samego Miscrosoft.NETCore.UniversalWindowsPlatform w Solution Explorer.
Możemy jednak użyć innego narzędzia, Eksploratora pakietów NuGet, aby się temu przyjrzeć. Otwórzmy teraz ten adres URL w przeglądarce -https://npe.codeplex.com/downloads/get/clickOnce/NuGetPackageExplorer.application a zobaczysz pobieranie małego narzędzia.
Po zakończeniu pobierania kliknij dwukrotnie ten plik.
Kliknij Install aby rozpocząć instalację w Eksploratorze pakietów NuGet.
Po zakończeniu instalacji zostanie wyświetlone następujące okno dialogowe.
Kliknijmy teraz Open a package from online feed opcja.
Domyślnie wyszuka źródło danych nuget.org. Wyszukajmy teraz Microsoft.NETCore.UniversalWindowsPlatform w polu wyszukiwania, a zobaczysz 1 wynik, jak pokazano poniżej.
Kliknij open link i otworzy zależności najwyższego poziomu tego metapakietu.
Otwórzmy teraz obok siebie metapakiet .NETCore dla aplikacji .NETCore i metapakiet dla aplikacji UWP.
Możesz teraz zobaczyć, że każdy metapakiet składa się z innego zestawu pakietów.
.NET Core jest podzbiorem klas dostępnych w .NET Framework przynajmniej w tym momencie, ale rośnie i będzie odpowiadał klasom bazowym .NET Framework.
Platforma UWP jest oparta na platformie .NET Core i stanowi nadzbiór interfejsów API dostępnych do programowania w Sklepie Windows.
Teraz mamy więcej interfejsów API dostępnych do programowania dzięki .NET Core.
Składniki środowiska wykonawczego systemu Windows to niezależne obiekty, których można tworzyć i używać z dowolnego języka, w tym C #, Visual Basic, JavaScript i C ++. Oprócz meta-pakietu .NET Core, który widzieliśmy w poprzednim rozdziale, aplikacja UWP domyślnie zawiera również odniesienie do uniwersalnego zestawu Windows SDK.
Universal Windows to odniesienie do środowiska wykonawczego Windows i zostało uwzględnione w szeregu kontraktów API.
Zestaw interfejsów API w rodzinie urządzeń jest podzielony na podgrupy zwane kontraktami API. Listę różnych kontraktów API znajdziesz tutajhttps://msdn.microsoft.com/en-us/library/windows/apps/dn706135.aspx
Większość tych interfejsów API w środowisku wykonawczym systemu Windows jest uwzględniona w pojedynczym kontrakcie. Poszukajmy teraz słowa kluczowego Universal na stronie Kontrakty API.
Możesz zobaczyć linki do różnych API, a także możesz zobaczyć, że rodzina Universal jest tak duża, że ma 12 stron dokumentacji.
Na tej stronie możesz również wyszukać umowę API telefonu.
Kliknijmy teraz Windows.Phone.PhoneContracti przewiń w dół; zobaczysz teraz informacje o baterii telefonu lub urządzenia mobilnego.
Jeśli chcesz dodać te informacje do tego, co już masz, powinieneś dodać odniesienia ręcznie. Przejdźmy teraz do programu Visual Studio i kliknij prawym przyciskiem myszy odwołania w Eksploratorze rozwiązań.
Wybierz Add References…
Możesz teraz zobaczyć nową kategorię referencyjną dla Universal Windows; w tej kategorii znajduje się Core, który odnosi się do podstawowych kontraktów Universal Windows API
Rozszerzenia pozwalają nam rozszerzyć funkcjonalność, a zobaczysz różne odniesienia do rozszerzeń mobilnych, stacjonarnych i innych.
Istnieją różne rozszerzenia SKD i możesz je dodać, aby uzyskać więcej interfejsów API.
Możesz także zobaczyć różne wersje. Dlatego upewnij się, że masz najnowszą wersję, aby pobrać zaktualizowane interfejsy API, a następnie kliknij przycisk OK.
Teraz możesz to zobaczyć Windows Mobile Extensions for the UWP jest dodawany jako odniesienie.
Biblioteka klas definiuje typy i metody, które można wywołać z dowolnej aplikacji.
Biblioteka klas opracowana przy użyciu platformy .NET Core obsługuje bibliotekę .NET Standard Library, która umożliwia wywoływanie biblioteki przez dowolną platformę .NET obsługującą tę wersję biblioteki standardowej .NET.
Kiedy skończysz swoją bibliotekę klas, możesz zdecydować, czy chcesz ją rozprowadzać jako komponent innej firmy, czy też chcesz dołączyć ją jako komponent, który jest dołączony do jednej lub więcej aplikacji.
Zacznijmy od dodania projektu biblioteki klas w naszej aplikacji Console; kliknij prawym przyciskiem myszy pliksrc folder w Eksploratorze rozwiązań i wybierz Add → New Project…
w Add New Project W oknie dialogowym wybierz węzeł .NET Core, a następnie wybierz szablon projektu biblioteki klas (.NET Core).
W polu tekstowym Nazwa wprowadź „UtilityLibrary” jako nazwę projektu, jak pokazano na poniższym rysunku.
Kliknij przycisk OK, aby utworzyć projekt biblioteki klas. Po utworzeniu projektu dodajmy nową klasę. Kliknij prawym przyciskiem myszyproject w Eksploratorze rozwiązań i wybierz Add → Class...
Wybierz klasę w środkowym okienku i wprowadź StringLib.cs w nazwie i polu, a następnie kliknij Add. Po dodaniu klasy zamień następujący kod w pliku StringLib.cs.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
namespace UtilityLibrary {
public static class StringLib {
public static bool StartsWithUpper(this String str) {
if (String.IsNullOrWhiteSpace(str))
return false;
Char ch = str[0];
return Char.IsUpper(ch);
}
public static bool StartsWithLower(this String str) {
if (String.IsNullOrWhiteSpace(str))
return false;
Char ch = str[0];
return Char.IsLower(ch);
}
public static bool StartsWithNumber(this String str) {
if (String.IsNullOrWhiteSpace(str))
return false;
Char ch = str[0];
return Char.IsNumber(ch);
}
}
}
Biblioteka klas, UtilityLibrary.StringLib, zawiera metody takie jak: StartsWithUpper, StartsWithLower, i StartsWithNumber która zwraca wartość logiczną, która wskazuje, czy bieżące wystąpienie ciągu zaczyna się odpowiednio od dużej, małej litery i liczby.
W programie .NET Core Char.IsUpper metoda zwraca wartość true, jeśli znak jest pisany wielką literą, metoda Char.IsLower zwraca wartość true, jeśli znak jest zapisany małymi literami, i podobnie metoda Char.IsNumber zwraca wartość true, jeśli znak jest liczbą.
Na pasku menu wybierz opcję Kompiluj, kompiluj rozwiązanie. Projekt powinien się skompilować bez błędów.
Nasz projekt konsoli .NET Core nie ma dostępu do naszej biblioteki klas.
Teraz, aby korzystać z tej biblioteki klas, musimy dodać odwołanie do tej biblioteki klas w naszym projekcie konsoli.
Aby to zrobić, rozwiń FirstApp, kliknij prawym przyciskiem myszy Referencje i wybierz Add Reference…
W oknie dialogowym Menedżer odniesień wybierz opcję UtilityLibrary, nasz projekt biblioteki klas, a następnie kliknij przycisk OK.
Otwórzmy teraz plik Program.cs projektu konsoli i zamień cały kod na następujący kod.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using UtilityLibrary;
namespace FirstApp {
public class Program {
public static void Main(string[] args) {
int rows = Console.WindowHeight;
Console.Clear();
do {
if (Console.CursorTop >= rows || Console.CursorTop == 0) {
Console.Clear();
Console.WriteLine("\nPress <Enter> only to exit; otherwise, enter a string and press <Enter>:\n");
}
string input = Console.ReadLine();
if (String.IsNullOrEmpty(input)) break;
Console.WriteLine("Input: {0} {1,30}: {2}\n", input, "Begins with uppercase? ",
input.StartsWithUpper() ? "Yes" : "No");
} while (true);
}
}
}
Uruchommy teraz twoją aplikację, a zobaczysz następujące dane wyjściowe.
Aby lepiej zrozumieć, pozwól nam skorzystać z innych metod rozszerzających biblioteki klas w Twoim projekcie.
W tym rozdziale omówimy, czym jest PCL (przenośna biblioteka klas), a także dlaczego potrzebujemy języka PCL. Aby zrozumieć tę koncepcję, otwórzmy folder projektu biblioteki klas, który utworzyliśmy w poprzednim rozdziale.
W tym folderze widać, że oprócz plików project.json i CS mamy również plik * .xproj, a to dlatego, że typ projektu programu Visual Studio .NET Core to * .xproj zamiast * .csproj.
Jak wspomniał Microsoft, * .xproj zostanie wycofany, ale nadal jest dostępny w narzędziach w wersji zapoznawczej 2. Jak już omówiliśmy, aplikacja UWP używa * .csproj.
Teraz w rzeczywistości nie jest możliwe pobranie * .csproj do odniesienia i * .xproj, a ta funkcja nie zostanie zaimplementowana, ponieważ * .xproj zostanie usunięty.
Zamiast tego potrzebujemy biblioteki klas, którą można udostępniać między aplikacją konsoli i aplikacją UWP, a tutaj jest PCL.
Co to jest PCL
Zrozummy teraz, czym jest PCL -
Projekt Portable Class Library umożliwia pisanie i tworzenie zestawów zarządzanych, które działają na więcej niż jednej platformie .NET Framework.
Możesz tworzyć klasy zawierające kod, który chcesz udostępnić w wielu projektach, na przykład udostępnioną logikę biznesową, a następnie odwoływać się do tych klas z różnych typów projektów.
Może również pomóc w szybkim i łatwym tworzeniu wieloplatformowych aplikacji i bibliotek dla platform firmy Microsoft.
Przenośne biblioteki klas mogą pomóc zredukować czas i koszty tworzenia i testowania kodu.
Użyj tego typu projektu, aby pisać i tworzyć przenośne zestawy .NET Framework, a następnie odwoływać się do tych zestawów z aplikacji przeznaczonych dla wielu platform, takich jak Windows i Windows Phone itp.
Usuńmy teraz bibliotekę klas, którą utworzyliśmy z Eksploratora rozwiązań. Jednocześnie usuń go z folderu Solution i dodatkowo dodaj nowy element projektu.
Wybierz Visual C# → Windows szablon w lewym okienku i wybierz Biblioteka klas (przenośna) w środkowym okienku.
Wpisz StringLibrary w polu nazwy i kliknij OK aby stworzyć ten projekt.
Teraz musimy wybrać ramy docelowe do odniesienia. Wybierzmy na chwilę Windows Universal i ASP.NET Core, a następnie przekierujemy go. KliknijOK.
Możesz zobaczyć, że utworzył nowy projekt w formacie PCF. Teraz kliknij prawym przyciskiem myszy projekt StringLibrary w Eksploratorze rozwiązań i wybierz opcję Właściwości.
Kliknij docelowy standard platformy .NET.
Kliknij Tak; jest to teraz ta sama biblioteka klas z jedną drobną różnicą. Różnica polega na tym, że może być również używany przez UWP, ponieważ zawiera plik * .csproj zamiast * .xproj.
Dodajmy teraz nową klasę; w tym celu kliknij prawym przyciskiem myszy projekt w Eksploratorze rozwiązań i wybierzAdd → Class...
Wybierz klasę w środkowym okienku i wejdź StringLib.cs w polu nazwy, a następnie kliknij Add. Po dodaniu klasy zamień następujący kod w pliku StringLib.cs.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace StringLibrary {
public static class StringLib {
public static bool StartsWithUpper(this String str) {
if (String.IsNullOrWhiteSpace(str))
return false;
Char ch = str[0];
return Char.IsUpper(ch);
}
public static bool StartsWithLower(this String str) {
if (String.IsNullOrWhiteSpace(str))
return false;
Char ch = str[0];
return Char.IsLower(ch);
}
public static bool StartsWithNumber(this String str) {
if (String.IsNullOrWhiteSpace(str))
return false;
Char ch = str[0];
return Char.IsNumber(ch);
}
}
}
Zbudujmy ten projekt przenośnej biblioteki klas i powinien skompilować się bez błędów. Teraz musimy dodać odniesienie do tej przenośnej biblioteki klas w naszym projekcie konsoli. Rozwiń więc FirstApp i kliknij prawym przyciskiem myszy Referencje i wybierzAdd Reference…
W oknie dialogowym Menedżer odwołań wybierz opcję StringLibrary, która jest naszym projektem przenośnej biblioteki klas, a następnie kliknij przycisk OK.
Możesz zobaczyć, że odwołanie StringLibrary jest dodawane do projektu konsoli i można je również zobaczyć w pliku project.json.
Możesz teraz ponownie uruchomić aplikację, a zobaczysz te same dane wyjściowe.
Użyjmy teraz innych metod rozszerzających twojej przenośnej biblioteki klas w twoim projekcie. Ta sama przenośna biblioteka będzie również używana w aplikacji UWP.
W tym rozdziale omówimy, jak dodać odniesienia do biblioteki. Dodawanie odwołań do biblioteki przypomina dodawanie odwołań do innych projektów, takich jak projekt konsoli i projekt platformy UWP.
Możesz teraz zobaczyć, że projekt PCL ma domyślnie pewne odwołania. Możesz również dodać inne odniesienia zgodnie z potrzebami aplikacji.
W bibliotece PCL można również zobaczyć plik project.json.
{
"supports": {},
"dependencies": {
"NETStandard.Library": "1.6.0",
"Microsoft.NETCore.Portable.Compatibility": "1.0.1"
},
"frameworks": {
"netstandard1.3": {}
}
}
Jedną z metod dodawania odwołań do biblioteki jest wpisanie jej bezpośrednio w pliku project.json. Jak widać, dodaliśmy kilka odniesień w sekcji zależności, jak pokazano w poniższym kodzie.
{
"supports": {},
"dependencies": {
"NETStandard.Library": "1.6.0",
"Microsoft.NETCore.Portable.Compatibility": "1.0.1",
"System.Runtime.Serialization.Json": "4.0.3",
"Microsoft.EntityFrameworkCore": "1.1.0"
},
"frameworks": {
"netstandard1.3": {}
}
}
Zapiszmy teraz ten plik, a zobaczysz, że odniesienia zostały teraz dodane do Twojej biblioteki.
Inną metodą dodawania odwołań do biblioteki jest Menedżer pakietów NuGet. Kliknijmy teraz prawym przyciskiem myszy plikStringLibrary (Portable) projekt i wybierz Mange NuGet Packages…
Na karcie Przeglądaj możesz przeszukać dowolny pakiet NuGet; powiedzmy, że chcemy dodać pakiet „System.Runtime.Serialization.Primitives”.
Kliknij Install przycisk, co spowoduje wyświetlenie następującego ekranu.
Teraz kliknij OK przycisk.
Na koniec kliknij I Acceptprzycisk, aby rozpocząć instalację tego pakietu NuGet. Po zakończeniu instalacji zobaczysz, że pakiet NuGet „System.Runtime.Serialization.Primitives” został dodany do Twojej biblioteki.
W tym rozdziale omówimy, jak udostępniać swoją bibliotekę jako NuGet Packageaby można go było wykorzystać w innym projekcie. Tworzenie pakietu rozpoczyna się od kodu, który chcesz spakować i udostępnić innym, za pośrednictwem publicznej galerii NuGet.org lub prywatnej galerii w Twojej organizacji. Pakiet może również zawierać dodatkowe pliki, takie jakreadme który jest wyświetlany po zainstalowaniu pakietu i może zawierać transformacje do niektórych plików projektu.
Rozważmy teraz prosty przykład, w którym utworzymy pakiet NuGet z naszej biblioteki. Aby to zrobić, otwórz wiersz polecenia i przejdź do folderu, w którym znajduje się plik project.json projektu biblioteki.
Uruchommy teraz następujące polecenie.
dotnet help
Na końcu możesz zobaczyć różne polecenia, takie jak nowe, przywracanie i budowanie itp.
Ostatnim poleceniem jest pack;spowoduje to utworzenie pakietu NuGet. Wykonajmy teraz następujące polecenie.
dotnet pack
Możesz teraz zobaczyć, że pakiety NuGet są tworzone w folderze bin; pozwól nam otworzyć folder bin \ Debug.
Teraz pytanie brzmi, co znajduje się w pakietach NuGet, aby zobaczyć, że możemy użyć Eksploratora pakietów NuGet. Otwórzmy teraz Eksploratora pakietów NuGet.
Wybierz pierwszą opcję Open a local package.
Wybierz StringLibrary.1.0.0.nupkg i kliknij Open.
Widać, że w sekcji Zawartość pakietu mamy tylko StringLibrary.dll. W sekcji Metadane pakietu zobaczysz trochę informacji o tej bibliotece, takich jak identyfikator, wersje i wszystkie zależności.
Otwórzmy teraz plik StringLibrary.1.0.0.symbols.nupkg.
W tym pakiecie NuGet zobaczysz pliki źródłowe i *.pdbplik. Jeśli klikniesz dwukrotnie plikStringLib.cs plik, zobaczysz również kod źródłowy.
Tutaj pytanie brzmi, jak skonfigurować metadane, takie jak wersja, autorzy i opis itp.
Plik project.json jest używany w projektach .NET Core do definiowania metadanych projektu, informacji o kompilacji i zależności. Otwórzmy teraz plik project.json i dodajmy następujące dodatkowe informacje.
{
"authors": [ "Mark Junior" ],
"description": "String Library API",
"version" : "1.0.1-*",
"supports": {},
"dependencies": {
"Microsoft.EntityFrameworkCore": "1.1.0",
"Microsoft.NETCore.Portable.Compatibility": "1.0.1",
"NETStandard.Library": "1.6.0",
"System.Runtime.Serialization.Json": "4.0.3",
"System.Runtime.Serialization.Primitives": "4.3.0"
},
"frameworks": {
"netstandard1.3": {}
}
}
Możesz teraz zobaczyć dodatkowe informacje, takie jak nazwa autora, opis i wersja dodana tutaj. Zapiszmy ten plik, skompilujmy projekt biblioteki, a następnie ponownie wykonaj polecenie „dotnet pack”.
W folderze bin \ Debug widać, że pakiety NuGet StringLibrary są tworzone w wersji 1.0.1; otwórzmy go w Eksploratorze pakietów NuGet.
Zobaczysz zaktualizowane metadane. Pytanie brzmi, jak możemy go wykorzystać w innym pakiecie.
Musimy zacząć od opublikowania gdzieś w kanale NuGet, a następnie możemy wykorzystać go w innym projekcie.
Istnieją dwie opcje publikowania zaktualizowanych metadanych -
- Opublikuj go w witrynie NuGet.org
- Wypchnij metadane do prywatnego źródła danych NuGet
Tutaj będziemy używać prywatnego źródła danych NuGet, ponieważ jest to o wiele łatwiejsze niż skonfigurowanie konta w witrynie NuGet.org. Aby dowiedzieć się, jak opublikować pakiet w witrynie nuget.org, możesz postępować zgodnie ze wszystkimi wytycznymi określonymi tutajhttps://docs.microsoft.com/en-us/nuget/create-packages/publish-a-package.
Wykonaj następujące kroki, aby wypchnąć zaktualizowane metadane do prywatnego źródła danych NuGet.
Step 1- Na początek potrzebujemy narzędzia wiersza poleceń nuget i musimy je zainstalować. Otwórzmy teraz Menedżera pakietów NuGet i wyszukaj nuget.commandline.
Step 2 - Wybierz Nuget.Commandline i kliknij Install.
Step 3 - Kliknij OKzainstalować Nuget.Commandline. Możesz również zainstalować go ręcznie, pobierając go z następującego adresu URLhttps://dist.nuget.org/index.html a następnie skonfiguruj zmienną środowiskową.
Step 4 - Po zakończeniu instalacji otwórzmy ponownie wiersz polecenia i przejdź do pliku bin\Debug folder, w którym znajdują się pakiety NuGet, i określ następujące polecenie -
nuget add StringLibrary.1.0.1.nupkg -Source D:\PrivateNugetPackages
Step 5 - W powyższym poleceniu dodajemy pakiet StringLibrary.1.0.1.nupkg do naszego prywatnego kanału, a lokalizacja jest D:\PrivateNugetPackages, -Source określa źródło pakietu.
Step 6 - Widzisz, że StringLibraryjest zainstalowane; theStringLibrary można dodatkowo dodać do prywatnego kanału.
Step 7 - Przejdźmy do tego folderu.
Step 8 - Wewnątrz stringlibrary folder, zobaczysz inny folder z nazwą wersji, a tutaj jest to 1.0.1.
Pakiet NuGet znajduje się tutaj.
W tym rozdziale omówimy, jak korzystać z pakietu NuGet, który utworzyliśmy i opublikowaliśmy w prywatnym źródle treści NuGet. Więc najpierw utworzymy projekt Xamarin.Forms. Najpierw musimy zrozumieć, czym jest Xamarin.Forms.
Xamarin.Forms to framework, który umożliwia programistom szybkie tworzenie wieloplatformowych interfejsów użytkownika.
Xamarin.Forms to wieloplatformowa abstrakcja zestawu narzędzi interfejsu użytkownika obsługiwana natywnie, która umożliwia deweloperom łatwe tworzenie interfejsów użytkownika, które można udostępniać w systemach Android, iOS, Windows i Windows Phone.
Interfejsy użytkownika są renderowane przy użyciu natywnych kontrolek platformy docelowej, dzięki czemu aplikacje Xamarin.Forms zachowują odpowiedni wygląd i działanie dla każdej platformy.
Aby uruchomić Xamarin.Forms, potrzebujemy dodatkowych funkcji w Visual Studio 2015. Zmodyfikujmy Twój Visual Studio 2015 i upewnij się, że wybrana jest następująca opcja tworzenia aplikacji mobilnych dla wielu platform.
Po zakończeniu instalacji zaktualizujmy Xamarin, wybierając Tools → Options…
Przewiń w dół i rozwiń platformę Xamarin w lewym okienku, a następnie wybierz Other. W prawym górnym rogu okna dialogowego kliknijCheck Now aby sprawdzić, czy są dostępne aktualizacje.
Możesz zobaczyć, że aktualizacje są dostępne, kliknijmy Downloadprzycisk, aby rozpocząć pobieranie. Po zakończeniu pobierania otrzymasz powiadomienie o konieczności zainstalowania aktualizacji.
Otwórzmy teraz ponownie Visual Studio i wybierzmy plik File → New → Project… opcja menu.
W lewym okienku wybierz plik Visual C# → Cross-Platform szablon iw środkowym okienku wybierz Blank Xaml App (Xamarin.Forms Portable). Wpisz nazwę w polu Nazwa i kliknij OK.
Wybierz wersję docelową i wersję minimalną i kliknij OK.
Zobaczysz serię projektów; u góry mamy bibliotekę PCL, która będzie współdzielona między wszystkimi platformami, takimi jak Android, iOS, UWP, Windows 8.1 i Windows Phone 8.1.
Tutaj skupimy się na bibliotece PCL i wprowadzimy tutaj trochę kodu. Rozwińmy kod.
W tym szablonie Xamarin.Forms można zobaczyć ogólny plik App.xaml i MainPage.xaml, który używa struktury XAML Xamarin.Forms, która działa na tych platformach.
Musimy zaimportować nasze kody, a także potrzebujemy prywatnego kanału NuGet, który skonfigurowaliśmy w ostatnim rozdziale.
Otwórzmy teraz Menedżera pakietów NuGet. Kliknij koło obok listy rozwijanej Źródło pakietu.
Musimy tutaj dodać nasz prywatny kanał, kliknijmy plus (+) button.
Zobaczysz, że kolejne pole wyboru zostało dodane w Available package sources określmy nazwę i ścieżkę źródłową i kliknij OK.
Przejdźmy teraz do karty Przeglądaj i wybierz opcję PrivateSource z listy rozwijanej Źródło pakietu, a zobaczysz pakiet NuGet StringLibrary. Wybierz StringLibrary i kliknijInstall.
Kliknij OK, a zobaczysz jeden błąd.
Nie możemy używać biblioteki z profilem .NETPortable w wersji 259, naprawimy ten błąd w następnym rozdziale.
W tym rozdziale naprawimy błąd, który napotkaliśmy podczas instalowania pakietu NuGet z naszego prywatnego źródła w projekcie Xamarin.Forms.
W dalszej części wyjaśnimy krótko problem. Na początek kliknij prawym przyciskiem myszy bibliotekę PCL i wybierz opcję Właściwości.
Na tej stronie zobaczysz całą serię docelowych frameworków. Na podstawie błędu widać, że profil .NETPortable 259 nie jest zgodny z naszą biblioteką StringLibrary 1.0.1. Jednak próbuje pobrać odniesienie z biblioteki .NET Standard 1.1.
Zobaczmy teraz standardową bibliotekę .NET i określmy, która platforma nie jest kompatybilna z naszą biblioteką.
Widać, że Windows Phone Silverlight 8 jest kompatybilny z .NET Standard 1.0. Jeśli otworzysz następującą stronę internetową, zobaczysz, że Profile259 obsługuje tylko .NET Standard 1.0.
Odznaczmy teraz Windows Phone Silverlight 8.
Kliknij OK przycisk.
Teraz, aby rozwiązać ten problem, kliknij OK i anuluj okno dialogowe Zmień cele, a następnie otwórz konsolę Menedżera pakietów i wykonaj następujące polecenie.
PM > Uninstall-Package Xamarin.Forms
Przejdźmy teraz do Właściwości biblioteki PCL. Kliknij przycisk Zmień.
Usuń zaznaczenie opcji Windows Phone Silverlight 8 i kliknij przycisk OK.
Możesz teraz zobaczyć, że Windows Phone Silverlight 8 nie jest już dostępny w platformie docelowej. Możesz również zobaczyć profil, który jest teraz celem. Aby to zobaczyć, zwolnijmy bibliotekę PCL i edytuj plik XamarinApp.csproj.
Możesz teraz zobaczyć, że TargetFrameworkProfile to teraz Profile111.
Jeśli otworzysz dokumentację, zobaczysz, że Profile111 obsługuje .NET Standard 1.1.
Załadujmy teraz ponownie PCL i otwórz Menedżera pakietów NuGet i spróbuj zainstalować pakiet StringLibrary z prywatnego źródła.
Z listy rozwijanej Zachowanie zależności wybierz opcję Ignoruj zależności, a następnie kliknij przycisk Install.
Możesz zobaczyć, że pakiet StringLibrary jest teraz instalowany z prywatnego źródła. Jeśli rozwiniesz References of PCL, zobaczysz, że odwołanie do StringLibrary również zostało dodane, jak pokazano poniżej.
Odinstalowaliśmy Xamarin.Forms dla problemu Windows Phone Silverlight 8. Należy ponownie zainstalować Xamarin.Forms. Zaleca się zainstalowanie tej samej wersji.
Po zakończeniu instalacji skorzystaj z funkcji StringLibrary w Twojej aplikacji.
W tym rozdziale omówimy sposób tworzenia projektu testowego przy użyciu platformy .NET Core. Testowanie jednostkowe to proces opracowywania oprogramowania, które ma najmniejsze testowalne części aplikacji, zwane jednostkami. Są oni indywidualnie i niezależnie sprawdzani pod kątem prawidłowego działania. Testowanie jednostkowe może być zautomatyzowane lub wykonane ręcznie.
Otwórzmy teraz okno dialogowe Nowy projekt i wybierzmy Visual C# → .NET Core szablon.
W tym oknie dialogowym widać, że nie ma szablonu projektu do testowania jednostkowego. Aby utworzyć projekt testu jednostkowego, powinniśmy użyć narzędzia wiersza poleceń. Przejdźmy do utworzonego przez nas folderu Solution; utwórz folder testowy, a wewnątrz folderu test utwórz inny folder i nadaj mu nazwęStringLibraryTests.
Użyjmy teraz narzędzia wiersza polecenia dotnet, aby utworzyć nowy projekt testowy, wykonując następujące polecenie -
dotnet new -t xunittest
Możesz teraz zobaczyć, że tworzony jest nowy projekt C #; zajrzyjmy do folderu, wykonując plikv polecenie, a zobaczysz project.json i Tests.cs pliki, jak pokazano poniżej.
Oto kod w pliku project.json.
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable"
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.1.1",
"xunit": "2.1.0",
"dotnet-test-xunit": "1.0.0-rc2-192208-24"
},
"testRunner": "xunit",
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"imports": [
"dotnet5.4",
"portable-net451+win8"
]
}
}
}
Poniżej znajduje się kod w pliku Test.cs.
using System;
using Xunit;
namespace Tests {
public class Tests {
[Fact]
public void Test1() {
Assert.True(true);
}
}
}
Aby pobrać niezbędne zależności z NuGet, wykonajmy następujące polecenie -
dotnet restore
Test możemy uruchomić po przywróceniu niezbędnych zależności.
Widać, że kompilacja się powiodła; gdy zejdziesz na dół, możesz zobaczyć informacje o wykonanym teście.
Obecnie mamy 1 test wykonany, 0 błędów, 0 nieudanych, 0 pominiętych, a czas potrzebny na wykonanie jest również wymieniony jako informacja.
W tym rozdziale omówimy sposób uruchamiania testów w programie Visual Studio. NET Core został zaprojektowany z myślą o testowalności, dzięki czemu tworzenie testów jednostkowych dla aplikacji jest łatwiejsze niż kiedykolwiek wcześniej. W tym rozdziale uruchomimy i wykonamy nasz projekt testowy w Visual Studio.
Otwórzmy rozwiązanie FirstApp w programie Visual Studio.
Widzisz, że ma tylko dwa projekty i nie będziesz mógł zobaczyć projektu testowego, ponieważ nie dodaliśmy tego projektu w naszym rozwiązaniu.
Najpierw dodajmy folder i nazwijmy go test.
Kliknij prawym przyciskiem myszy plik test teczka.
Wybierz project.json plik i kliknij Open.
Poniższy zrzut ekranu przedstawia kod w Tests.cs plik jako wyjście.
Jest to domyślna implementacja i po prostu sprawdza, czy wartość True jest równa prawdzie. Jest to platforma testowa xUnit, a zobaczysz atrybut Fact, który zawiera adnotacje i oznacza metodę testową.
using System;
using Xunit;
namespace Tests {
public class Tests {
[Fact]
public void Test1() {
Assert.True(true);
}
}
}
Poniżej znajduje się implementacja project.json plik.
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable"
},
"dependencies": {
"System.Runtime.Serialization.Primitives": "4.1.1",
"xunit": "2.1.0",
"dotnet-test-xunit": "1.0.0-rc2-192208-24"
},
"testRunner": "xunit",
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"imports": [
"dotnet5.4",
"portable-net451+win8"
]
}
}
}
W project.jsonplik, najważniejszą zależnością od frameworka testowego jest xunit, który wprowadza atrybut Fact. Wprowadza ramy testowe i interfejsy API do testowania za pomocą xunit.
Mamy również dotnet-test-xunit, to jest program adoptujący, dzięki czemu xunit może współpracować z .NET Core, w szczególności z dotnet testnarzędzie wiersza poleceń. Wtedy zobaczysztestRunner który będzie uruchamiał xunit, a także możesz zobaczyć plik netcoreapp1.0 struktura.
Zobaczysz zależność .NETCore.App poniżej.
Aby uruchomić test w programie Visual Studio, otwórzmy Eksploratora testów z poziomu Test → Window → Test Explorer opcja menu.
I widać, że program Visual Studio automatycznie wykrywa test. Nazwa testu składa się znamespace.className.TestMethodName. Kliknijmy terazRun All button in Test Explorer.
Najpierw zbuduje kod i uruchomi test, a zobaczysz całkowity czas potrzebny na test. Zmieńmy metodę testową, abyśmy mogli zobaczyć wynik, gdy test się nie powiedzie.
using System;
using Xunit;
namespace Tests {
public class Tests {
[Fact]
public void Test1() {
Assert.True(false);
}
}
}
Wykonajmy test ponownie, klikając plik Run All link do przycisku.
Możesz teraz zobaczyć plik test niepowodzenie.
W tym rozdziale przetestujemy naszą bibliotekę StringLibrary i aby to zrobić, musimy zmienić kolejność naszych projektów, tak abyśmy mogli przestrzegać domyślnej konwencji.
Otwórzmy global.json plik.
{
"projects": [ "src", "test" ],
"sdk": {
"version": "1.0.0-preview2-003131"
}
}
U góry tego pliku zobaczysz ustawienia projektu i skonfigurujesz folder, taki jak src i test domyślnie.
Zgodnie z konwencją musimy mieć projekty w tych folderach, jest to nowa konwencja, która będzie używana jako część .NET Core.
W Eksploratorze rozwiązań widać, że zarówno projekt konsoli, jak i projekt biblioteki znajdują się w src podczas gdy projekt testowy jest w środku test teczka.
A struktura projektów w Eksploratorze rozwiązań nie przedstawia, gdzie projekty fizycznie istnieją na dysku. Otwórzmy teraz folder Rozwiązanie, a zobaczysz toStringLibrary projekt nie znajduje się w src teczka.
Widać, że jedno i drugie src i test foldery są mapowane na konwencję określoną w global.jsonplik. Mamy jednak jeden projekt StringLibrary, który jest poza konwencją. Dodajmy terazStringLibrary projekt wewnątrz src teczka.
W folderze src mamy dwa projekty i musimy naprawić problem, abyśmy mogli poprawnie używać wszystkich projektów. Wróćmy do programu Visual Studio i kliknij prawym przyciskiem myszy projekt StringLibrary i wybierz opcję Usuń. Nie usunie go, ale usunie tylko projekt.
Teraz kliknij prawym przyciskiem myszy folder src i wybierz Add → Existing Project…
Przejdź do projektu StringLibrary, który znajduje się teraz w src wybierz folder StringLibrary.csproj plik i kliknij Open.
Musimy teraz usunąć odniesienie do StringLibrary z project.json plik aplikacji konsoli.
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"NuGet.CommandLine": "3.5.0",
"System.Runtime.Serialization.Json": "4.0.3"
},
"frameworks": {
"netcoreapp1.0": {
"dependencies": { },
"imports": "dnxcore50"
}
}
}
Zapisz zmiany, a następnie dodaj odniesienie do StringLibrary ponownie w projekcie konsoli.
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"NuGet.CommandLine": "3.5.0",
"System.Runtime.Serialization.Json": "4.0.3"
},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"StringLibrary": {
"target": "project"
}
},
"imports": "dnxcore50"
}
}
}
Teraz wszystko powinno znowu działać i możesz budować StringLibrary i wtedy FirstApp(projekt konsoli) bez żadnego błędu. Przetestujmy teraz funkcjonalność StringLibrary przy użyciu xunit. Musimy dodać odwołanie do StringLibrary do naszego projektu testowego. Kliknij prawym przyciskiem myszy projekt References of StringLibraryTests i wybierz opcję Dodaj odwołanie…
Kliknij OK co doda odniesienie do StringLibrarydo naszego projektu testowego. Zastąpmy teraz następujący kod wTests.cs plik.
using System;
using Xunit;
using StringLibrary;
namespace Tests {
public class Tests {
[Fact]
public void StartsWithUpperCaseTest() {
string input = "Mark";
Assert.True(input.StartsWithUpper());
}
[Fact]
public void StartsWithLowerCaseTest() {
string input = "mark";
Assert.True(input.StartsWithLower());
}
[Fact]
public void StartsWithNumberCaseTest() {
string input = "123";
Assert.True(input.StartsWithNumber());
}
}
}
Jak widać, mamy trzy metody testowe, które przetestują funkcjonalność StringLibrary. KliknijmyRun All link, a zobaczysz następujące dane wyjściowe w Eksploratorze testów.
Możesz także uruchomić testy z wiersza poleceń. Otwórzmy wiersz polecenia i wykonajmy plikdotnet test Komenda.
W tym rozdziale omówimy strukturę zarządzanej rozszerzalności (MEF). MEF może służyć do rozszerzania wtyczek innych firm lub może przynosić korzyści z luźno połączonej architektury podobnej do wtyczki do zwykłych aplikacji.
MEF to biblioteka do tworzenia lekkich, rozszerzalnych aplikacji.
Umożliwia programistom aplikacji odkrywanie i używanie rozszerzeń bez konieczności konfiguracji.
MEF jest integralną częścią .NET Framework 4 i jest dostępny wszędzie tam, gdzie jest używany .NET Framework, co zwiększa elastyczność, łatwość konserwacji i testowalność dużych aplikacji.
Możesz używać MEF w aplikacjach klienckich, niezależnie od tego, czy używają one Windows Forms, WPF lub dowolnej innej technologii, czy w aplikacjach serwerowych, które używają ASP.NET.
MEF został przeniesiony jako Microsoft.Composition do .NET Core, ale częściowo.
Tylko System.Composition jest przenoszony i System.ComponentModel.Compositionnie jest jeszcze dostępny. Oznacza to, że nie mamy katalogów, które mogą ładować typy z zestawów w katalogu.
W tym rozdziale dowiemy się tylko, jak możemy używać MEF w aplikacji .NET Core.
Zrozummy prosty przykład, w którym użyjemy MEF w aplikacji konsolowej .NET Core. Utwórzmy teraz nowy projekt konsoli .NET Core.
W lewym okienku wybierz Templates → Visual C# → .NET Core, a następnie w środkowym okienku wybierz pozycję aplikacja konsoli (.NET Core).
Wpisz nazwę projektu w polu Nazwa i kliknij OK.
Po utworzeniu projektu musimy dodać odwołanie do Microsoft.Composition, abyśmy mogli używać MEF. Aby to zrobić, kliknij prawym przyciskiem myszy projekt w Eksploratorze rozwiązań iManage NuGet Packages…
Szukaj Microsoft.Composition i kliknij Install.
Kliknij OK przycisk.
Kliknij I Accept przycisk.
Po zakończeniu instalacji znajdziesz błąd w materiałach referencyjnych.
Otwórzmy project.json plik.
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.Composition": "1.0.30",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"frameworks": {
"netcoreapp1.0": {
"imports": "dnxcore50"
}
}
}
Widać, że plik Microsoft.Composition zależność jest dodana, ale problem polega na tym, że ten pakiet nie jest zgodny z dnxcore50. Więc musimy zaimportowaćportablenet45+win8+wp8+wpa81. Pozwól nam teraz zastąpić twójproject.json plik z następującym kodem.
{
"version": "1.0.0-*",
"buildOptions": {
"emitEntryPoint": true
},
"dependencies": {
"Microsoft.Composition": "1.0.30",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
}
},
"frameworks": {
"netcoreapp1.0": {
"imports": "portable-net45+win8+wp8+wpa81"
}
}
}
Zapisz ten plik, a zobaczysz, że błąd został naprawiony.
Jeśli rozwiniesz odwołania, zobaczysz odniesienie do Microsoft.Composition.
Najpierw musimy stworzyć interfejs, który ma być wyeksportowany i zaimplementować interfejs oraz ozdobić klasę atrybutem export. Dodajmy teraz nową klasę.
Wpisz nazwę swojej klasy w polu Nazwa i kliknij Add.
Dodajmy następujący kod w PrintData.cs plik.
using System;
using System.Collections.Generic;
using System.Composition;
using System.Linq;
using System.Threading.Tasks;
namespace MEFDemo {
public interface IPrintData {
void Send(string message);
}
[Export(typeof(IPrintData))]
public class PrintData : IPrintData {
public void Send(string message) {
Console.WriteLine(message);
}
}
}
Jak wspomniano powyżej, katalogi nie są dostępne w przestrzeni nazw Microsoft.Composition. Więc załaduje wszystkie typy z zestawu z atrybutem eksportu i dołączy do atrybutu importu, jak pokazano w metodzie Compose w pliku Program.cs.
using System;
using System.Collections.Generic;
using System.Composition;
using System.Composition.Hosting;
using System.Linq;
using System.Reflection;
using System.Threading.Tasks;
namespace MEFDemo {
public class Program {
public static void Main(string[] args) {
Program p = new Program();
p.Run();
}
public void Run() {
Compose();
PrintData.Send("Hello,this is MEF demo");
}
[Import]
public IPrintData PrintData { get; set; }
private void Compose() {
var assemblies = new[] { typeof(Program).GetTypeInfo().Assembly };
var configuration = new ContainerConfiguration()
.WithAssembly(typeof(Program).GetTypeInfo().Assembly);
using (var container = configuration.CreateContainer()) {
PrintData = container.GetExport<IPrintData>();
}
}
}
}
Uruchommy teraz twoją aplikację, a zobaczysz, że działa, tworząc wystąpienie PrintData klasa.
Aby dowiedzieć się więcej o MEF, odwiedź następujący adres URL https://msdn.microsoft.com/en-us/library/dd460648%28v=vs.110%29.aspx po więcej szczegółów.
W tym rozdziale poznamy nadchodzące funkcje platformy .NET Core. Zaczniemy od narzędzi wiersza poleceń .NET, otwierając następujący adres URL w przeglądarcehttps://github.com/dotnet/cli
Aby dowiedzieć się więcej o postępie, możesz pobrać najnowszą wersję zestawu .NET Core SDK, przewijając w dół, a zobaczysz sekcję Instalator i pliki binarne.
Możesz zobaczyć najnowszą wersję narzędzi podglądu dla różnych systemów operacyjnych, wybierzmy Instalatora zgodnie z Twoim systemem operacyjnym.
Pracujemy nad wersją 1 wersji zapoznawczej .NET Core 2.0.
Przyjrzyjmy się teraz naszym obecnym narzędziom, otwierając wiersz polecenia i wykonując następujące polecenie.
dotnet --info
Zobaczysz informacje o aktualnie zainstalowanej wersji Narzędzi wiersza poleceń .NET w twoim systemie, jak pokazano poniżej.
Widać, że obecnie mamy podgląd narzędzi 2. Uruchommy teraz następujące polecenie, aby zapoznać się z plikiemnew Komenda.
dotnet help new
W przypadku nowego języka poleceń projektu możesz wybrać C # i F # oraz typ projektu itp.
Zobaczmy teraz zmiany w najnowszej wersji .NET Core. Po pobraniu instalatora kliknij go dwukrotnie, aby go zainstalować. Kliknij Zainstaluj.
Poniższy zrzut ekranu przedstawia proces instalacji.
Rozpocznie się proces instalacji. Po zakończeniu instalacji zamknij to okno dialogowe.
Otwórz wiersz polecenia i wykonaj następujące polecenie.
dotnet --info
Zobaczysz informacje o aktualnie zainstalowanej wersji Narzędzi wiersza poleceń .NET w systemie, jak pokazano poniżej.
Teraz widać, że mamy narzędzia w wersji Preview1 platformy .NET Core 2. Uruchommy teraz następujący kod w wierszu polecenia, aby zapoznać się z nowym poleceniem w .NET Core 2 w wersji zapoznawczej1.
dotnet help new
Polecenie pomaga również w pobieraniu pakietów do pamięci podręcznej pakietów.
Polecenie otwiera następującą stronę internetową, która zawiera informacje o nowym poleceniu w .NET Core 2 w wersji zapoznawczej1.
Przewińmy w dół, widać, że możemy stworzyć aplikację .NET Core z większą liczbą szablonów.
Teraz możemy tworzyć mstest, web, mvc i webapi projekty również za pomocą wiersza poleceń.
NET Core zdecydował się porzucić project.json i wrócić do MSBuild i * .csproj. To jest coś, co już się wydarzyło w właśnie wydanym narzędziu .Net Core 2.0 w wersji zapoznawczej1. To dość rozczarowujące, ponieważ project.json był powiewem świeżego powietrza. Jest to jednak zrozumiałe i ma również wiele zalet.
Omówmy teraz korzyści, jakie przynosi ta zmiana -
Ułatwiłoby to przejście istniejących rozwiązań Visual Studio na platformę .NET Core.
To ogromna zmiana, która umożliwi również wykorzystanie istniejących inwestycji w CI / RM w oparciu o MSBuild.
Podczas kompilacji w programie MSBuild możemy myśleć o kompilacji przyrostowej, rozwiązywaniu zależności czasu kompilacji, zarządzaniu konfiguracją itp.
Dostarczenie cli dotnet na czas wymaga dużo pracy, ponieważ nie chodzi już tylko o ASP.NET Core, ale także o aplikacje konsolowe, aplikacje UWP itp.
Poniżej przedstawiono zmiany w programie MSBuild i * .csproj -
Plik Project.json (* .xproj) zostanie zastąpiony przez MSBuild (* .csproj).
Funkcje w project.json zaczną być ponownie scalane z plikiem * .csproj.
Nie jest jeszcze jasne, co zamierzają zrobić z listą pakietów, ale wspomniano, że mogą zachować ją jako json pod nuget.json lub scal go w *.csproj.
Podobno to przejście powinno być płynne i potencjalnie automatyczne, jeśli używasz programu Visual Studio.
Zalety MSBuild
MSBuild jest oprogramowaniem typu open source i jest dostępne w serwisie GitHub i jest w pełni wieloplatformowe.
MSBuild radykalnie uprości i przycina strukturę *.csproj.
Microsoft wprowadza również nowy system projektów, który umożliwi wiele scenariuszy bez konieczności używania Visual Studio, a szczegóły są podane w tym adresie URL https://github.com/dotnet/roslyn-project-system/.
Celem jest, aby nawet przy konfiguracji MSBuild praca z kompilacjami i projektami w środowisku IDE programu Visual Studio była tak samo płynna, jak poza nim.
MSBuild vs project.json
Utwórzmy teraz nowy projekt konsoli z narzędziami .NET Core Preview2, wykonując następujące polecenie.
dotnet new -t console
Aby zobaczyć wszystkie pliki utworzone w tym projekcie, uruchom dir Komenda.
Możesz zobaczyć, że powstały dwa pliki, Program.cs i project.json plik.
Utwórzmy teraz aplikację konsolową z narzędziami .NET Core 2 w wersji zapoznawczej1, wykonując następujące polecenie.
dotnet new console
Aby zobaczyć wszystkie pliki utworzone w tym projekcie, uruchom dirKomenda. Możesz zobaczyć, że powstały trzy pliki,Program.cs, NuGet.config i MSBuild.csproj zamiast pliku project.json.
Porównajmy teraz project.json i MSBuild.csproj pliki obok siebie.
Po lewej mamy plik w formacie json, a po prawej plik w formacie XML. Możesz zobaczyć, że w pliku project.json, w sekcji zależności, jestnetcoreapp1.0, podczas gdy w pliku MSBuild.csproj zobaczysz plik netcoreapp2.0.
W tym rozdziale omówimy, jak przywrócić i zbudować plik MSBuild (* .csproj) za pomocą narzędzia wiersza poleceń. Aby zobaczyć, jakie polecenia są dostępne w .NET Core 2.0 w wersji zapoznawczej 1, uruchommy następujące polecenie.
dotnet help
Zobaczysz wszystkie polecenia, takie jak nowe, przywracanie, budowanie itp.
Poniżej znajduje się domyślna implementacja w Program.cs plik.
using System;
namespace MSBuild {
class Program {
static void Main(string[] args) {
Console.WriteLine("Hello World!");
}
}
}
Wykonajmy teraz następujące polecenie, aby zobaczyć postęp.
dotnet build
Zobaczysz wiele błędów. Te błędy wymagają naprawy.
Uruchommy teraz następujące polecenie.
dotnet restore
Możesz zobaczyć, że wszystkie pakiety zostały przywrócone. Wygenerowano również nowe foldery i pliki.
Aby zobaczyć strukturę katalogów, uruchommy następujące polecenie.
tree /f
Poniżej znajduje się struktura katalogów -
Przebudujmy teraz projekt, ponownie uruchamiając następujące polecenie.
dotnet build
Teraz projekt zostanie pomyślnie skompilowany bez żadnych błędów i zostanie również utworzony plik MSBuild.dll.
Aby zobaczyć dane wyjściowe, uruchommy następujące polecenie -
dotnet run
Na konsoli możesz zobaczyć następujące dane wyjściowe.
W tym rozdziale dokonamy migracji aplikacji konsoli, która zawiera rozszerzenie project.json system budowania plików zamiast MSBuild (*.csproj). Mamy więc stary projekt, który zawiera następujące pliki.
Teraz pytanie brzmi, dlaczego potrzebujemy migracji? Ten projekt jest tworzony przy użyciu narzędzi .NET Core 1.0 w wersji zapoznawczej 2, a teraz mamy zainstalowane narzędzia .NET Core 2.0 w wersji zapoznawczej 1. Teraz podczas tworzenia tej aplikacji przy użyciu narzędzia wiersza poleceń programu .NET Core 2.0 zostanie wyświetlony następujący błąd.
To dlatego, że project.jsonbuild nie jest już dostępny w .NET Core 2.0, więc potrzebujemy migracji, aby działał poprawnie. Aby zobaczyć dostępne polecenia, uruchommy następujące polecenie.
dotnet help
W sekcji poleceń możesz zobaczyć różne polecenia, a także możesz zobaczyć migrate polecenie, które spowoduje migrację projektu opartego na project.json do projektu opartego na programie MSBuild.
Uruchommy teraz następujące polecenie.
dotnet migrate
Zobaczysz podsumowanie procesu migracji, a tutaj możesz również zobaczyć, że projekt został pomyślnie przeniesiony.
Zobaczmy teraz strukturę katalogów za pomocą następującego polecenia.
tree /f
Zobaczysz teraz plik * .csproj wraz z plikiem Program.cs w katalogu głównym projektu, a plik project.json zostanie przeniesiony do folderu kopii zapasowej.
Otwórzmy console.csprojplik. Teraz możesz przywrócić i skompilować ten projekt przy użyciu systemu MSBuild, uruchamiając następujące polecenie.
dotnet restore
Możesz teraz zobaczyć, że wszystkie pakiety zostały przywrócone.
Możesz teraz skompilować swój projekt za pomocą następującego polecenia.
dotnet build
Teraz widać, że projekt został pomyślnie skompilowany przy użyciu programu MSBuild, a plik console.dll jest również generowany w programie ..\bin\Debug\netcoreapp1.0 teczka.
Poniższy zrzut ekranu przedstawia strukturę katalogów i pliki.