Установка свойства 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 файл (<Project> XML-называется это MySolution.sln.targets). В нем я определил <PropertyGroup> это перебило <OutputPath> имущество:

$(SolutionDir)bin$(Platform)$(Configuration)

затем я добавил следующий импорт во все соответствующие проекты перед импортом целей сборки:

<Import Project="$(SolutionPath).targets" />

таким образом, каждое решение имеет сопроводительный .targets файл, определяющий такие вещи, которые я хочу быть в масштабе решения.

это сработало хорошо, но затем я столкнулся со следующей проблемой: вышеупомянутый $(Platform) и $(Configuration) макросы относятся к проекта свойства, а не общесистемные. Что произойдет, если отладка моего решения/любая Конфигурация процессора все еще построила какой-то очень конкретный проект в своей конфигурации выпуска? Насколько мне известно, после тщательного изучения документации такие макросы не экспортируются, которые имеют гранулярность решения.

нашел расширение Visual Studio от ceztko что заставило Visual Studio экспортировать именно те макросы, которые Я искал - но после некоторых экспериментов и возни я обнаружил, что это расширение установило их слишком поздно - только после создания решения. Это вызвало проблемы с функцией инкрементной сборки Visual Studio-он продолжал думать, что проекты устарели, потому что он искал в неправильном месте - он не знал переменных, но MSBuild.exe был.

я начал возиться с IVsUpdateSolutionEvents интерфейс, трассировка при вызове каждого метода-и затем обнаружил, что IVsUpdateSolutionEvents.OnActiveProjectCfgChange вызывается дважды при открытии решения 1-проекта в новой Visual Studio или при изменении конфигурации решения с Debug на Release. Дальнейшие манипуляции показали, что если я установил проект для компиляции в Release в обеих конфигурациях решения, этот метод теперь вызывается один раз вместо двух при изменении конфигураций решения.

Я разветвил репозиторий расширения и исправил проблему, переместив логику настройки макросов в вышеупомянутый метод. Вы можете найти его здесь.

отказ от ответственности: это может не так хорошо взаимодействовать с операциями пакетной сборки из IDE и требует, чтобы вы экспортировали эти свойства самостоятельно при создании из MSBuild.командная строка exe.

удачи в ваших путешествиях.