Get Latest Version automático no CheckOut

Olá.

Muitas empresas já estão implantando o Team Foundation Server e, pelo que tenho percebido, as grandes dificuldades são principalmente quanto à diferença de paradigma e cultura, principalmente no que se refere ao Source Control.
Um dos pontos que mais incomodam os desenvolvedores acostumados ao Visual Source Safe é o fato do Visual Studio não pegar automaticamente a última versão do arquivo quando da realização do check out.

Os desenvolvedores do Team Foundation têm argumentos bem sólidos para este comportamento:

It turns out that this is by design, so let me explain the reasoning behind
it. When you perform a get operation to populate your workspace with a set
of files, you are setting yourself up with a consistent snapshot from source
control. Typically, the configuration of source on your system represents
a point in time snapshot of files from the repository that are known to work
together, and therefore is buildable and testable.
As a developer working in
a workspace, you are isolated from the changes being made by other
developers. You control when you want to accept changes from other
developers by performing a get operation as appropriate. Ideally when you
do this, you'll update the entire configuration of source, and not just one or
two files. Why? Because changes in one file typically depend on
corresponding changes to other files, and you need to ensure that you've still
got a consistent snapshot of source that is buildable and testable.
This is
why the checkout operation doesn't perform a get latest on the files being
checked out. Updating that one file being checked out would violate the
consistent snapshot philosophy and could result in a configuration of source
that isn't buildable and testable. As an alternative, Team Foundation
forces users to perform the get latest operation at some point before they
checkin their changes. That's why if you attempt to checkin your changes,
and you don't have the latest copy, you'll be prompted with the resolve
conflicts dialog.

Porém, muitas vezes, eles não têm conseguindo convencer a comunidade muito bem.

Por isso existem algumas iniciativas de confecção de plug-in para o Visual Studio que adicionam o comportamento ao mesmo.

Após instalar e testar alguns, percebemos que o melhor é o TFS GetLatest (http://blogs.microsoft.co.il/files/folders/leon/entry10828.aspx).

O melhor deste plug-in é que, configurados o servidor e a porta do Team Foundation Server, toda a ação de Get Latest Version é transparente quando o usuário realiza algum Check Out.

Abraços e até o próximo post.

No symbols have been loaded for this document

Olá.

Venho hoje falar rapidamente sobre um problema que vez ou outra ocorre quando queremos depurar nosso projeto e utilizarmos breakpoints.
O que o ocorre é que o Visual Studio simplesmente não para em algum breakpoint e este fica com o símbolo vazado e um ícone de alerta.
Ao passarmos o mouse sobre o ícone do breakpoint podemos notar a mensagem: “No symbols have been loaded for this document”.

O que ocorre é que o timestamp do arquivo “.pdb” gerado é diferente do timestamp da DLL ou exe.
Na maioria das vezes basta utilizarmos o recurso “Rebuild Solution” da solução ou “Rebuild” do projeto, para solucionarmos o problema.
Outras vezes é necessário que acessemos o diretório Debug do projeto e apaguemos o arquivo “. pdb".
Ao apagarmos este arquivo, o compilador, é obrigado a gerar um novo.

Por hoje é só.

Abraços e até o próximo post.

Referência circular usando Master Page e User Control

Olá.

Depois que a Microsoft nos disponibilizou as master pages nossa vida melhorou bastante. Mesmo com alguns contratempos a simples possibilidade de realizarmos herança visual em nossas páginas já é recompensador e, como todo bom recurso, tenho usado e abusado do mesmo.

Dentre os “abusos” posso citar a confecção de master pages de outras master pages (tenho casos de quatro níveis de herança) e controles que estão tanto na master page quanto na página que a implementa.

Este último “abuso” me causou bastante dor de cabeça.
Ainda não sei exatamente onde estava o problema, pois necessito estudar a fundo o modelo de compilação do ASP.NET 2.0.

Lembremos que houve uma mudança no sistema de compilação do ASP.NET.
Nas versões anteriores ao Visual Studio 2005 nossos sites eram projetos do tipo Web Project e agora temos o conceito de Web Site. Por haver material farto na internet sobre este assunto, vou diretamente ao meu problema, mas antes, segue link para quem quiser se aprofundar:

Compilando aplicações ASP.NET 2.0 - Mudanças no Modelo de Código e Compilação

Nota importante: para quem sente saudades ou necessita trabalhar como antigamente, o Service Pack 1 do Visual Studio 2005 adiciona um novo, porém velho conhecido, tipo de projeto: o Web Project. Mas ao trabalhar com este tipo de projeto você perderá uma série de vantagens dos Web Sites, como por exemplo, mudar algo no codebehind ou outra classe e não precisar recompilar.

Quando necessitei usar um mesmo controle de usuário (user control) na master page e na página (content place holder) recebi erros de referência circular.

Depois de algum tempo pesquisando postei minha dúvida no fórum da MSDN e obtive uma resposta quase que imediatamente. A sugestão era, ao invés de registrar o controle em cada página (na master page e na página), eu o registrasse no web.config, desta forma:

<configuration>
<system.web>
<pages>
<controls>
<add tagPrefix="IW" tagName="ctrPesquisas" src="~/Controles/ctrPesquisas.ascx"/>
</controls>
</pages>
</system.web>
</configuration>

Tal solução funcionou perfeitamente para o meu problema.

De maneira básica, os problemas de referência circular não necessariamente ocorrem diretamente entre páginas, controles e master pages.
Segundo o modelo de compilação padrão as classes em uma mesma pasta são compiladas em uma mesma DLL.
Vejam o exemplo visual abaixo:

No caso apresentado a ClasseA possui uma referência à ClasseC e a ClasseD possui uma referência para a ClasseB. Note que não há qualquer referência circular direta entre as classes, porém há uma referência circular entre as dll’s geradas porque a DLL1 referencia a DLL2 e a DLL2 referencia a DLL1.

Conhecendo este comportamento podemos adotar estratégias para evitar tais referências, como, por exemplo, movendo alguma das classes para outra pasta provocando assim a criação de uma terceira DLL e evitando a referência circular.

De maneira mais radical, poderemos utilizar a diretiva batch da tag compilation do web.config que força a criação de uma DLL para cada classe, página, controle e demais componentes.

<configuration>
<system.web>
<compilation batch="false">
</compilation>
</system.web>
</configuration>

Abraços e até o próximo post.