Różnice między środowiskiem .Net Full a .Net Core Framework 4.5 używanym przez środowisko wykonawcze K?

Question

Widziałem filmy przedstawiające ASP.NET vNext i śledzenie ostatnich ogłoszeń na blogu, ale szczegółowe informacje na temat tego, co zostało usunięte z pełnego frameworka, wydają się niewielkie. Oto, co myślę, że wiem do tej pory:

• To znacznie mniejszy (11MB vs> 200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
• Strong nazewnictwa zniknął: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
• To dumpingowych System.Web
• Obejmuje ona scalona MVC i WebAPI (jednak nie sądzę, że jest to część samej struktury, ale raczej zależności, które można określić)
• Zależności są całkowicie zarządzane przez project.json, w zakresie, w jakim baza

Czy w zasadzie patrzymy na ramy, które zasadniczo zawierają tylko to, co jest w mscorlib w pełnej strukturze, a wszystko inne jest dostarczane za pośrednictwem zarządzania pakietami? A jeśli tak, to dlaczego miałbyś celować specjalnie w ramy, tak jak tutaj opisano? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx

Answer 1

Powodem, dla którego są one specjalnie ukierunkowane na NET45 w podanym łączu, jest fakt, że AutoFac jest zbudowany i ma zależność od .NET 4.5. Bez kodu NET45 kod nie zostałby skompilowany.

Moje założenie jest takie, że gdy vNext zbliża się coraz bardziej do wydania Autofac (i StructureMap, i Castle Windsor, i ...) wyda wersję, która kieruje się do zoptymalizowanego środowiska chmurowego w celu usunięcia zależności.

Answer 2

Nie mogę znaleźć oryginalnego źródła poza komentarzem Davida Fowlera (jak sądzę) na prezentacji z NDC, ale CoreCLR używany przez K Runtime jest w rzeczywistości reinkarnacją CLR używanego przez Silverlight 2. Było to używane, ponieważ jest małe i zaprojektowane jako platforma krzyżowa. Istnieje kilka dodatkowych informacji tutaj: https://stackoverflow.com/a/25720160/113225

Answer 3

O ile mi zrozumieć, .Net Framework jest w pełni ramy znamy i kochamy wszystkich implementacjach Windows i dużą ilością kodu my zwykle nie korzystają, jak wyjaśniają w niektórych wideo analizator składni XML.

W .NET Core usunęli wszystkie niepotrzebne implementacje/zależności i opuścili tylko podstawowe. co pozwala również na cross platformę (jeszcze nie), więc w przyszłości można by pomyśleć jako jedyny framework: CORE Framework i uruchomić na dowolnym urządzeniu. Ich february community standup daje wiele informacji i wgląd w ich cele i cele.

Widzę to jako przejście, gdy niektóre funkcje są dostępne tylko w pełnym programie ramowym, podczas gdy w przyszłości można oczekiwać, że wszystkie funkcje będą dostępne dla .NET Core.

Z perspektywy Microsoftu, jeśli chcą wydać, powiedzmy Entity Framework for mobile (EF7 dąży do tego), muszą pozbyć się wszystkich implementacji Windows, EF i jego zależności (Framework). Stworzyli więc zależność od systemu, która nie jest zależna od systemu Windows, co również pomaga zainstalować wiele frameworku i usunąć niektóre problemy z aktualizacją architektury, ponieważ są one w większości odizolowane od systemu, leżące w aplikacji. Pojawią się nowe problemy, takie jak wiele kopii tego samego schematu na jednej maszynie na aplikację, dlatego pracują nad czymś, co nazywa się Inteligentne udostępnianie.

This post może pomóc i daje pewien wgląd specjalnie niniejszej części:

Struktura NET Rdzeń składa się z dwóch głównych elementów, które dodają do i rozszerzają możliwości Framework następująco :

1. Runtime:

Zbudowany na tym samym kodzie, jak .NET Framework CLR. Obejmuje takie same GC i JIT (RyuJIT) Nie obejmuje funkcji takich jak Domeny lub Zabezpieczenia dostępu do kodu. Środowisko wykonawcze jest dostarczany na Nuget (pakiet Microsoft.CoreCLR)

klasy biblioteki
2. bazy:

są takie same jak kod biblioteki klas .NET Framework Ale nie zawierają zależności, więc mają mniejszy ślad. Dostępne na Nuget (System. * Pakiet)

i myślę, że już czytać Introducing .NET Core Microsoft.

Jeśli chodzi o twoją troskę o określenie konkretnego schematu, to dlatego, że teraz nie wszystko działa na Core CLR, więc musisz wybrać, którego użyć, lub możesz kierować obie i używać różnych implementacji.

Obecnie CORE działa tylko w systemie Windows; framework mono nie ma dostawcy SQLLite dla struktury encji, ale działa na Core, więc możesz na przykład użyć dostawcy InMemory lub Azure EF i wybrać w zależności od środowiska, w którym działa twoja aplikacja.

Jak mówi Scott Gu na stanowisku społecznościowym, wyobrażają sobie przyszłość, w której nie ma jednolitych ram ani pełnej struktury, jest tylko rdzeń, ale to zajmie czasu, jeśli kiedykolwiek się wydarzy.