.net core publish - po co są te pliki poziom wyżej od wynikowego /publish?

Googlowałem ale nie mogę znaleźć odpowiedzi.

Za każdym razem, gdy wykonuję polecenie dotnet publish jako self-contained, tworzone są:

• katalog dla wybranej architektury (logiczne),
• ... w nim pliki wykonywalne, dll, pdb, .runtimeconfig.json etc. (co to jest i po co?),
• ... oraz katalog /publish, zawierający to samo co wyżej, ale dodatkowo biblioteki .net core i inne dołączone (logiczne, self-contained).

Wpadłem w .net core na chwilę, ktoś mi wyjaśni dlaczego publikują się także te "golasy" nad katalogiem /publish? :) Mogę je bezpiecznie usuwać i dystrybuować wyłącznie to, co w publish?

O ile dobrze Cię rozumiem, to problemem dla Ciebie jest właśnie to self-contained. On wtedy dorzuca wszystko to, co musi, żeby uruchomić aplikację. Jeśli masz serwer, który obsługuje .net core, to jest Ci to niepotrzebne. Jeśli masz serwer bez tego, to musisz mieć.

Juhas napisał(a):

O ile dobrze Cię rozumiem, to problemem dla Ciebie jest właśnie to self-contained. On wtedy dorzuca wszystko to, co musi, żeby uruchomić aplikację. Jeśli masz serwer, który obsługuje .net core, to jest Ci to niepotrzebne. Jeśli masz serwer bez tego, to musisz mieć.

Chyba nie do końca o to mi chodzi. Miałem na myśli to, że komenda dotnet publish tworzy podwójne kopie dokładnie tych samych plików wykonywalnych z programem, które wrzuca do, przykładowo:

/Release/netcoreapp2.2**/win-x64/Program.exe
/Release/netcoreapp2.2/win-x64/publish/**Program.exe

... z tą różnicą, że w publish będą dołączone wszystkie zależności, a w katalogu nadrzędnym tylko exe, dll i jeszcze z 5 plików.

Wszystko to się pojawia od zera za każdym wywołaniem komendy dotnet publish -c Release -r win-x64 --self-contained.

Podkatalog publish i kopie plików wykonywalnych pojawiają się zawsze, niezależnie czy zrobię --self-contained false, czy nie. Nie rozumiem po co są te duplikaty.

(Nie mówiąc już o tym, że elegancko by było mieć plik wykonywalny w katalogu nadrzędnym, a zależności w podkatalogu typu vendor, ale tak się w dotnet chyba nie da ;))

Znalazłem odpowiedź na SO: https://stackoverflow.com/questions/49939630/why-does-dotnet-publish-create-2-copies-of-the-same-files

Pliki powyżej katalogu publish są generowane przez krok wykonujący komendę build, a następnie kopiowane wraz z zależnościami przez krok publish do podkatalogu /publish. "Przestrzeń dyskowa jest dzisiaj tania, więc to chyba nie problem" heh ;)