.NET Framework i .NET Core są dwoma różnymi platformami implementującymi standard .NET. Oto kilka kluczowych różnic między nimi:

1. **Wsparcie dla wielu platform** :
.NET Framework jest dostępny tylko dla systemu operacyjnego Windows, natomiast .NET Core jest multiplatformowy i działa na różnych systemach operacyjnych, takich jak Windows, Linux i MacOS.

2. **Model aplikacji**:
.NET Framework obsługuje różne modele aplikacji, w tym Windows Forms, WPF i ASP.NET. .NET Core natomiast początkowo miał ograniczone modele aplikacji, głównie konsolowe i ASP.NET Core. Od wersji 3.0 .NET Core zaczęło wspierać także WPF i Windows Forms, ale tylko na systemie Windows.

3. **Wsparcie dla mikrousług**:
.NET Core jest lepszym wyborem dla mikrousług ze względu na jego naturę modularną i lekką. Pozwala tworzyć małe, niezależne usługi, które mogą być rozbudowane i skalowane niezależnie od siebie. .NET Framework natomiast nie jest zalecany dla architektury mikrousług.

4. **Wydajność**:
.NET Core jest bardziej wydajny i szybki w porównaniu do .NET Framework dzięki usprawnieniom i optymalizacjom.

5. **Wsparcie dla wersji**:
.NET Core ma lepsze wsparcie dla różnych wersji. W .NET Core można lepiej kontrolować używaną wersję środowiska uruchomieniowego. W .NET Framework, aktualizacje zwykle wpływają na cały system i mogą powodować problemy ze zgodnością.

Kestrel to serwer internetowy, który jest używany domyślnie w ASP.NET Core przy tworzeniu aplikacji internetowych. Jest to serwer typu cross-platform, co oznacza, że działa na różnych systemach operacyjnych takich jak Windows, Linux czy MacOS.

**Kestrel** potrafi obsługiwać niewielkie, jak i duże projekty, co czyni go uniwersalnym wyborem dla programistów. Najważniejsza cecha tego serwera to bardzo dobra wydajność, szczególnie w porównaniu do poprzednich serwerów używanych w ASP.NET.

Jest jednak jednym z wielu serwerów, które można używać w ASP.NET Core. Można go zastąpić innym, na przykład IIS lub HTTP.sys, jeżeli jest taka potrzeba. Kestrel jest jednak domyślnym wyborem przy tworzeniu nowych aplikacji w ASP.NET Core ze względu na swoją wydajność i uniwersalność. Dodatkowo, jest on w pełni konfigurowalny, więc programista ma pełną kontrolę nad tym, jak działa serwer.

**Hot Reload** to funkcjonalność w .NET, która umożliwia deweloperom modyfikowanie kodu źródłowego aplikacji podczas jej działania, bez konieczności zatrzymywania i ponownego uruchamiania aplikacji. Zmieniony kod jest natychmiast kompilowany i wprowadzany do działającej aplikacji.

To oznacza, że jeśli wprowadzasz zmiany w widoku lub logice biznesowej, nie musisz zatrzymywać i ponownie uruchamiać swojej aplikacji, aby zobaczyć te zmiany na żywo. Poprawia to efektywność procesu deweloperskiego, oszczędzając czas i eliminując (lub przynajmniej zmniejszając) przerwy wywołane koniecznością ponownego uruchamiania.

Dotychczas Hot Reload jest dostępny dla aplikacji konsolowych, aplikacji WPF (.NET Core 3.1 i nowszych), aplikacji Windows Forms (.NET 6.0 i nowszych) oraz dla aplikacji ASP.NET Core (z wyłączeniem aplikacji Blazor).

Cechą wyróżniającą tę funkcjonalność jest to, że można jej używać bez konieczności podłączenia debugera, co czyni jej użycie jeszcze bardziej efektywnym w codziennym rozwoju aplikacji. Hot Reload działa zarówno w trybie Debug, jak i Release.

Global Tool to specjalny typ pakietu NuGet, który zawiera konsolową aplikację. Narzędzie to jest zainstalowane globalnie na komputerze i można go używać z dowolnego miejsca w systemie.

Może to być użyteczne w wielu sytuacjach, na przykład gdy chcesz mieć dostęp do określonej funkcji Narzędzi .NET bez dodawania ich jako zależności do każdego projektu. Przykładowym Global Tool jest .NET Watcher, który automatycznie buduje i uruchamia aplikację, kiedy wykryje zmiany w kodzie źródłowym.

Do instalowania Global Tools używa się polecenia `dotnet tool install -g`, gdzie opcja `-g` oznacza zainstalowanie narzędzia globalnie. Do odinstalowania używa się `dotnet tool uninstall -g`.

Istnieje także możliwość instalacji narzędzia lokalnie dla konkretnego projektu za pomocą opcji `--tool-path`. Może to być przydatne, jeśli chcesz używać różnych wersji narzędzi dla różnych projektów.