Arquivo da categoria: Visual Studio 2012

ASP.Net – Web Application Projects x Web Site Projects

Publicado em por

No Visual Studio, você pode criar Web Application Projects ou Web Site Projects. É melhor escolher o tipo certo antes de criar um projeto web, porque pode ser demorado, difícil e propenso a erros para depois converter de um tipo para o outro.

Web Application Project

Web Application Project ou Web Site Project? Estas duas opções de criar uma aplicação web costumam gerar diversas dúvidas e problemas. Este artigo aborda todas as vantagens e desvantagens de cada uma para que a melhor escolha seja tomada conforme o seus cenários e necessidades.

Nota
Para um novo desenvolvimento é recomendado que seja escolhido o Web Application Project. Este artigo explica que Web Site Projects possuem algumas vantagens, mas muitos desenvolvedores que escolhem Web Site Projects, eventualmente descobrem que as desvantagens superam as vantagens percebidas. Além disso, à medida que novos recursos ASP.Net são desenvolvidos eles não vão estar sempre disponíveis para Web Site Projects. Por exemplo, a versão do Visual Studio 2013 possui novas ferramentas para a criação de projetos web e esta nova ferramenta vai trabalhar apenas com Web Application Projects. Para mais informações consulte Creating an ASP.NET Web Project in Visual Studio 2013.

Este artigo contém as seguintes seções:

Cenários

Cenários em que os Web Application Projects são uma escolha indicada incluem as condições:

    • Você quer ser capaz de usar o recurso Edit and Continue característico do depurador do Visual Studio.
    • Você deseja executar testes de unidade em código que está nos arquivos de classe que estão associados a páginas ASP.Net.
    • Você quer se referir às classes que estão associadas com as páginas e user controls a partir de classes standalone.
    • Você quer estabelecer dependências do projeto entre vários projetos web.
    • Você quer que o compilador crie um assembly único para todo o site.
    • Você quer controle sobre o nome do assembly e número de versão que é gerado para o site.
    • Você quer usar MSBuild ou Team Build para compilar o projeto. Por exemplo, você pode querer adicionar passos prebuild e postbuild.
    • Você quer evitar colocar o código-fonte em um servidor de produção.

Cenários em que Web Site Projects são uma escolha indicada incluem as condições:

    • Você deseja incluir o código C # e Visual Basic em um único projeto web. (Por padrão, uma aplicação web é compilada com base em configurações de idioma no arquivo de projeto. Exceções podem ser feitas, mas é relativamente difícil.)
    • Você deseja abrir o site em produção no Visual Studio e atualizá-lo em tempo real, utilizando FTP.
    • Você não quer ter que compilar explicitamente o projeto.
    • Se você pré-compilar o site, você quer que o compilador crie vários assemblies para o site, que pode incluir um assembly por página ou controle de usuário, ou um ou mais assemblies por pasta.
    • Você quer ser capaz de atualizar arquivos individuais na produção copiando apenas novas versões para o servidor de produção, ou editando os arquivos diretamente no servidor de produção.
    • Se você pré-compilar o site, você quer ser capaz de atualizar páginas da Web ASP.NET. Individuais (aspx) sem ter que recompilar todo o site.
    • Você gosta de manter seu código fonte no servidor de produção, pois pode servir como uma cópia de segurança adicional.

Resumo das Diferenças

A tabela a seguir resume as principais diferenças.

Área Web Application Projects Web Site Projects
Estrutura do arquivo de projeto
  • Um arquivo de projeto Visual Studio (. Csproj ou. Vbproj) armazena informações sobre o projeto, tais como a lista de arquivos que estão incluídos no projeto, e todas as referências de projeto a projeto.
  • Não há nenhum arquivo de projeto (. Csproj ou. Vbproj). Todos os arquivos em uma estrutura de pastas são automaticamente incluídas no site.
Compilação
  • O código fonte é compilado no computador que é usado para o desenvolvimento ou source control.
  • Por padrão, a compilação de arquivos de código (excluindo. Arquivos.ascx aspx e.) Produz um único assembly.
  • O código-fonte é normalmente compilado dinamicamente (automaticamente) pelo ASP.NET no servidor pela primeira vez quando um request é recebido depois que o site foi instalado ou atualizado. É possível pré-compilar o site (compilar com antecedência em um computador de desenvolvimento ou no servidor).
  • Por padrão, a compilação produz múltiplos assemblies.
Namespaces
  • Namespaces explícitos são adicionados a páginas, controles e classes por padrão.
  • Namespaces explícitos não são adicionados a páginas, controles e classes por padrão, mas você pode adicioná-los manualmente.
Desenvolvimento
  • Você copia o assembly para o servidor. O assembly é produzido através da compilação do aplicativo.
  • O Visual Studio fornece ferramentas que se integram com Web Deploy (ferramenta de deploy para IIS) para automatizar muitas tarefas de implantação.
  • Você copia os arquivos de origem do aplicativo em um computador que tem o IIS instalado.
  • Se você pré-compilar o site em um computador de desenvolvimento, você pode copiar os assemblies produzidas por compilação para o servidor IIS.
  • O Visual Studio fornece ferramentas que se integram com Web Deploy (ferramenta de deploy para IIS) para automatizar muitas tarefas de implantação.

Estrutura de Arquivos

Web Application Projects usam arquivos de projeto do Visual Studio (. Csproj ou. Vbproj) para acompanhar as informações sobre o projeto. Isso torna possível especificar quais arquivos são incluídos ou excluídos do projeto e, portanto, os arquivos que são criados durante uma compilação.

Para Web Site Projects todos os arquivos em uma estrutura de pastas são automaticamente considerados para serem incluídos no site. Se você quiser excluir algo da compilação, você deve remover o arquivo da pasta do projeto do web site ou alterar a sua extensão de nome de arquivo para uma extensão que não é compilado e não é enviado ao IIS.

Uma vantagem de usar arquivos de projeto em Web Application Projects é o seguinte:

  • É fácil de remover temporariamente os arquivos do site, mas ainda certificar-se de que você não perdê-los, porque eles permanecem na estrutura da pasta. Por exemplo, se uma página não está pronta para ser implantada, você pode excluí-la temporariamente a partir da compilação sem excluí-la da estrutura da pasta. Você pode implantar o assembly compilado e em seguida incluir o arquivo no projeto novamente. Isto é especialmente importante se você estiver trabalhando com um repositório de source control.

Uma vantagem de usar estrutura de pastas sem arquivos de projeto em Web Site Projects é o seguinte:

  • Você não tem que gerenciar a estrutura do projeto exclusivamente no Visual Studio. Por exemplo, você pode copiar os arquivos para o projeto ou excluí-los do projeto usando o File Explorer.

Compilação

Para Web Application Projects, você normalmente pode compilar o projeto no Visual Studio ou usando um ASP.Net batch compiler em um computador que não é o servidor IIS de produção. Todos os arquivos de classe code-behind e arquivos de classe standalone no projeto são compilados em um único assembly, que é então colocado na pasta Bin do Web Application Projects. (Os arquivos. Aspx e. Ascx são compilados dinamicamente de forma semelhante ao que é feito para Web Site Projects.)

Para Web Site Projects, você não tem que compilar manualmente o projeto. Web Site Projects normalmente são compilados dinamicamente pelo ASP.NET (tanto no computador de desenvolvimento e servidor IIS de produção). Você pode escolher entre o modo de compilação em lotes, que normalmente produz um assembly por pasta e modo de compilação fixa, que normalmente produz um assembly para cada página ou user control.

Vantagens do modelo de compilação de Web Application Projects incluem o seguinte:

    • Você pode usar o MSBuild para criar um custom batch-compilation process.
    • É fácil especificar os atributos do assembly, tais como nome e versão.
    • Compilando com antecedência garante que os usuários não tenham que esperar enquanto o site compila no servidor de produção. (Se o site é muito grande, compilação dinâmica de um Web Site Project pode levar uma quantidade considerável de tempo. Compilação dinâmica ocorre quando um request para um site é recebido após uma atualização, o request que desencadeia a compilação pode ser retardado enquanto os recursos necessários são compilados. Se o atraso for inaceitável, é possível pré-compilar o site. No entanto, em seguida, algumas das vantagens da compilação dinâmica são perdidas.)
    • Você tem o controle completo sobre onde colocar os arquivos de código fonte na estrutura de pasta do projeto e como as classes no projeto referem-se uns aos outros. (Compilação dinâmica requer que o código fonte para todas as classes que são usados em todo o site deve estar na pasta App_Code).

Vantagens do modelo de compilação para Web Site Projects incluem o seguinte:

    • Você pode testar as páginas específicas, independentemente do estado de outras páginas. Isso ocorre porque a rodar uma página individual não requer que todo o site seja compilado com sucesso, apenas a página e quaisquer componentes que depende, como o código na pasta App_Code ou no Global.asax. (Em um Web Application Project, se houver erros de compilação em qualquer lugar do site, você não pode criar os assemblies e, portanto, não pode testar até mesmo as partes do site que compilaram.)
    • É fácil atualizar um site em produção. Você pode atualizar os arquivos de código fonte individuais no servidor de produção sem ter que recompilar explicitamente o site. Você pode atualizar arquivos individuais que estão prontos para a implantação, mesmo que outros arquivos não estejam prontos devido a erros de compilação. Você também pode abrir o site no servidor IIS de produção diretamente no Visual Studio e atualizar o site em tempo real.
    • Pré-compilação de vários assemblies pode ter uma vantagem de desempenho em alguns cenários. Um exemplo típico é um site que tem muitas páginas com um monte de código escrito para eles. A maioria das páginas raramente são solicitadas e só algumas são usadas com freqüência. Se você compilar um site como este em várias assemblies o servidor de produção pode carregar apenas os assemblies que são necessários para as requisições atuais. Se uma página não é solicitada, a sua assembly correspondente não será carregada.
Nota
Não há diferença de desempenho entre um Web Site Project e um Web Application Project. As únicas exceções significativas são as que já foram observadas e por uma questão prática que se aplicam apenas aos sites muito grandes. O primeiro request para o web site pode requerer o site a ser compilado, o que pode resultar em um atraso. Se o site está sendo executado em um servidor IIS que possui pouca memória, possuindo todo o site em um único assembly pode usar mais memória do que seria necessário para vários assemblies.

Deploy

Para realizar o deploy de um Web Application Project, você pode copiar o assembly que é criado ao compilar o projeto para um servidor IIS. Em contraste, para realizar o deploy de um Web Site Project, você pode normalmente copiar os arquivos de origem do projeto para um servidor IIS. (Qualquer uma destas tarefas pode ser feita manualmente ou através de ferramentas de deploy).

Vantagens da estratégia de deploy de Web Application Projects incluem o seguinte:

    • Evitar a exposição de código-fonte no servidor IIS. Em alguns cenários, tais como ambientes de hospedagem compartilhada, você pode estar preocupado com o acesso não autorizado ao código fonte no servidor IIS. (Para um Web Site Project, você pode evitar este risco pré-compilando em um computador de desenvolvimento e realizando o deploy dos assemblies gerados em vez do código fonte. Entretanto, nesse caso, você perde alguns dos benefícios de facilidade de atualizações do site).
    • O deploy muitas vezes envolve outras tarefas além de copiar assemblies ou código para um servidor. Por exemplo, os scripts de banco de dados podem precisar serem executados em produção e connection strings no arquivo Web.config podem precisar serem alteradas para um servidor de produção. O Visual Studio fornece ferramentas que com um clique publicam que trabalham com Web Application Projects para automatizar muitas destas tarefas. Essas ferramentas não estão disponíveis para Web Site Projects.

Vantagens da estratégia de deploy para Web Site Projects incluem o seguinte:

    • Se você fizer uma pequena mudança em um site, você não tem que realizar o deploy de todo o site. Em vez disso, pode copiar apenas o arquivo alterado para o servidor IIS de produção. Você também pode editar arquivos diretamente no servidor de produção. (Como os arquivos de código fonte de um Web Application Projects são compilados em um único arquivo assembly, você deve realizar o deploy de todo o site, mesmo para pequenas mudanças, a menos que a única mudança é para um arquivo aspx ou ascx).

Fonte

ASP.Net MVC – Autenticando usuário através da conta do Facebook

Publicado em por

A utilização de contas de redes sociais para autenticação em outras aplicações já é uma realidade, aprenda como autenticar um usuário utilizando a conta do Facebook em sua aplicação ASP.Net MVC e faça parte desta nova tendência.

ASP.Net MVC + Facebook

O ASP.Net MVC em conjunto com o Visual Studio proporciona uma enorme facilidade em executar esta integração, um projeto no template Internet Application por exemplo já vem praticamente pronto para realizar essa integração com as seguintes contas:

  • Facebook
  • Twitter
  • Microsoft
  • Google

Sua aplicação ASP.Net MVC pode trabalhar com estes quatro modelos simultaneamente sem problema algum, o esquema de membership do ASP.Net proporciona o armazenamento e identificação de cada tipo de login e sua rede social de origem.

Neste artigo gravei um vídeo seguindo passo a passo como integrar uma aplicação ASP.Net MVC com o Facebook, porém este processo é muito similar a integração com as demais redes sociais disponíveis.

Neste vídeo não foi necessário utilizar nenhum plugin externo, porém faço menção ao Facebook SDK for .NET que é um SDK para trabalhar com recursos avançados de integração com o Facebook, como por exemplo postar informações na timeline e interagir com a lista de amigos.

A partir do momento em que o usuário está autenticado numa aplicação ASP.Net MVC utilizando a conta do Facebook o Facebook SDK complementa as demais funcionalidades possíveis para uma interatividade completa.

Obtenha o Facebook SDK for .NET no site:
http://facebooksdk.net/

Ou instale diretamente via NuGet

PM> Install-Package Facebook

Em um próximo vídeo exibirei como utilizar esse SDK e realizar integrações no Facebook além do login.

Espero que aproveite o vídeo e deixe seu feedback ou dúvidas aqui nos comentários.

Palestra sobre ASP.Net SignalR + Demos + Vídeo

Publicado em por

Palestra sobre ASP.Net SignalR ministrada no Visual Studio Summit 2013.

ASP.Net SignalR

Desde que comecei a estudar ASP.Net SignalR me interessei muito e se tornou um dos meus assuntos favoritos, acompanhe aqui como foi minha palestra:

Vídeo da Palestra

Eu ainda não sou o bom palestrante que desejo ser, mas um dia chego lá 🙂

Slides

Demos (compatíveis com VS 2012)

*Jogo da velha original foi baixado aqui. Fiz melhorias, correções e complementos para demonstração.

Quer conhecer mais sobre ASP.Net SignalR? Leia o meu artigo aqui.

O Visual Studio Summit é um dos maiores eventos sobre desenvolvimento na plataforma Microsoft, assista todas palestras da edição 2013 aqui.

Deixe seu feedback logo abaixo 🙂
Abraços!

Como foi o Visual Studio Summit 2013

Publicado em por

Visual Studio Summit 2013 – Minhas impressões

No dia 25 de Março ocorreu a segunda edição do Visual Studio Summit realizado em São Paulo na sede da Microsoft. O Visual Studio Summit é um evento feito por desenvolvedores de software, pessoas de todas as partes do Brasil estavam presentes para se atualizar, aprender e conhecer as últimas novidades da plataforma de desenvolvimento Visual Studio.

Estive presente na primeira edição em 2012 como palestrante e nesta edição de 2013 além de palestrar fiz parte da organização/coordenação do evento. Foi uma experiência fantástica poder ajudar a realizar um evento deste porte, é muito mais trabalho que eu imaginava organizar um evento e estou muito satisfeito, pois deu tudo certo.

Alguns números sobre o evento

  • Palestrantes: 25
  • Staff apoio operação: 18
  • Staff Infra estrutura: 8
  • Palestras: 61 palestras
  • Total de horas de conteúdo: 31 horas 
  • Salas: 6 simultâneas e 2 de mini cursos.

O evento iniciou com o keynote do Ramon Durães – 2PC (realizador do evento) e Fernando Martin – Microsoft (gerente do produto Visual Studio).

A audiência foi muito alta, praticamente todos os auditórios lotaram, graças ao método de repetição das palestras em outro horário todos os participantes puderam assistir seus temas escolhidos sem precisar abrir mão de outro.

Todas as palestras foram entregues pontualmente, essa foi uma das nossas maiores preocupações em sinal de respeito aos palestrantes e espectadores. As palestras de 30 minutos foram desenvolvidas para entregar conteúdo de alto impacto. Rodando pelo evento ouvi muitos feedbacks positivos.

Um detalhe que me chamou muito a atenção, o público presente no evento foi de altíssimo nível técnico, profissionais da área que proporcionaram uma incrível troca de conhecimentos, dúvidas muito bem elaboradas, gostei muito de interagir com todos que tive a oportunidade.

Todas as palestras foram gravadas e serão disponibilizadas gratuitamente, em breve publicarei os links aqui.

Ao final do evento conversando com alguns funcionários da Microsoft foi revelado que este foi o maior evento realizado na sede da Microsoft, fico muito feliz por ter feito parte desse acontecimento.

Gostaria de agradecer a todos presentes, palestrantes e staffs, especialmente o time de MSP’s que foram indicados pela Microsoft para apoiar a realização do evento. Todos foram muito prestativos, educados e dedicados. Parabéns a vocês!

Aguardo você na próxima edição 🙂

Links para seguir

Vou palestrar no Visual Studio Summit 2013

Publicado em por

Olá pessoal,

O Visual Studio Summit 2013 é um evento anual realizado na sede da Microsoft Brasil onde alguns dos maiores nomes do mercado e convidados realizam palestras sobre todo o processo de desenvolvimento de software utilizando a plataforma de desenvolvimento Visual Studio.

E como era de se esperar os temas que serão apresentados estão super interessantes, recomendo como uma atualização de conhecimentos e troca de experiências com a comunidade técnica, vale muito a pena conferir.

Nesta edição irei apresentar o tema:
ASP.NET SignalR. O que é e como usar!

Já estou preparando o material para a palestra, o que vai render alguns artigos sobre o ASP.Net SignalR, fique ligado 😉

Para mais detalhes do evento:
http://www.visualstudiosummit.com.br 

Agradeço ao Mestre Ramon Durães pela oportunidade de colaborar em mais uma edição deste grande evento.

Te vejo lá !!!

TFS – Customizando o Workflow de um Work Item

Publicado em por

No TFS existe a opção de escolher qual o process template da metodologia que o projeto será gerenciado, atualmente existem os process templates para Scrum, MSF for CMMI e MSF for Agile. Os process templates fornecem ao projeto suporte as terminologias e definem vários elementos que determinada metodologia aborda.

É muito comum após um process template configurado surgir a necessidade de alguma modificação / adaptação, pois o processo da equipe pode ter alguma particularidade.

Nesse artigo usaremos o process template de Scrum para o exemplo. No Scrum existe o Conceito de Pronto que significa que um time Scrum define quais critérios são necessários para dar como pronta uma atividade. Com certeza para uma atividade ser considerada pronta é necessário que ela esteja testada. O workflow de uma atividade no process template Scrum vai de In Progress para Done, não existe o estado Testing.

Nesse artigo abordaremos como alterar o workflow de uma tarefa e incluir o estado Testing.

Esse artigo aborda o uso de:

Utilizando o TFS Power Tools para editar um Work Item

Após instalar o TFS Power Tools surgirá uma opção do menu Tools do Visual Studio chamado Process Editor

O Process Editor permite que seja editado um Work Item seja ele global ou de algum projeto específico.

No exemplo será editado o Work Item de Task onde será adicionado um novo campo de valor e também modificaremos o seu workflow para prever o novo estado de Testing.

O caminho a seguir é Work Item Types > Open WIT from Server

Surgirá uma janela de diálogo com os projetos disponíveis no TFS, será necessário expandir o projeto em questão e selecionar o tipo de Work Item a ser editado, selecione Task.

Modificando o Workflow de um Work Item no TFS

Na mesma tela Work Item Type clique na aba chamada Workflow

Abaixo está a ilustração do Workflow original para o Work Item de Task no Process Template Scrum 2.2:

A alteração que será executada será adicionar o novo estado Testing e alterar o fluxo de dos estados existentes, para isso serão necessária as ferramentas de design que estão disponíveis em Toolbox

Criando um Estado no Workflow

Arrastando um item da caixa State para o Workflow

Este é a caixa do novo estado, já foi renomeado para Testing e agora é necessário criar as transições, que são responsáveis por guiar o fluxo.

Para criar uma transição basta selecionar o item Transition Link na Toolbox clicar na caixa que a transição inicia e arrastar e soltar na caixa onde termina.

A transição de estado está feita, isso significa que quanto a tarefa estiver em estado Testing, será possível mudar para Done, agora é necessário realizar algumas configurações.

Com um duplo clique na caixa Transition abrirá uma janela de diálogo Workflow Transition.

Na aba Reasons cadastraremos um novo valor para quando o estado de Testing passar para Done.

Clicando em New para preencher o valor do Reason, que é a razão pelo qual a tarefa mudou de estado.

Note que no fluxo principal, a caixa Done requer a adição de um parâmetro o Closed Date, isso significa que é necessário passar essa informação para que haja transição de Testing para Done, a passagem desse valor é feita durante a transição através do item recurso Fields.

Pressione OK e retorne a janela de diálogo Workflow Transition, selecione a aba Fields e clique em New, o combo abaixo irá exibir diversas opções selecione ClosedDate.

Além de selecionar a referência do campo a ser passado é necessário configurar a regra de passagem, clique na aba Rules e selecione New, uma janela com uma lista exibirá todas as regras existentes, nesse caso a regra SERVERDEFAULT deve ser escolhida, pois trabalharemos com uma informação do servidor.

Como estamos trabalhando com um valor do tipo DateTime selecione no combo From a opção Clock, significa que iremos utilizar a data que está no servidor como referência.

Etapa concluída, o novo estado Testing está configurado e a transição para Done foi finalizada.

Note que exitem outras transições a serem feitas como por ex:

  • In Progress > Testing (Atividade finalizada e encaminhada para testes)
  • Testing > In Progress (Bugs encontrados, necessário trabalho adicional)

Basta seguir o mesmo processo para as demais transições.
Salve as alterações pelo Visual Studio e automaticamente o novo estado Testing estará publicado.

No próximo artigo gravarei um vídeo executando este processo e fornecendo mais detalhes de como modelar o Workflow de um Work Item.

Utilizem os comentários para dúvidas ou feedbacks.
Até a próxima 😉

TFS – Team Foundation Service – Parte II – Criando uma conta

Publicado em por

Olá pessoal,

Como havia prometido no post anterior, este post possui um vídeo que eu gravei falando sobre o Team Foundation Service, explico a diferença com o Team Foundation Server e caminho passo-a-passo desde o início no processo da criação de uma conta no Team Foundation Service.

Aproveitem e deixem seus comentários 🙂

Vou palestrar no DevBrasil Summit 2013

Publicado em por

Olá Pessoal, tudo bem?

DevBrasil Summit 2013

O DevBrasil Summit 2013 é encontro nacional da rede social DevBrasil reunindo desenvolvedores de software de todo o Brasil para falar de inovação, empreendedorismo e tecnologia.

Farei minha palestra sobre Visual Studio LightSwitch, um tema que eu adoro falar principalmente para o público mais jovem que está iniciando na carreira de desenvolvimento.

Segue link oficial, façam suas inscrições (gratuíto):
http://devbrasil.net/events/devbrasil-summit-2013-sao-paulo

Mais uma vez agradeço ao Mestre Ramon Durães e o time DevBrasil pela oportunidade 🙂

Espero vocês lá!

TFS – Team Foundation Service

Publicado em por

TFS – Team Foundation Service, é a conhecida plataforma de gerenciamento de código fonte e colaboração da Microsoft que foi parar na nuvem.

Team Foundation Service

Quando pensamos em TFS geralmente nos vem o nome Team Foundation Server, afinal trata-se de uma plataforma local, interna e instalada em um servidor.

A Microsoft há algum tempo disponibilizou esta mesma ferramenta só que hospedada na nuvem, ou seja, nos servidores do Windows Azure.

O famoso TFS passou a ser disponibilizado como serviço, notem que está cada vez mais comum encontrar os “SaaS” Software as a Service, diversos produtos da Microsoft já foram para nuvem (ex Office 365).

Minha experiência:

Tanto em casa como no trabalho eu sou usuário do TFS, no trabalho usamos a versão internalizada, ou seja instalada, e em casa antigamente eu tinha uma virtual machine rodando um windows 2008 server apenas para suportar o TFS.

Com o lançamento do TFS 2012 veio a versão TFS Express, gratuita para 5 usuários (porém com algumas limitações), que roda inclusive em windows 8.

Não cheguei a fazer uso do TFS Express, migrei diretamente para o TFS (Service) também conhecido como TFS Preview e o melhor, é de graça para 5 usuários também.

Estou plenamente satisfeito com minha escolha, não precisei instalar nada, apenas com a conta da Microsoft (antigo Live ID) fiz o login no site https://tfs.visualstudio.com/ e criei minha conta no TFS.

Todos os serviços estão disponíveis sem limitações, mesmo para as contas gratuitas, algumas funcionalidades podem se tornarem pagas daqui algum tempo, mas por enquanto a experiência é completa, vale a pena a imersão 🙂

A intenção deste post foi apresentar o serviço do TFS e comentar sobre minha experiência.
Em continuação deste farei um post técnico onde irei explicar passo-a-passo todo processo de utilização, aguardem 🙂

Até mais e abraços!

Undo Checkout no TFS

Publicado em por

Undo Checkout no TFS é um processo comum, mas e quando o arquivo está preso a outra pessoa? Nesse caso existem ferramentas de apoio para resolver, mas se você não tem nenhuma a solução é mais uma vez a linha de comando.

O comando é o tf undo (tf.exe) e para executá-lo você precisa do Visual Studio instalado

Para encontrar o diretório digite este caminho no Command Prompt:

cd %programfiles%Microsoft Visual Studio 11.0Common7IDE

Em uma edição de 64 bits do windows, substitua %programfiles% com %programfiles(x86)%.

*Atente-se ao diretório devido a qual versão do Visual Studio está usando.*

O comando deve ser chamado da seguinte forma:

tf undo [/workspace:workspacename[;workspaceowner]]
[/recursive] itemspec [/noprompt] [/login:username,[password]]
[/collection:TeamProjectCollectionUrl]

Naturalmente o usuário deverá ter permissão de Administer Workspaces para realizar esta operação.

/collection : TeamProjectCollectionUrl
Especifica a URL da coleção de projeto de equipe que contém os itens. Por exemplo: http://myserver:8080/tfs/DefaultCollection.

itemspec
Especifica o escopo de itens. Você pode especificar mais de um argumento de itemspec Para a sintaxe, consulte Referência de comandos de controle de versão do Team Foundation.

/login
Especifica a conta de usuário para usar o para executar o comando. Consulte Referência de comandos de controle de versão do Team Foundation.

/noprompt
Suprime a exibição das janelas e caixas de diálogo e redireciona dados de saída para o prompt de comando. Consulte Referência de comandos de controle de versão do Team Foundation.

/recursive
Desfaz recursivamente alterações dos itens no diretório especificado e todas as subpastas.

/workspace workspacename[;workspaceowner]
Especifica o nome do espaço de trabalho que você deseja desfazer alterações pendentes. Se não for especificado, o espaço de trabalho é aquele que mapeia o diretório atual.

Exemplos:

Remover as alterações pendentes em um arquivo
– Remove todas as alterações pendentes em program.cs

c:codeSiteAppMainSolutionAProject1>tf undo program.cs

Remova recursivamente durante alterações em todos os itens em uma pasta
– Remove todas as alterações pendentes na pasta c:codeSiteAppMain e todas suas subpastas.

c:codeSiteAppMain>tf undo * /recursive

Remover as alterações pendentes em um arquivo em um espaço de trabalho remota
– Remove todas as alterações pendentes em program.cs na coleção e o espaço de trabalho especificados.

c:>tf undo /collection:http://fabrikam-3:8080/tfs/DefaultCollection
/workspace:FABRIKAM-1;JuliaI $/SiteApp/Main/SolutionA/Project1/program.cs

Até a próxima dica 😉