У меня есть программное обеспечение, которое до сих пор выполнялось с помощью пользовательского интерфейса или командных скриптов. Моя работа заключалась в удалении всего пользовательского интерфейса и его автоматическом запуске с использованием сборки tfs. Использование TFS 2012 VS 2012autodeployment tfs build
Мои вопросы: 1. Как запустить программное обеспечение, которое оно строит. Я пытался использовать аргументы MSBuild с использованием
/p:DeployOnBuild=True /p:DeployTarget=Package /p:CreatePackageOnPublish=True
/p:OutputPath=bin /p:VisualStudioVersion=11.0 /p:MSDeployPublishMethod=InProc
/p:MsDeployServiceUrl=localhost
/p:[email protected]"\\filer01\FDrive\public\documents\new\\"
Ошибок нет, но мое тестовое решение ничего не производит. Для тестирования он должен создать файл. Тот же код отлично работает в рамках пользовательской активности кода, поэтому это означает, что программное обеспечение не запускается. Я хочу запустить программное обеспечение из источника управления.
Вопрос 2. Каков наилучший способ передать аргументы из определения построения TFS для программного обеспечения, которое я создаю и запускаю? Могу ли я позвонить им с помощью программного обеспечения?
Edit: Решение: пользовательские активность:
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = String.Format("{0}\\TestingForm.exe", binaries)
}
};
process.Start();
process.WaitForExit();
Я хочу использовать их в качестве конфигурации. Я хочу иметь около 70 определений сборки, используя один шаблон с тем же источником, но с разными конфигурациями. Я думал о создании xml или ini-файла на лету и использовать его для настройки, но также думал о преобразовании программного обеспечения в один большой пользовательский вид, чтобы также сэкономить место на диске. Каждый ход сборки = 60 МБ * 70 * 2 раза в день в конечном итоге занимает много лишнего места. – Claudius
Не знаете, в чем ваш вопрос. Нужна дополнительная информация. – chief7
Спасибо, что помогли, я как-то понял это с помощью другого подхода. – Claudius