Настройка свойства OutputPath проекта с помощью Visual Studio Automation
Я пишу пакет VSIX, чтобы позволить пользователю массово редактировать свойство OutputPath всех активных конфигураций проектов в загруженном в данный момент решении (см. невероятно раздражающий Шаг #4 здесь).
Я столкнулся с очень специфической проблемой: при установке свойства на значение, содержащее макросы (например, "$(SolutionDir)binDebug" Значение, записанное в .csproj экранируется следующим образом:
<OutputPath>%24%28SolutionDir%29binDebug</OutputPath>
Который, вместо того, чтобы позволить MSBuild расширить макрос, создает фактический физический папка с именем $(SolutionDir). Я хотел бы как-то обойти это бегство.
Документация MSDN неудивительно отсутствует в этой области.
Мой исходный код выглядит следующим образом:
private void MenuItemCallback(object sender, EventArgs e)
{
SolutionWideOutputDialogWindow dialog = new SolutionWideOutputDialogWindow();
dialog.ShowModal();
if (!dialog.DialogResult.HasValue || !dialog.DialogResult.Value)
{
return;
}
string requestedOutputPath = dialog.outputPathTextBox.Text;
Solution2 solution = _dte2.Solution as Solution2;
if (solution == null)
{
return;
}
Projects projects = solution.Projects;
foreach (Project project in projects)
{
Property outputPath = project.ConfigurationManager.ActiveConfiguration.Properties.Item("OutputPath");
outputPath.Value = requestedOutputPath;
project.Save();
}
}
Очень ценю чью-либо помощь.
2 ответов:
Visual Studio, к сожалению, экранирует специальные символы при редактировании из свойств проекта.
Чтобы исправить это, отредактируйте свой .csproj файл непосредственно в текстовом редакторе.
Например, изменение:
<OutputPath>%24%28SolutionDir%29\bin\Debug\</OutputPath>Кому:
<OutputPath>$(SolutionDir)\bin\Debug\</OutputPath>
Вот что я в итоге сделал:
Задача, которую я пытался решить, не повторяется (D. R. Y.) И не задает выходной каталог для всего решения (в решении с большим количеством проектов)-то есть при компиляции решения все проекты будут иметь свой выходной каталог, установленный в нечто вроде
$(SolutionDir)bin\Debugили$(SolutionDir)bin\Release. Стоит отметить, что некоторые проекты включаются в разные репозитории и в несколько решений.Сначала я создал файл MSBuild (A
<Project>XML - называется онMySolution.sln.targets). В нем я определил<PropertyGroup>, который переопределяет свойство<OutputPath>на:$(SolutionDir)bin\$(Platform)\$(Configuration)Затем я добавил следующий импорт во все соответствующие проекты, прежде чем импортировать цели сборки:
<Import Project="$(SolutionPath).targets" />Таким образом, каждое решение имеет сопутствующий файл
.targets, определяющий такие вещи, которые я хочу использовать в рамках всего решения.Это сработало хорошо, но затем я столкнулся со следующей проблемой: вышеупомянутые
$(Platform)и$(Configuration)макросы ссылаются на свойствапроекта , а не решение-широкое. Что произойдет, если в конфигурации Debug/Any CPU моего решения все еще будет построен какой-то очень специфический проект в конфигурации выпуска? Насколько мне известно, после тщательного изучения документации, никакие такие макросы не экспортируются, которые имеют детализацию в масштабе всего решения.Я нашел расширение Visual Studio ceztko , которое заставило Visual Studio экспортировать именно те макросы, которые я искал, но после некоторых экспериментов и возни я обнаружил, что это расширение установило их слишком поздно-только после построения решения. Это вызвало проблемы с функцией инкрементной сборки Visual Studio-он продолжал думать, что проекты устарели, потому что он искал в неправильном месте - он не знал переменных, но MSBuild.ехе был.
Я начал возиться с
IVsUpdateSolutionEventsинтерфейс , трассировка при вызове каждого метода - и затем обнаружил, чтоIVsUpdateSolutionEvents.OnActiveProjectCfgChangeвызывается дважды при открытии решения 1-го проекта в новом визуальном элементе Studio, или при изменении конфигурации решения с Debug на Release. Дальнейшие манипуляции показали, что если я настроил проект на компиляцию в релизе в обеих конфигурациях решения, этот метод теперь вызывался один раз вместо двух при изменении конфигураций решения.Я разветвил репозиторий расширения и исправил проблему, переместив логику настройки макросов в вышеупомянутый метод. Вы можете найти его здесь.
Отказ от ответственности: это может не взаимодействовать так хорошо с пакетной сборкой операций из IDE, и требует, чтобы вы экспортировали эти свойства самостоятельно при сборке из MSBuild.командная строка exe.
Удачи вам в ваших путешествиях.
Comments