Подтвердить что ты не робот

MSBuild - Как создать файл решения .NET(в задаче XML script) из предварительно написанных команд командной строки

Я изучаю MSBuild, так как мне нужно автоматизировать свои сборки в магазине разработки. Я смог легко написать .BAT файл, который вызывает командную строку VS и передает мои команды MSBuild. Это работает довольно хорошо и довольно красиво.

Вот содержимое моего файла сборки .BAT:

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\amd64\vcvars64.bat"
cd  C:\Sandbox\Solution
msbuild MyTopSecretApplication.sln /p:OutputPath=c:\TESTMSBUILDOUTPUT /p:Configuration=Release,Platform=x86
pause

^ Это хорошо работает, но теперь мне нужно использовать задачу MSBuild для TeamCity CI. Я попытался написать несколько сценариев MSBuild, но я не могу заставить их работать одинаково. Что эквивалентная сборка script для команды, которую я использую в моем .BAT файле? Любые идеи?

Я попытался использовать что-то вроде этого, но не успел (я знаю, что это неправильно):

<?xml version="1.0"?>
<project name="Hello Build World" default="run" basedir=".">

<target name="build">
    <mkdir dir="mybin" />
    <echo>Made mybin directory!</echo>

  <csc target="exe" output="c:\TESTMSBUILDOUTPUT">
    <sources>
      <include name="MyTopSecretApplication.sln"/>
    </sources>
  </csc>
  <echo>MyTopSecretApplication.exe was built!</echo>
</target>

<target name="clean">
    <delete dir="mybin" failonerror="false"/>
</target>

<target name="run" depends="build">
  <exec program="mybin\MyTopSecretApplication.exe"/>
</target>

Мне просто нужна сборка MSBuild XML script, которая компилирует одно решение для режима Release в указанный выходной каталог. Любая помощь?

4b9b3361

Ответ 1

Используйте задачу MSBuild для создания решения, передающего необходимые вам свойства.

<?xml version="1.0" encoding="utf-8"?>
<Project
    xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
    ToolsVersion="4.0"
    DefaultTargets="Build">

    <PropertyGroup>
        <OutputDir>c:\TESTMSBUILDOUTPUT</OutputDir>
    </PropertyGroup>

    <ItemGroup>
        <ProjectToBuild Include="MySecretApplication.sln">
            <Properties>OutputPath=$(OutputDir);Configuration=Release</Properties>
        </ProjectToBuild>
    </ItemGroup>

    <Target Name="Build">
        <MSBuild Projects="@(ProjectToBuild)"/>
    </Target>

</Project>

Ответ 2

Вот мой последний MSBuild script:

<?xml version="1.0" encoding="utf-8"?>

<PropertyGroup>
    <OutputDir>C:\TESTMSBUILDOUTPUT</OutputDir>
</PropertyGroup>

<ItemGroup>
    <ProjectToBuild Include="MyTopSecretApplication.sln" >
        <Properties>OutputPath=$(OutputDir);Configuration=MSBuildRelease;Platform=x86</Properties>
    </ProjectToBuild>
</ItemGroup>

<Target Name="Build">
    <MSBuild Projects="@(ProjectToBuild)"/>
</Target>

Как вы можете видеть, основным отличием от ответа Брайана Уокера является настройка "Конфигурация". Здесь он установлен на "MSBuildRelease" вместо "Release", который я настроил из .NET IDE. Следуйте инструкциям Брайана (щелкните правой кнопкой мыши по решению node и выберите Configuration Manager в Visual Studio, добавьте конфигурацию "NEW" и удалите/снимите флажки проектов, которые вы хотите исключить.)

С тех пор я загрузил это на свой сервер TEAMCITY и с вашей помощью автоматизировал мой процесс сборки .NET. Большое спасибо Брайан Уокер (один техасский)... Я куплю тебе пиво! CHEERS!!

Ответ 3

Я знаю, что это не прямой ответ на ваш вопрос, но почему бы просто не использовать встроенный бегун сборки Visual Studio и не собрать скомпилированный вывод из соответствующего пути /obj и сохранить его в качестве артефакта сборки? Если вы фактически ничего не делаете за пределами простой компиляции против указанной конфигурации сборки, тогда добавление большого количества добавленной стоимости благодаря наличию выделенного файла сборки и использованию артефактов сборки может сделать жизнь намного проще (использовать их в других сборках, загружать их легко и т.д.).

Попробуйте описанную здесь конфигурацию, если это не имеет смысла: http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_25.html