Ostatnio na warsztatach przytrafiła nam się sytuacja, że pewien deloy nie zależnie jak próbowaliśmy go odpalić nam po prostu nie działał. A robiliśmy wszystko przez dobre 20 minuty (klikanie po VSTS nie jest łatwe…) ;) A wszystko rozbiło się o jedna prostą opcje, którą można ustawić na pliku w projekcie w Visual Studio.
Mianowicie, dla każdego z plików możemy ustalić dwie opcje – Build Action i Copy to Output Directory. W zależności od typu pliku jaki tworzymy, te opcje są domyślnie ustawiane za nas. I przeważnie defaultowe ustawienia są dobre. Dodajemy nowy plik cs? Build Action jest na Compile i Copy to Output Directory na Do not copy. Web.config zaś ma opcję Content i Do not copy.
Co to robi?
Copy to Output Direcory kopiuje pliku do katalogu wynikowego do którego aplikacja jest kompilowana. W przypadku Console Application czy Library, jest to bin\Debug|Release etc. To znaczy, że nasz plik (w zależności od opcji wybranej) będzie lub nie będzie zawsze do tego katalogu kopiowany.
Build Action zaś wykona określoną akcję na pliki w trakcie budowania projektu. To może być załączenie pliku jako zasobu, kompilacja czy też pominięcie pliku. Ale także istnieje opcja potraktowania pliku jako zawartości (Content). Content – czyli weź plik i załącz go do projektu zgodnie z planem publikowania/deployowania aplikacji.
Dla aplikacji windowsowych, przeważnie Build Action - Content, nie ma znaczenia, do póki nie wykorzystujemy opcji publikowania aplikacji – a przez cały okres mojego programowania w .NET próbowałem to zrobić 2 razy. Za to, duże znaczenie ma Copy to Output Directory. Opcja inna niż Do not copy skopiuje plik do bin\Debug|Release.
Dla aplikacji webowch zaś Copy to Output Directory powoduje, że plik ląduje w katalogu bin – w którym są wszystkie DLLki, ale nie ma tam strony. Strona znajduje się w katalogu root (katalog projektu), tam też znajdują się wszystkie pliki, które nas interesują – takie jak js, css, cshtml etc. By te pliki były uwzględnione w trakcie publikowania/deployowania aplikacji webowej, potrzebne jest poprawne ustawienie Build Action - Content na pliku. Spowoduje to, załączenie plików jak artefaktów a nie jako wynik kompilacji (bin). W przeciwnym wypadku, nasz plik nigdy nie zostanie załączony do wersji która będzie deployowana.
Podsumowanie
U nas rozbiło się wszystko o plik Dockerfile, który miał zaznaczoną opcję Build Action - None, i Copy to Output Directory - Always. Czyli w katalogu bin, lądował on cały czas, ale nigdy tam gdzie chcieliśmy go mieć – czyli w root.
Warto więc znać różnicą pomiędzy tymi dwoma opcjami i co daje jedna i co daje druga.
Warto jeszcze dodać, że ustawienie jakiegoś pliku w projekcie na “Copy always” spowoduje, że projekt w którym będzie się znajdował się ten plik zawsze będzie rebuildowany – nawet jeśli w kodzie nic się nie zmieniło. Może mieć to znaczący wpływ na czas budowania solucji.
true, jeszcze jest tak, że Copy to Output Directory wykonuje się niezależnie od Build Action (w myśl “None”)
Comments are closed.