Kopiowanie do katalogu wyjściowego w VS

Kiedy program korzysta z zewnętrznych plików (np. obrazków, dźwięków, itp.), które docelowo mają się znaleźć razem z nim w tym samym katalogu, w Visual Studio pojawia się pewien problem. Otóż nie bardzo wiadomo, gdzie dokładnie pliki te należy umieścić, by aplikacja miała do nich dostęp. Zazwyczaj najwygodniej byłoby wrzucić je do katalogu głównego z projektem i/lub całym solution. Tyle że wersje skompilowane trafiają zwykle do katalogów w rodzaju Debug czy Release, czyli folderów pod- lub równorzędnych. Skutek jest często taki, że aplikacja nie potrafi znaleźć potrzebnych plików, gdyż nie znajdują się one we wspomnianych katalogach ze skompilowanymi wersjami programu.

Można je oczywiście ręcznie tam skopiować, ale to niezbyt dobre rozwiązanie – zwłaszcza, jeśli ręcznie musielibyśmy te pliki aktualizować przy każdej zmianie (i to w dwóch miejscach!). Alternatywą jest ustawienie w opcjach projektu odpowiedniego katalogu roboczego (working directory), dzięki czemu moglibyśmy otwierać nasze niezbędne pliki posługując się ścieżkami względnymi. W finalnej wersji programu należałoby jednak pozbyć się tej zależności od katalogu roboczego. Jej pozostawanie sprawiłoby bowiem, że nasz program nie odszukałby potrzebnych plików, jeśli tylko zostałby uruchomiony z innym katalogiem roboczym (np. z poziomu wiersza poleceń lub przy pomocy odpowiednio przygotowanego skrótu). Byłby to ewidentny błąd.
Dlatego też lepiej, aby wszystkie pliki “towarzyszące” otwierać przy pomocy ich pełnych ścieżek, złożonych przy pomocy ścieżki do katalogu z plikiem EXE. Ją zaś można pobrać na wiele sposobów, w zależności od języka i platformy. W Windows API można na przykład użyć funkcji GetModuleFileName (do uzyskania pełnej ścieżki do pliku wykonywalnego) oraz PathRemoveFileSpec (do wyrzucenia z niej nazwy pliku). W .NET będzie to pole System.Windows.Forms.Application.ExecutablePath w połączeniu np. z metodą System.IO.Path.GetDirectoryName.

Wówczas jednak dochodzimy do punktu wyjścia, jako że podczas uruchamiania w debuggerze program będzie szukał swoich plików w katalogach Debug/Release. Można temu w prosty sposób zaradzić. Wystarczy mianowicie:

1. Dodać potrzebne pliki do projektu w Visual Studio – zupełnie tak samo, jak pliki z kodem źródłowym.
2. Odpowiednio ustawić dla nich właściwość Copy to Output Directory.

Domyślną wartością dla tej właściwości jest Do not copy. Wybranie wariantu Copy always sprawi, że zawsze po kompilacji Visual Studio skopiuje wskazany plik do katalogu z plikami wykonywalnymi (np. Debug). Możemy też wybrać Copy if newer, przez co kopiowanie zostanie wykonane tylko wtedy, jeśli od ostatniego zbudowania projektu nasz plik uległ zmianie. Ten wariant jest zwykle najrozsądniejszy, bo oszczędza niepotrzebnego kopiowania tych samych wersji plików.

Be Sociable, Share!

• 
• 

Be Sociable, Share!

• 
• 

• Tweet
•