Как получить текущий каталог проекта из кода C# при создании пользовательской задачи MSBuild?
вместо того, чтобы запускать внешнюю программу с жестко заданным путем, я хотел бы получить текущий проект Dir. Я вызываю внешнюю программу, используя процесс в пользовательской задаче.
Как бы я это сделал? домен приложений.CurrentDomain.BaseDirectory просто дает мне расположение VS 2008.
15 ответов:
вы можете попробовать один из этих двух методов.
скажите, какой из них вам кажется лучше
Это позволит получить каталог проекта
это также даст вам каталог проекта, Перейдя на два уровня вверх от текущего исполняемого каталога (это не вернет каталог проекта для каждой сборки, но это наиболее распространенный).
конечно, вы хотели бы содержать это в какой-то проверки/обработки ошибок.
Если вы хотите узнать, что такое каталог, в котором находится ваше решение, вам нужно сделать это:
Если вы позволите только с GetCurrrentDirectory() метод, вы получаете папку сборки независимо от того, если вы отладки или выпуска. Я надеюсь, что это поможет! Если вы забудете о проверках, это будет выглядеть так:
Если проект выполняется на IIS express, то Environment.CurrentDirectory может указывать, где находится IIS Express ( путь по умолчанию будет C:\Program файлы (x86)\IIS Express ), а не туда, где находится проект.
это, вероятно, наиболее подходящий путь к каталогу для различных видов проектов.
это определение MSDN.
возвращает базовый каталог, который сопоставитель сборок использует для поиска сборки.
Я тоже это искал. У меня есть проект, который запускает HWC, и я хотел бы сохранить веб-сайт из дерева приложений, но я не хочу держать его в каталоге отладки (или выпуска). FWIW, принятое решение (и это тоже) только идентифицирует каталог, в котором работает исполняемый файл.
найти этот каталог, я использую
Если вы хотите получить путь к папке bin
может быть, есть лучший способ =)
еще одно несовершенное решение (но, возможно, немного ближе к идеалу, чем некоторые другие):
эта версия вернет текущие проекты’ папка, даже если текущий проект не является Startup Project для решения.
первый недостаток заключается в том, что я пропустил все проверки ошибок. Это можно исправить достаточно легко, но это должно быть проблемой только в том случае, если вы храните свой проект в корневом каталоге для диска или используете соединение в вашем пути (и это соединение является потомком папки решения), поэтому этот сценарий маловероятен. Я не совсем уверен, что Visual Studio может справиться с любой из этих настроек в любом случае.
еще одна (более вероятная) проблема, с которой вы можете столкнуться, заключается в том, что имя проекта должны сопоставьте имя папки для проекта, чтобы он был найден.
другая проблема может быть в том, что проект должен находиться в папке решения. Это, как правило, не проблема, но если вы использовали Add Existing Project to Solution возможность добавить проект в решение, то это может быть не так, как ваше решение организовано.
наконец, если вы приложение будет изменять рабочий каталог, вы должны сохранить это значение, прежде чем делать это, потому что это значение определяется относительно текущего рабочего каталога.
после того, как я, наконец, закончил полировку своего первого ответа относительно использования публичных строк для получения ответа, мне пришло в голову, что вы, вероятно, можете прочитать значение из реестра, чтобы получить желаемый результат. Как оказалось, этот маршрут был еще короче:
во-первых, вы должны включить Microsoft.Win32 пространство имен, так что вы можете работать с реестром:
примечание к этому ответу:
Я использование Visual Studio 2008 Professional Edition. Если вы используете другую версию, (т. е. 2003, 2005, 2010; и т. д.), то вам может потребоваться изменить часть «версия» строки подраздела (т. е. 8.0, 7.0; и т. д.).
Если вы используете один из моих ответов, и если это не слишком много, чтобы спросить, то я хотел бы знать, какой из моих методов вы использовали и почему. Удача.
у меня была аналогичная ситуация, и после бесплодных Googles я объявил публичную строку, которая модифицирует строковое значение пути отладки / выпуска, чтобы получить путь к проекту. Преимущество использования этого метода заключается в том, что, поскольку он использует каталог проекта currect, не имеет значения, работаете ли вы из каталога отладки или каталога выпуска:
тогда вы сможете вызвать его, когда захотите, используя только одну строку:
Это должно работать в большинство случаях.
используйте это, чтобы получить каталог проекта (работал для меня):
Как правильно указать локальный путь?
2 ответа 2
У вас есть 4 варианта действий, ну или произвольная их комбинация, по вкусу и потребностям.
1. Предоставить выбор пользователю
В этом случае просто открываете FolderBrowserDialog и получаете путь к папке через свойство FolderBrowserDialog.SelectedPath. Это удобно, если требуется частая смена пути к файлам по желанию пользователя.
2. Указать пути к файлам в конфигурации
Явно прописываете путь в AppСonfig, через стандартный механизм Settings, таким образом можно будет указать путь к папке перед запуском программы в конфигурационном файле приложения. Это удобно, если не требуется часто менять пути к файлам.
3. Указать путь относительно рабочего каталога
Этот и следующий варианты похожи, но не одинаковы. Рабочим каталогом, по умолчанию считается текущий каталог командной строки, или любой оболочки над командной строкой, вроде FAR или TotalComander. Это значит, что он вовсе не обязан совпадать с каталогом, в котором находится исполняемый файл. Получить путь к рабочему каталогу можно так: Environment.CurrentDirectory или так: Directory.GetCurrentDirectory(), тогда путь к вашей папке может быть задан так:
Этот вариант хорош тем, что позволяет программе работать именно в том каталоге, в котором она была вызвана.
Важное замечание, запуск из командной строки и запуск при помощи ярлыка работают по разному. В свойствах ярлыка, рабочий каталог может быть задан явно, в противном случае, рабочим каталогом считается каталог исполняемого файла.
4. Указать путь относительно исполняемого файла
Можно принудительно заставить всегда использовать каталог исполняемого файла, но для этого его нужно получить. Тут тоже есть несколько вариантов. Для WinForms этот каталог можно получить с помощью Application.ExecutablePath. Более универсальный вариант AppDomain.CurrentDomain.BaseDirectory, в этом случае вы всегда получите путь к каталогу в котором лежат сборки вашей программы. Результат будет выглядеть так:
Этот вариант стоит выбрать, если программа должна работать с файлами строго в своих директориях, например по соображениям безопасности, или еще каким системным ограничениям.
5 Истина где-то рядом
На самом деле ни одна из программ не использует только один из этих вариантов. Обычно используется некоторая комбинация приведенных вариантов, с указанием порядка поиска файлов по всем возможным расположениям, с выдачей ошибки или диалога для явного указания размещения, если файлы не удалось обнаружить ни в одном известном месте.
Получить путь к папке приложения
Помощь в написании контрольных, курсовых и дипломных работ здесь.
Получить путь к папке Решения
Подскажите, как узнать путь к папке Решения? Только НЕ через Она выдаёт путь к екзешнику.
Получить полный путь к папке
Возможно ли как-то получить полный путь к папке (есть только её название) находящейся на.
RGDriftRG, используй свойство Application.StartupPath.
Metall_Version, «текущий каталог» может измениться при работе с файловыми диалогами или запуске приложения с elevated правами. Вопроизвести это на Windows 7 у меня правда не получилось.
Вообще же смысл в этом что т.н. «текущий каталог» контролируется не нами и лучше полагаться на способ который будет 100% работоспособным. Свойство Application.StartupPath именно таким и является.
Как получить путь к папке процеса?
Здравствуйте! В диспетчере висит процесс «program.exe». Нужно сделать так, что бы программа.
Правильно задать путь к файлу, который находится в папке в директории приложения
Добрый день! Использую в своей программе файлы настроек, лог файл и т.д. Все файлы ложу в папку.
Как получить все файлы соответствующие маске, если путь к папке и маска в одной строке
Всем привет! Если нам передают строку типа: «C:\temp\*.xml» Как мне получить список всех.
Получение путей к системным каталогам
Получение путей к системным каталогам.
Появление этого поста связано с
одной из стандартных проблем, любого программиста работающего под windows,
проблема называется: зависимость от путей файлов, каталогов, в операционной системе.
Рано или поздно такие проблемы возникают у программиста,
он должен знать средство абстракции от путей к папкам и файлам.
Простой жизненный пример:
Программист, решил понадеется что на windows XP(Vista и.т.д.) папка
program files всегда и везде(на любом ПК) находиться здесь: C:\Program Files
и установил папку со своей программой имменно туда, и работа
с файлами в его программе была связана с путем C:\Program File\My prog\data
но прошло время и человек задумался,
а если системная папка может находиться на диске D, D:\Program Files, вот тут и есть суть проблемы,
программисту: нужно некое средство определяющее пути системных директорий ОС.
Прототип функции получения системных путей:
Коды проверены на VS2008.
Заголовочный файл: stdafx в данном примере особо не нужен,
просто я создал стандартное приложение и среда разработки навязала мне этот файл.
Ниже приведен список допустимых значений: для параметра: csidl
#define CSIDL_ADMINTOOLS 0x0030
// Административные инструменты текущего пользователя (например консоль MMC). Win2000+
#define CSIDL_CDBURN_AREA 0x003b
// Папка для файлов, подготовленных к записи на CD/DVD
// (Обычно C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\CD Burning)
#define CSIDL_COMMON_ADMINTOOLS 0x002f
// Папка, содержащая инструменты администрирования
#define CSIDL_COMMON_APPDATA 0x0023
// Папака AppData для всех пользователей. (обычно C:\Documents and Settings\All Users\Application Data)
#define CSIDL_COMMON_DOCUMENTS 0x002e
// Папка «Общие документы» (обычно C:\Documents and Settings\All Users\Documents)
#define CSIDL_COMMON_TEMPLATES 0x002d
// Папка шаблонов документов для всех пользователей (Обычно C:\Documents and Settings\All Users\Templates)
#define CSIDL_COMMON_MUSIC 0x0035
// Папка «Моя музыка» для всех пользователей. (обычно C:\Documents and Settings\All Users\Documents\My Music)
#define CSIDL_COMMON_PICTURES 0x0036
// Папка «Мои рисунки» для всех пользователей. (обычно C:\Documents and Settings\All Users\Documents\My Pictures)
#define CSIDL_COMMON_VIDEO 0x0037
// Папка «Моё видео» для всех пользователей (C:\Documents and Settings\All Users\Documents\My Videos)
#define CSIDL_COMPUTERSNEARME 0x003d
// Виртуальная папка, представляет список компьютеров в вашей рабочей группе
#define CSIDL_CONNECTIONS 0x0031
// Виртуальная папка, представляет список сетевых подключений
#define CSIDL_LOCAL_APPDATA 0x001c
// AppData для приложений, которые не переносятся на другой компьютер (обычно C:\Documents and Settings\username\Local Settings\Application Data)
#define CSIDL_MYDOCUMENTS CSIDL_PERSONAL
// Виртуальный каталог, представляющий папку «Мои документы»
#define CSIDL_MYMUSIC 0x000d
// Папка «Моя музыка»
#define CSIDL_MYPICTURES 0x0027
// Папка «Мои картинки»
#define CSIDL_MYVIDEO 0x000e
// Папка «Моё видео»
#define CSIDL_PROFILE 0x0028
// Папка пользователя (обычно C:\Documents and Settings\username)
#define CSIDL_PROGRAM_FILES 0x0026
// Папка Program Files (обычно C:\Program Files)
#define CSIDL_PROGRAM_FILESX86 0x002a
#define CSIDL_PROGRAM_FILES_COMMON 0x002b
// Папка Program Files\Common (обычно C:\Program Files\Common)
#define CSIDL_PROGRAM_FILES_COMMONX86 0x002c
#define CSIDL_RESOURCES 0x0038
// Папка для ресерсов. Vista и выше (обычно C:\Windows\Resources)
#define CSIDL_RESOURCES_LOCALIZED 0x0039
#define CSIDL_SYSTEM 0x0025
// Папака System (обычно C:\Windows\System32 или C:\Windows\System)
#define CSIDL_SYSTEMX86 0x0029
#define CSIDL_WINDOWS 0x0024
// Папка Windows. Она же %windir% или %SYSTEMROOT% (обычно C:\Windows)
Исходный код первой программы:
Суть кода такова есть имя: файла не путь: оно задается пользовательской программой.
путь к самой папке: где будет сохранен файл, уже известен:
нам прописывать его не надо, так же можно не беспокоиться:
на каком диске расположена системная директория,
функция: SHGetSpecialFolderPath знает где находиться системная директория:
именно это и абстрагирует нас от особенностей местоположения каталогов.
Вот так выглядит стандартный путь(в программе выше) к папке с файлом:
C:\Program Files\My folder\data
Что бы пример сработал корректно: надо создать папки My folder и data.
Небольшое отступление от темы:
программисту: помимо средств абстракции от путей каталогов: нужны средства установки программ:
так называемые установщики(инсталляторы).
Суть установщика скопировать упакованные файлы вашей программы:
в определенные вами директории(инсталлятор создает нужные директории если их нет в файловой системе).
Из инструментов для создания инсталляторов могу посоветовать: InstallShield 10.5 или новее,
отличное средство быстрого создания инсталляторов, это не реклама, а совет.
Исходный код второй программы:
Суть кода: следующая:
Имеется массив строк, и меню для работы с этим массивом:
с помощью меню мы можем сохранять, загружать массив, заполнять, выводить.
Подробная суть кода есть в комментариях, повторяться не буду,
важный момент: это то, что мы не имеем дело с путями, клиент не должен
предоставлять путей файлов, клиент должен предоставлять только имена файлов,
путь к каталогу известен заранее: и он всегда правильный потому, как система определяет
букву диска(и саму sys директорию) на котором находиться системная директория.
//////////////////////////////////////////////////////////////////
А если системная директория в какой-нибудь версии Windows,
вдруг перестала называться Program Files, тогда важность
использования SHGetSpecialFolderPath возрастает в разы.
Обычный пример из жизни: в одной ОС Windows системная папка тут: C:\WINNT\SYSTEM32
а в другой ОС WIndows здесь: C:\WINDOWS\system32
От такой зависимости можно избавиться используя: SHGetSpecialFolderPath
///////////////////////////////////////////////////////////////////
Примечание к функциям save и proc: если клиент передаст путь, а не имя файла,
естественно процесс сохранения или загрузки не произойдет.
Еще одно примечание: если в пути присутствуют русские буквы, надо преобразовывать
весь путь в WCHAR, может особенность какая то, но в VS2008 ofstream и ifstream
не открывают файл если в пути присутствуют русские буквы, если преобразовать в WCHAR то все ok.
О функции преобразования:
MultiByteToWideChar: http://msdn.microsoft.com/en-u. 02786.aspx
Я думаю, что без MultiByteToWideChar ofstream и ifstream лучше не использовать.
Пример к данному примечанию ниже:
Путь к целевому каталогу данной программы: где будет храниться файл(файлы) у меня таков:
C:\Documents and Settings\Ignat\Мои документы\My folder\data
У вас: заместо Ignat будет стоять скорее всего другое имя.
Вывод к сказанному:
Функция SHGetSpecialFolderPath предоставляет программисту независимость
от разположения системных каталогов, следовательно гарантированна,
корректная работа его приложений, установленных в системные каталоги.
О ShellExecute :
Это функция для запуска приложений и документов.
ShellExecute: http://msdn.microsoft.com/en-u. S.85).aspx
Как использовать: ShellExecute:
Без SHGetSpecialFolderPath, функцию ShellExecute использовать, думаю не имеет смысла,
почему: можно понять прочитав весь пост.
Просьба к форумчанам:
Форматы путей к файлам в системах Windows
Традиционные пути DOS
Стандартный путь DOS может состоять из трех компонентов:
Если присутствуют все три компонента, путь является абсолютным. Если буква тома или диска не указана и имя каталога начинается с символа разделителя каталогов, такой путь задан относительно корня текущего диска. В противном случае путь задан относительно текущего каталога. В следующей таблице показаны некоторые возможные пути к каталогам и файлам.
В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера.
Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.
UNC-пути
UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:
Ниже приводятся некоторые примеры UNC-путей:
Пути к устройствам DOS
В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:
Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:
Путь к устройству DOS состоит из следующих компонентов:
Описатель пути к устройству ( \\.\ или \\?\ ), который идентифицирует путь как путь к устройству DOS.
Символьная ссылка на «реальный» объект устройства (C: в случае имени диска или Volume
Для UNC-путей к устройствам часть сервера или общего сетевого ресурса образует том. Например, в пути \\?\server1\e:\utilities\\filecomparer\ часть server1\utilities представляет сервер или общий сетевой ресурс. Это важно при вызове такого метода, как Path.GetFullPath(String, String) с сегментами с относительным путем к каталогу, поскольку переход дальше тома невозможен.
Пример. Способы задать ссылку на один и тот же файл
В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.
Нормализация путей
Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:
Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.
Идентификация пути
На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:
Тип пути определяет, будет ли каким-либо образом применяться текущий каталог. Кроме того, от типа пути зависит применяемый корень.
Работа с устаревшими устройствами
Применение текущего каталога
Канонизация разделителей
Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( \ ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.
Вычисление относительных компонентов
Если обнаруживается одна точка, текущий сегмент удаляется, поскольку он ссылается на текущий каталог.
Если обнаруживаются две точки, удаляются текущий и родительский сегмент, поскольку в этом случае задается ссылка на родительский каталог.
Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C:\ ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \\Server\Share ) и префикс пути к устройству для путей к устройствам ( \\?\ или \\.\ ).
Удаление знаков
Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:
Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент, состоящий из одной или двух точек, нормализуется на предыдущем шаге. Сегмент, состоящий из трех или более точек, не нормализуется и фактически представляет собой допустимое имя файла или каталога.)
Если путь не заканчивается разделителем, удаляются все конечные точки и пробелы (U+0020). Если последний сегмент содержит только одну или две точки, к нему применяется приведенное выше правило для относительных компонентов.
Это правило устанавливает, что вы можете создать имя каталога с конечным пробелом, добавив разделитель после пробела.
Создавать имена каталогов или файлов с конечным пробелом нельзя. Наличие конечных пробелов может затруднить или исключить возможность доступа к каталогу. В связи с этим при попытке обработать каталоги или файлы, имена которых содержат конечные пробелы, происходит сбой приложения.
Пропуск нормализации
Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.
Зачем нужно пропускать нормализацию? Существует три основных причины:
Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена.
Пропуск нормализации и проверки максимальной длины пути является единственным отличием между двумя видами синтаксиса путей к устройствам. В остальных аспектах они идентичны. Пропуск нормализации следует использовать с осторожностью, поскольку в этом случае легко получить пути, при работе с которыми в обычных приложениях будут возникать трудности.
Регистр символов и файловая система Windows
Особенность файловой системы Windows заключается в том, что пользователи и разработчики, имеющие дело с другими операционными системами, могут сталкиваться с проблемами из-за того, что в именах каталогов и путях не учитывается регистр символов. Это значит, что в именах каталогов и файлов сохраняется регистр строк, используемый в момент их создания. Например, вызов метода