Jeszcze jedno niedoskonałe rozwiązanie (ale być może trochę bliższe doskonałemu niż niektóre inne):
protected static string GetSolutionFSPath() {
return System.IO.Directory.GetParent(System.IO.Directory.GetCurrentDirectory()).Parent.Parent.FullName;
}
protected static string GetProjectFSPath() {
return String.Format("{0}\\{1}", GetSolutionFSPath(), System.Reflection.Assembly.GetExecutingAssembly().GetName().Name);
}
Ta wersja zwróci folder bieżących projektów, nawet jeśli bieżący projekt nie jest Startup Project
przeznaczony dla rozwiązania.
Pierwsza wada polega na tym, że pominąłem wszystkie sprawdzanie błędów. Można to naprawić dość łatwo, ale powinno to stanowić problem tylko wtedy, gdy przechowujesz projekt w katalogu głównym dysku lub używasz skrzyżowania w ścieżce (i to skrzyżowanie jest elementem podrzędnym folderu rozwiązania), więc ten scenariusz jest mało prawdopodobny . Nie jestem do końca pewien, czy Visual Studio i tak poradzi sobie z którąkolwiek z tych konfiguracji.
Innym (bardziej prawdopodobnym) problemem, na który możesz się natknąć, jest to, że nazwa projektu musi być zgodna z nazwą folderu projektu, aby można go było znaleźć.
Innym problemem, który możesz mieć, jest to, że projekt musi znajdować się w folderze rozwiązania. Zwykle nie stanowi to problemu, ale jeśli użyłeś Add Existing Project to Solution
opcji dodania projektu do rozwiązania, może to nie być sposób zorganizowania rozwiązania.
Na koniec, jeśli twoja aplikacja będzie modyfikować katalog roboczy, powinieneś zapisać tę wartość zanim to zrobisz, ponieważ ta wartość jest określana względem bieżącego katalogu roboczego.
Oczywiście to wszystko oznacza również, że nie możesz zmieniać domyślnych wartości opcji Build
-> Output path
lub Debug
-> Working directory
projektów w oknie dialogowym właściwości projektu.