Este artigo foi traduzido por máquina.

ALM Rangers

Estendendo o Visual Studio Team Explorer 2012

Mike Fourie

Baixar o código de exemplo

Neste artigo eu falarei sobre novos pontos de extensibilidade fornecidos no Microsoft Visual Studio Team Explorer 2012. Eu vou construir uma amostra de trabalho para destacar a arquitetura de Team Explorer 2012 enquanto espero proporcionando-lhe alguma inspiração para criar extensões que serão benéficos para você, sua equipe e talvez até mesmo a Comunidade em geral.

Visual Studio 2005, Team Explorer tem desde a interface primária para interagir com os vários recursos centrados em equipe fornecidos no Visual Studio , como itens de trabalho, documentos do SharePoint, relatórios, compilações e controle de fonte.

As versões subseqüentes do Visual Studio 2008 e Visual Studio 2010 desde pequenas atualizações para Team Explorer, mas o paradigma de navegação de exibição em árvore básico manteve-se no lugar — até Visual Studio 2012 chegou, que é. Visual Studio 2012 introduziu um Team Explorer completamente redesenhado e UX. Foi-se a exibição de árvore, que foi substituído por um conjunto de páginas que fornece acesso aos mesmos recursos que nós nos tornamos acostumados a, bem como algumas novas funcionalidades como o meu trabalho.

Observe também que, com o Visual Studio 2012, você pode trabalhar agora inteiramente em código gerenciado sem quaisquer preocupações sobre como lidar com internos.

Visão geral de 2012 Team Explorer

Team Explorer 2012 é composto por várias páginas, cada uma delas pode ser dividida em seções e host itens de navegação e Links de navegação. A página padrão é chamada de Home e fornece fácil acesso a outras páginas fornecidas no Team Explorer, ou seja, meu trabalho, alterações pendentes, itens de trabalho, compilações, Web Access, os membros da equipe e configurações.

Figura 1 mostra a página inicial e vários itens de navegação e Links fornecidos.

Figura 1: A Home Page Team Explorer 2012

Figura 2 mostra o uso de seções, que você pode adicionar páginas.

Figura 2 seções no Team Explorer constrói a página

Se esta é a primeira vez que você já viu o Team Explorer 2012, você sem dúvida vai concordar que o design é completamente diferente da experiência baseada no modo de exibição de árvore anterior fornecida no Visual Studio 2005, 2008 e 2010.

Dada a simplicidade e eficiência das implementações anteriores de exibição de árvore, você pode se perguntar por que há tal uma reformulação radical. Depois de trabalhar no novo baseado em página Team Explorer você pode sentir — e acho que com alguma justificação — que a navegação não é tão eficiente quanto o modo de exibição de árvore simples que substituiu. Certamente leva algum para se acostumar, mas espero que no final deste artigo você vai entender que a atual perda na eficiência de navegação é compensada pelos recursos de extensibilidade poderoso que fornece o novo design da página e a redução nas caixas de diálogo modais que são prevalentes em versões anteriores. Observe que digo "atual" perda na eficiência da navegação, como espero que o projeto ser mexido durante todo o curso das atualizações trimestrais que Microsoft está fornecendo agora para Visual Studio. Na verdade, Visual Studio 2012 Update 2 tem uma útil novo ligar página que exibe cada Team Foundation Server (TFS), coleção de projeto de equipe e projeto de equipe já previamente conectado, facilitando a navegação conexões do TFS.

Recursos de extensibilidade de Team Explorer existentes

Além deste artigo, você deve estar ciente de alguns outros recursos que podem ajudá-lo a encontrar o seu caminho em torno de estender Team Explorer. MSDN tem documentação de API-nível cobrindo o namespace Microsoft.TeamFoundation.Controls que hospeda todos os objetos que eu vou estender.

O Visual Studio Developer Center tem uma amostra, "extensão Team Explorer em Visual Studio 2012" (bit.ly/Zp1OFf), que foi publicado pela equipe que desenvolveu o Team Explorer 2012. A extensão de amostra MyHistory fornecida com este artigo baseia-se nesse exemplo e eu recomendo que você lê-lo primeiro.

Team Explorer Arquitetura

Antes de iniciar a criação de extensões para o Team Explorer será benéfico entender um pouco sobre como o Team Explorer é arquitetado.

As extensões que você cria precisam implementar a interface para o ponto de extensão que você está alvejando. Essas interfaces são implementadas no namespace Microsoft.TeamFoundation.Controls e são definidas como segue:

• Página: ITeamExplorerPage (bit.ly/11FvPyE)
• Seção: ITeamExplorerSection (bit.ly/Y6Y22X)
• Item de navegação: ITeamExplorerNavigationItem (bit.ly/11Hh2Cm)
• Link de navegação: ITeamExplorerNavigationLink (bit.ly/17XFHEp)

Extensões que você criar são descobertos usando o Managed Extensibility Framework (MEF). Para auxiliar a descoberta, você deve decorar sua classe com o atributo apropriado conforme definido aqui:

• Página: [TeamExplorerPage("guid")] (bit.ly/17kBzQD)
• Seção: [TeamExplorerSection ("guid", "parentPageGuid", prioridade)] (bit.ly/12nMxCC)
• Item de navegação: [TeamExplorerNavigationItem ("guid", prioridade)] (bit.ly/Y6YQ7S)
• Link de navegação: [TeamExplorerNavigationLink ("guid", "parentNavigationItemGuid", prioridade)] (bit.ly/12KFghj)

Para a sua extensão a ser descoberto, o assembly deve ser em um dos locais "bem conhecido" extensão para Visual Studio. Esses locais são definidos no arquivo "Mestre PkgDef", localizado em <VsInstallRootFolder> \Common7\IDE\devenv.pkgdef.

O mecanismo de empacotamento recomendados para suas extensões é usar Visual Studio . Esse mecanismo vai cuidar de todo o encanamento de implantação para você. Se você gostaria de ler mais sobre descoberta, veja o post do Blog Visual Studio , "How VSIX extensões são descobertas e carregados no VS 2010" (bit.ly/xTJrSv).

Para ilustrar o tempo de vida de extensão, navegação, gerenciamento de contexto e outros recursos disponíveis para sua extensão, vejamos o exemplo de minha história com este artigo.

Primeiros passos com o aplicativo de exemplo

Você pode baixar o completo exemplo de funcionamento para este artigo, mas creio que é importante destacar alguns pontos-chave para ajudá-lo a começar com êxito com a construção de sua própria extensão.

Para criar uma extensão, você vai precisar de Visual Studio 2012 — e, em particular, o SDK Visual Studio 2012 — para criar o projeto VSIX. Quando você cria um projeto VSIX, Visual Studio leva você direto para o arquivo de .vsixmanifest mostrado na Figura 3. Adicionei o meu próprio arquivo de licença para o projeto e completou alguns campos, como mostrado.

Figura 3 detalhes do arquivo .vsixmanifest

Você pode optar por adicionar sua extensão em um assembly separado ou hospedar todo o código dentro do projeto VSIX. Se você optar por hospedar todo o seu código de VSIX, é importante ajustar manualmente o arquivo. csproj assim a extensão estiver incluído no pacote VSIX. Por padrão, o projeto VSIX cria apenas o pacote VSIX. Quando você implanta a sua extensão, ele irá mostrar como instalado; no entanto, o assembly não vai ser implantado, assim ele não vai ser descoberto. Para incluir o conjunto, você precisa abrir o arquivo. csproj em um editor de texto e definir as configurações de projeto, como mostrado no código a seguir (esta mudança não pode ser feita através da interface do usuário):

<IncludeAssemblyInVSIXContainer>true</IncludeAssemblyInVSIXContainer>
<CopyBuildOutputToOutputDirectory>true</CopyBuildOutputToOutputDirectory>

Dentro do arquivo de manifesto você precisa configurar ativos para que a extensão pode implantar sua extensão apropriadamente. Na guia recursos, adicione um novo Microsoft.VisualStudio.VsPackage para o projeto. Isso informa VSIX que você estiver criando um pacote de Visual Studio . Além disso, adicione um activo do tipo Microsoft.VisualStudio.MefComponent, que fornece o nome do assembly no pacote VSIX extensão.

Um projeto VSIX não possui referências por padrão, então você precisa adicionar todos aqueles que são necessários. No mínimo você precisa as seguintes referências:

• Microsoft.TeamFoundation.Client
• Microsoft.TeamFoundation.Controls
• Microsoft
• Microsoft.TeamFoundation.VersionControl.Controls
• Microsoft
• Microsoft.VisualStudio.Shell.Interop.10.0
• 8.0
• Microsoft.VisualStudio.Shell.Interop.9.0
• Microsoft.VisualStudio.TeamFoundation.VersionControl
• VisualStudio
• Microsoft.VisualStudio.Shell.11.0
• Microsoft.VisualStudio.Shell.Immutable.10.0
• PresentationCore
• PresentationFramework
• Sistema
• System.ComponentModel.Composition
• System. Core
• System.Drawing
• System.Windows.Forms
• System. XAML
• System.Xml

Embora você possa criar sua extensão em código gerenciado, você precisará provavelmente ainda integrar com Visual Studio via COM, então você provavelmente precisa também referências COM EnvDTE e EnvDTE80.

Depois de feito tudo isso, você está pronto para começar a criar conteúdo para estender Team Explorer.

Depurando

Se esta é sua primeira aventura usando VSIX projetos, você pode estar se perguntando como depurá-los. No Visual Studio 2012 novo projeto agora é criado com as informações de depuração necessárias, então você pode simplesmente bater F5 e uma nova instância de "experimental" do Visual Studio (bit.ly/12KRCGq) vai começar com sua extensão carregado.

Você pode definir pontos de interrupção em seu código e depurar como qualquer outro aplicativo, embora talvez um pouco mais lento do que você pode ser usado para aplicações mais simples. De alguma forma meu projeto conseguiu perder as configurações, então mostrei a eles em Figura 4. Basicamente a ação iniciar é definida para iniciar o programa externo com o valor C:\Program Files (x86) \Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe e a linha de comando argumentos são definidos como /rootsuffix Exp.

Figura 4 VSIX depurar configurações

Noções básicas do meu exemplo de história

Os desenvolvedores freqüentemente precisam multitarefa (que é a palavra extravagante para randomização!) e, por vezes, esquecer o que eles fizeram apenas alguns minutos ou dias atrás. A extensão de minha história pretende ajudar a melhorar a sua experiência de multitarefa, fornecendo uma lista de Shelvesets, Changesets, itens de trabalho e projectos/soluções com as quais você trabalhou recentemente. Mostrado no Figura 5, trata-se de uma nova página, juntamente com várias seções, itens de navegação e Links de navegação.

Figura 5 a minha extensão de história

Neste ponto eu recomendo instalar a extensão para ver como ele se estende Team Explorer, então voltar a este artigo que passar por algumas partes principais do código de extensão.

O código na minha história

A solução é organizada em um conjunto de pastas para facilitar a navegação e a descoberta.

A pasta Base contém um conjunto de classes com base naqueles fornecidos na referida "extensão Team Explorer no exemplo 2012" Visual Studio . As pastas de componentes internos e recursos contêm várias classes auxiliares. Você está mais interessado na pasta seções, que contém a implementação de objetos do qual você precisa derivar. Figura 6 mostra como as classes estão relacionadas.

Figura 6 diagrama de Classes de MyHistory

Para criar um ponto de entrada para a nova página, você precisará adicionar um Link de navegação para uma das seções existentes na página inicial.

Figura 7 mostra o código para o Link de navegação personalizado contido no MyHistory­NavigationLink.cs. Esse código produz o link de minha história mostrado na Figura 5.

Figura 7 o meu Link de navegação do histórico

[TeamExplorerNavigationLink(MyHistoryNavigationLink.LinkId,
   TeamExplorerNavigationItemIds.MyWork, 200)]
public class MyHistoryNavigationLink : TeamExplorerBaseNavigationLink
{
  public const string LinkId = "e49a882b-1677-46a9-93b4-db290943bbcd";
  [ImportingConstructor]
  public MyHistoryNavigationLink([Import(typeof(SVsServiceProvider))]
     IServiceProvider serviceProvider) : base(serviceProvider)
  {
    this.Text = "My History";
    this.IsVisible = true;
    this.IsEnabled = true;
  }
  public override void Execute()
  {
    try
    {
      ITeamExplorer teamExplorer = GetService<ITeamExplorer>();
      if (teamExplorer != null)
      {
        teamExplorer.NavigateToPage(new Guid(MyHistoryPage.PageId), 
          null);
      }
    }
    catch (Exception ex)
    {
      this.ShowNotification(ex.Message, NotificationType.Error);
    }
  }

Quando o link for clicado, o método Execute é executado e Team Explorer feita para navegar para sua página personalizada de história minha. Vamos dar uma olhada na primeira linha em Figura 7. O TeamExplorerNavigation­Link classe atributo é usado para associar o link para a seção de MyWork, e a prioridade de 200 significa que link provavelmente aparece por último, supondo que alguém não tenha instalado outra extensão com um número maior (menor prioridade).

Figura 8 mostra o código em MyHistoryPage.cs, que prevê a adição de uma nova página de Team Explorer . Observe o uso do atributo e o ID exclusivo usado.

Figura 8 da página MyHistory

/// <summary>
/// MyHistory Page. We're extending Team Explorer by adding a new page and
/// therefore use the TeamExplorerPage attribute and pass in our unique ID
/// </summary>
[TeamExplorerPage(MyHistoryPage.PageId)]
public class MyHistoryPage : TeamExplorerBasePage
{
  // All Pages must have a unique ID; use the Tools | Create   
  // GUID menu in Visual Studio to create your own GUID
  public const string PageId = "BAC5373E-1BE5-4A10-97F5-AC278CA77EDF";
  public MyHistoryPage()
  {
    // Set the page title
    this.Title = "My History";
  }
}

Você tem uma entrada aponte para sua nova página, e você pode começar a sua nova página; Agora você precisa obter o conteúdo para a página. Vou cobrir a seção conjuntos de alterações em detalhes e deixar para você dar uma olhada em outras seções implementadas em seu próprio tempo. Todos seguem o mesmo padrão básico.

O código que acompanha o download é a classe ChangesetsSection.cs, que é muito longa para listar neste artigo. Nesta classe você pode registrar uma nova ITeamExplorerSection com o MyHistory Page, usando o atributo de classe TeamExplorerSection. Observe que o valor de 20, o atributo de classe é a prioridade da seção. Quanto menor a prioridade, mais acima na página da seção é renderizada. A classe declara uma ObservableCollection de conjuntos de alterações a que está vinculado a sua interface do usuário. No construtor da classe que você definir configurações adicionais do visuais e comportamentais. É importante ligar a classe para o conteúdo processado, que é uma nova instância do seu controle de usuário, ChangesetsSectionView.xaml.

Observe que no método Initialize você verificar contexto assim que você pode recarregá-lo da memória, em vez de consultar novamente a ele. O método SaveContext salva informações de contexto necessário para uso futuro, e o método ContextChanged pode ser usado para atualizar os dados se o usuário altera projetos ou coleções. Em todos os casos, se você precisa consultar novamente, você fazer isso de forma assíncrona para evitar bloquear o thread da interface do usuário. O método ViewChangesetDetails é chamado de seu controle de usuário. Esse método interage com Team Explorer e fornece-o com as informações necessárias processar os detalhes do conjunto de alterações na página correta.

A peça final no quebra-cabeça é criar o seu controle de usuário para exibir o conteúdo. A seção Changesets fornece um double -­lista clicável dos últimos 10 check-ins o usuário fez, cada um com uma dica de ferramenta mostrando alguns detalhes pertinentes e um hiperlink para levar o usuário a história completa do conjunto de alterações, como mostrado na Figura 9.

Figura 9 seção Changesets UI

O código para o controle de usuário é bastante básico, e ele realmente apenas lida com os eventos de usuário, o que fazem chamadas através de para o ParentSection para interagir com o Team Explorer. Figura 10 fornece uma visão abreviada sobre algumas de code-behind. Observe o uso da dependência­classe de propriedade (bit.ly/11FJNQW), que ajuda a ligar o controle de usuário para a classe que registou com Team Explorer.

Figura 10 o código de controle de usuário de Changesets

public partial class ChangesetsSectionView
{
  public static readonly DependencyProperty ParentSectionProperty =       
    DependencyProperty.Register("ParentSection",
    typeof(ChangesetsSection), typeof(ChangesetsSectionView));
  public ChangesetsSection ParentSection
  {
    get { return (ChangesetsSection)GetValue(ParentSectionProperty); }
    set {SetValue(ParentSectionProperty, value);}
  }
  private void HistoryLink_Click(object sender, RoutedEventArgs e)
  {
    this.ParentSection.ViewHistory();
  }
  private void ChangesetList_MouseDoubleClick(
    object sender, MouseButtonEventArgs e)
  {
    if (e.ChangedButton == MouseButton.Left &&
       changesetList.SelectedItems.Count == 1)
    {
      this.ViewChangesetDetails();
    }
  }
}

Consciência, uma visão e um ponto de partida

Há muito mais código para olhar através da amostra, o que permite, em conjunto com o que abordei neste artigo, espero que você com:

• Uma tomada de consciência da extensibilidade Team Explorer 2012 fornece.
• Uma visão sobre a vasta API Visual Studio fornece com o qual você pode interagir (leia o artigo da MSDN Magazine, "Versão controle em the TFS modelo de objeto cliente" msdn.microsoft.com/magazine/jj883959, se você estiver interessado em mais de leitura do nível de API de matéria).
• Um ponto de partida e a confiança para criar sua primeira extensão.

Obrigado por tomar o tempo para ler isto e por favor, veja mais de ALM Rangers (aka.ms/vsarunderstand).

Mike Fourie é um consultor independente com mais de 13 anos de experiência de desenvolvimento de software especializada em automação de compilação e implantação. Ele é um ALM da Microsoft MVP e distinto ALM Ranger. Ele pode ser contatado através de seu blog em freetodev.com. Você também pode segui-lo no Twitter em twitter.com/mikefourie.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Chad Boles (Microsoft), Jeff Bramwell (Farm de serviços de crédito da América), Willy-Peter Schaub (Microsoft) e Hamid Sousa (consultor)

Jeff Bramwell é diretor de arquitetura corporativa na fazenda serviços de crédito da América. Ele tem mais de 20 anos de experiência de desenvolvimento de software e sempre se esforça para seguir o mantra de início simples e sua maneira de trabalhar a partir daí. Seu blog está em devmatter.blogspot.com. Você pode segui-lo no Twitter em twitter.com/jbramwell.

Willy-Peter Schaub é gerente de programa sênior com o Visual Studio ALM Rangers o Canadá Microsoft Development Center. Desde meados da década de 1980, tem se empenhado em buscar a simplicidade e a facilidade de manutenção na engenharia de software. Leia seu blog em blogs.msdn.com/b/willy-peter_schaub e siga-o no Twitter em twitter.com/wpschaub.

Hamid Shahid é um Microsoft Visual Studio ALM Ranger e um consultor de software. Ele tem mais de 13 anos de experiência com tecnologias da Microsoft, com um interesse especial em MSBuild e Team Foundation Server.