Wsteczna kompatybilność .NET 7

Zauważyłem w Fedora Linux 37 i w Windows 10, jak się zainstaluje .NET Runtime 7, do domyślnie nie można uruchomić choćby najprostszej apki konsolowej skompilowanej dla .NET 6. Pokazuje się komunikat You must install or update .NET to run this application. Potem Architecture x64 i Framework Microsoft.NETCore.App version 6.0.0 (x64).

Wywołuję w sposób najbardziej standardowy, czyli dotnet testapp.dll. Doinstalowanie runtime .NET 6 rozwiązuje problem.

Czy .NET 7 jest wstecznie kompatybilny z .NET 6? Jeżeli nie jest kompatybilny, to nie mam więcej pytań.

A jeżeli jest kompatybilny, to w jaki sposób zmusić aplikację dla .NET 6 do uruchomienia w .NET 7? Czy trzeba zmienić coś w projekcie Visual Studio lub VSC z OmniSharp,czy coś w jednym z plików w folderze "publish" po wytworzeniu publikacji?

Póki co, nie znalazłem opisu innego sposobu niż zainstalowanie runtime 6.0.

Aby trochę rozjaśnić, o co mi chodzi, załóżmy następujący scenariusz: Są dwa komputery, na jednym jest tylko runtime .NET 7, a na drugim jest tylko runtime .NET 6. Nie mam dostępu do praw admina, mam tylko standardowego użytkownika. Jak spowodować, żeby jeden i ten sam program .NET działał na obu komputerach? Sam proces tworzenia i kompilacji przebiega na trzecim komputerze, na którym mogą być zainstalowane obie wersje SDK.

Możesz publikować jako self-contained, wtedy nie interesuje cie czy ktoś w ogole ma runtime. Zwieksza to oczywiscie rozmiar wynikowy.
Albo budować dla kilku runtime, wtedy w csproj dajesz np:

<TargetFrameworks>net6.0;net7.0</TargetFrameworks>

nie, w .net 7 wprowadzono sporo breaking changes, nie jest wstecznie kompatybilny https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0
to nie powinno mieć dużego znaczenia bo możesz robić apki self-contained i z trimmingiem nie będą zajmowały dużo miejsca

Właściwie doczytując to jeśli nie użyłeś żadnego feature'a z listy breaking changes to możesz zezwolić apce na odpalenie się na nowszym runtimie dopisując w pliku projektu

<PropertyGroup>
  <RollForward>Major</RollForward>
</PropertyGroup>

lub odpalać przez

dotnet testapp.dll --roll-forward Major

oczywiście lepszym i bezpieczniejszym rozwiązaniem będzie sprecyzowanie listy obsługiwanych wersji w TargetFrameworks, odpalanie libki w nowszym runtimie może zmienić w skrajnych wypadkach jej działanie. Zdarzyło mi się to kiedyś na .net framework 3.5 - ta sama libka zareferencjowana z projektu z .net framework 4.0 zachowywała się inaczej w pewnym miejscu przez wprowadzenie obsługi kowariancji w interfejsach.

obscurity napisał(a):

Właściwie doczytując to jeśli nie użyłeś żadnego feature'a z listy breaking changes to możesz zezwolić apce na odpalenie się na nowszym runtimie dopisując w pliku projektu

<PropertyGroup>
  <RollForward>Major</RollForward>
</PropertyGroup>

lub odpalać przez

dotnet testapp.dll --roll-forward Major

oczywiście lepszym i bezpieczniejszym rozwiązaniem będzie sprecyzowanie listy obsługiwanych wersji w TargetFrameworks, odpalanie libki w nowszym runtimie może zmienić w skrajnych wypadkach jej działanie. Zdarzyło mi się to kiedyś na .net framework 3.5 - ta sama libka zareferencjowana z projektu z .net framework 4.0 zachowywała się inaczej w pewnym miejscu przez wprowadzenie obsługi kowariancji w interfejsach.

Sprawdziłem i działają oba sposoby. Jedynie polecenie z parametrem musi być w tej kolejności: dotnet --roll-forward Major testapp.dll, wtedy też działa na niezmodyfikowanej apce. Ciekawe, że Microsoft nie wpadł na to, żeby domyślnie dodawać ten parametr. Rozumiem, ze tylko w konkretnych przypadkach apka z .NET 6 może się wysypać na .NET 7 i odwrotnie z powodu niepełnej kompatybilności, w większości powinno działać bez zakłóceń.