ASP.NET 5 – global.json, project.json i wykorzystanie DNX i DNU

W ASP.NET w końcu !!! w końcu !!! nie ma pliku csproj! Czy tam vbproj czy nawet SLN… Ja! :) no fajnie nie? :)

Teraz wszystko działa wokół project.json file, który jest definicją naszego projektu jak i! definicją paczki nuget. Czyli jak się domyślacie referencje teraz pomiędzy projektami to referencje za pomocą paczek nuget…

Ekhm, no nic ;) może to poprawią.

Tak czy siak, jeżeli chcemy mieć coś w stylu pliku sln to tworzymy plik global.json w root folderze (tam gdzie przeważnie mieliśmy sln) i ustawiamy mu ścieżkę do folderów zawierających projekty:

{
    "projects": [ "src" ]
}

Następnie nasze projekty dzielimy na katalogi i każdy z projektów w katalogu może odwoływać się do innego projektu za pomocą nazwy katalogu domyślnie lub nazwy zdefiniowanej w project.json odpowiedniego projektu.

Ech, zrozumiałe? :)

Dobra, to co taki plik project.json może zawierać?

W najbardziej minimalistycznej wersji to:

{
    "dependencies": {
    },
    "frameworks": {
        "dnx451": { }
    }
}

To znaczy, że nasz projekt będzie działał tylko pod full .NET frameworkiem :)

Jeżeli chcemy by działał nam dla przenaszalnego .NET frameworka zwanego CoreCLR lub Mono CLR, wtedy musimy zmodyfikować nasz plik projektu na taki:

{
    "dependencies": {
    },
    "frameworks": {
        "dnx451": { },
        "dnxcore50": { }
    }
}

Definicje frameworks, trafiają jako stałe do kodu, czyli mamy dostępne dwie stałe dnxcore50 i dnx451 by robić #IF w kodzie. Po co te #IF w kodzie? Po to, że możemy wykorzystywać różne biblioteki w zależności od framework – na przykład dla .NET Framework możemy mieć Noda Time a dla Core już będziemy z DateTime korzystali.

Poprzednio napisałem o tym, że możemy ustawić aktywny build za pomocą dnvm use, więc teraz w zależności od tego buildu odpowiednia konfiguracja z project.json będzie ładowana., ale ok, bo wyprzedzam.

Krótki opis tego project.json:

• depedencies: to co jest wymagane niezależnie od framework, na przykład MVC
• frameworks: to na jakich CLR ma nasza aplikacja działać
  • depedencies: zależności nugetowe dla danego framework. Na przykład jak zaraz zobaczymy dla coreCLR musimy dodać System.Console a dla full .NET nic nie musimy
  • frameworkAssemblies: to co mieliśmy std. w VS, dodanie ref do biblioteki z gaca

Więcej na temat pliku project.json można przeczytać tutaj i tutaj. Zaś o global.json chyba wyłącznie tutaj.

Stwórzmy prosty plik project.json:

{
    "dependencies": {
    },
    "commands": {
        "apap": "run"
    },
    "frameworks": {
        "dnx451": { },
        "dnxcore50": { 
            "dependencies": {
                "System.Console": "4.0.0-beta-*"
            }
         }
    }
}

Jak widzicie jest prawie tak samo pusty jak ten powyżej, z dwoma różnicami:

• doszła referencja do System.Console, po to byśmy mieli dostęp do Console.COS
• doszła sekcja commands. Commands to taki nowy byt który jest rozumiany przez DNX, a mianowicie są to skróty które są wykorzystywane przez DNX, to znaczy, zamiast pisać całą komendę (a mogą one być skomplikowane), możemy mieć to pod aliasem. Przy console app to nie ma znaczenia bo odpalenie z aliasem czy bez będzie takie same (dnx . run), ale jak jest alias możemy z niego skorzystać. To zaczyna mieć ręce i nogi przy aplikacjach webowych gdzie ładujemy odpowiedni hosting i do tego odpowiedni serwer z parametrami… ogólnie około 150 znaków. W tym przypadku robimy alias apap na komendę run a więc, dnx . apap będzie taki sam jak dnx . run.

Ok, to chyba nie było skomplikowane? :) To teraz, dodajmy kolejny plik Program.cs:

using System;

namespace Console01
{
    public class Program
    {
        public static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
            Console.ReadLine();
        }
    }
}

Jak widać raczej tutaj nie ma różnicy pomiędzy tym co kiedyś a tym co teraz ;)

Otwórzmy command line/terminal tam gdzie mamy plik project.json i Program.cs i odpalmy komendę:

dnu restore [-u]

opcjonalne -u bo ja lubię jak mi coś nie działa ;) to spowoduje, że dnu przeczyta nasz plik project.json i ściągnie wszystkie wymagane paczki przez nasz projekt do katalogu .dnx/packages (.dnx to ten sam co w poprzednim postcie). Taki VSowy nuget restore ;)

Jak już mamy wszystkie paczki ściągnięte to… pora odpalić naszą super skomplikowaną aplikację :)

Możemy to zrobić na dwa sposoby ! :)

dnx . apap
dnx . run

który wybieracie zależy od was :) Trochę mnie ta kropka wkurza, ale rozumiem, że mieli problem z odkryciem katalogu w którym dnx jest odpalany…

Dobra, to teraz zobaczcie co się stanie gdy zmienicie w Program.cs static void na public void albo internal void czy też private void? :) dalej działa? :) dlaczego tak jest? No to w poprzednim postcie znajdziecie linki do opisu jak działa DNX a dokładnie o informacji o Depedency Injection który jest częścią nierozłączną ASP.NET :)

To tyle :) coś nie jasne? Piszcie :)