Niedawno w projekcie pisałem małą apkę która wykonywała pewne działanie, które muszą być uruchamiane cyklicznie. W celu uzyskania dostępu do katalogu aplikacji użyłem zmiennej
System.Environment.CurrentDirectory .
Wszystko działało podczas debugowania. Jakies było moje zdziwienie, gdy okazało się, że zmienna ta wskazuje na katalog C:WindowsSystem32 podczas uruchamiania procesu przez Task Scheluder, zamiast katalogu aplikacji. Po długich lecz owocnych 🙂 poszukiwaniach udało mi się znaleźć rozwiązanie. Pewnym i niezawodnym sposobem na uzyskanie katalogu w którym znajduje się aplikacja jest :
System.IO.Path.GetDirectoryName(System.Reflection.Assembly._ GetExecutingAssembly().Location)
.
To jak już przy ścieżkach jesteśmy to zapytam z ciekawości ilu z Was używa Uri.MakeRelativeUri do zbudowania ścieżki względnej?
Większość internetu prowadzi do takiego rozwiązania nie mówiąc nic o pułapkach tej funkcji. Spróbujcie dodać do jednej czy drugiej ścieżki hasha i zobaczcie jak to wtedy działa 🙂
Niby hash jest raczej nieużywany, ale nie można go wykluczyć. Odkryłem to przypadkiem odpalając jeden projekt w folderze "testowym" z C# w nazwie.. też można spędzić trochę czasu na debugowaniu tego 🙂
Próbowałem to zaraz później powtórzyć i nie mogłem 🙂 Okazało się, że mnie pamięć oszukała.. to nie MakeRelativeUri nawala.. to sama obsługa klasy Uri.
http://fidek.org/UriHash.png
Mieliśmy w kodzie new Uri(Assembly.GetExecutingAssembly().CodeBase), a CodeBase jest zwracany w formacie z prefixem file:/// który powoduje takie właśnie traktowanie hasha. Dwa ostatnie przykłady pokazują jak to łatwo rozwiązać.
Przy tworzeniu taska w Task Schedulerze można ustawić katalog startowy ręcznie i wówczas Environment.CurrentDirectory będzie OK.