Передача объекта рабочей области TFS в код C# из Powershell?

Question

В настоящее время я работаю над созданием сценариев Powershell, чтобы создать более простой в обслуживании процесс сборки в TFS 2013.

Часть этого процесса требует, чтобы ряд SQL сравнивался с сценариями обновления.

Что я пытаюсь сделать, это использовать одну из наших старых пользовательских операций сборки (из TF 2010), которые выглядели достаточно легко для преобразования в файл кода C# для использования в Powershell. Это необходимо как шаг тестирования сборки/предварительной установки.

Я хотел бы сделать обновления доступными для модульных тестов, некоторые из которых основаны на интеграционных тестах на базе баз данных, которые ранее не обновлялись до следующей сборки.

проблема заключается в том, что для моего сценария C# требуется рабочее пространство TFS, и я не уверен, как и где это необходимо выполнить. В операции «Построение» использовалась модель кода TFS, которая имела свойства InArguments как свойства и обрабатывала все это.

Я изменил это, как показано ниже, чтобы работать как команда, как и в урезанном C примере # ниже:

using System.IO; 
using System.Text.RegularExpressions; 
using Microsoft.TeamFoundation.Build.Client; 
using Microsoft.TeamFoundation.Build.Workflow.Activities; 
using Microsoft.TeamFoundation.VersionControl.Client; 
using System.Activities; 
using System; 
using System.Collections.Generic; 
using System.Linq; 

public class UpdateAndCheckinNewScripts 
{ 
    Workspace workspace {get; set;} 

    public UpdateAndCheckinNewScripts(Workspace workspace) 
    { 
     this.workspace = workspace; 
    } 

    public void Execute(string versionToUpdate, string sourcesDirectory, string binariesDirectory) 
    { 
      //... do some stuff to scripts - ommitted... 

      //Copy over previous script 
      File.Copy(projectCreatefilePath, projectFinalPath, true); 

      //Checkin Project Create Script 
      workspace.CheckIn(workspace.GetPendingChanges(projectFinalPath), "Build Agent", "My checkin", null, null, new PolicyOverrideInfo("Auto checkin", null),CheckinOptions.SuppressEvent); 
    } 

    private static void CheckinScript(string upgradeHolder, 
      string filePath, string sourcesDirectory, string upgradeReplacementText, Workspace workspace) 
     { 
      string file = sourcesDirectory + @"\\yyy\xxx\Upgrade.csproj"; 

      //Checkout the project file <-- How do i create workspace to pass into object? 
      workspace.PendEdit(file); 

      workspace.PendAdd(filePath); 
      // ... other code 
    } 
} 

Я хочу, чтобы избежать прямого переписывания этого шага, если это возможно, но открыт для идей. Я хотел отойти от настройки Xaml определения сборки по умолчанию в TFS 2013. Я беру несколько советов по этой ссылке в качестве отправной точки для использования сборок .NET в Powershell:

http://ruudvanderlinden.com/2010/10/19/running-inline-c-with-custom-assemblies-in-powershell-2-0/

Я хочу знать, как я получаю объект рабочей области TFS для текущей сборки в этом и как создать экземпляр.

я думаю, что сценарий PS может выглядеть примерно так:

# assume I've run SQL comparison, create upgrade script and backups as needed.... 

# assuming all assembly and custom references required will have been added, here... 

$tfWorkspace = ??? #not sure here 
Add-Type -TypeDefinition $Source #assume $Source is the above c# source. 
$scriptingobject = New-Object UpdateAndCheckinNewScripts($tfWorkspace) 
$scriptingobject.Execute($buildVersion,$sourceLocalFolder,$binDirectory) 

#continue with custom script... 

я думаю, что у меня есть 2 варианта:

1. экземпляр объекта рабочей области в пределах C# код как-то.

2. экземпляр объекта в PowerShell и переход к создаваемому объекту .

Если кто-либо может помочь со мной с любым вариантом или с любой другой идеей, я был бы очень признателен.

Answer 1

В итоге я использовал сценарии powershell, как упоминалось на сайте разработки Microsoft: https://msdn.microsoft.com/en-us/library/dn376353.aspx.

Я объединил это с инструментами TFS Power и использовал командлеты Add-TfsPendingChange и New-TfsChangeset, но я также использовал объекты TFS API .Net, где требовался больше контроля.

Я покончил с использованием наших оригинальных пользовательских операций сборки, но мы настроили определение сборки, чтобы позволить больше сценариев Powershell вызываться на более высоких этапах стандартного шаблона TFS 2013.

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