Uma pergunta semelhante foi feita e respondida cerca de um ano atrás, mas era um problema diferente (tudo estava na versão beta) ou foi diagnosticada incorretamente. Está localizado aqui:A tarefa do MSbuild falha porque a solução "Qualquer CPU" é criada fora de ordem.

Meu problema é que tenho um projeto instalador wix e, depois de atualizar para o Tfs2010 na segunda-feira, a compilação falha ao vincular porque não é possível encontrar o produto de compilação do aplicativo Wpf no projeto. Depois de algumas escavações, é porque ainda não foi construído. Construir no Vs2010 funciona normalmente. O projeto wix está configurado para depender do projeto Wpf e, ao visualizar a Ordem de criação do projeto no IDE, tudo parece normal.

O problema foi encontrado originalmente com apenas duas definições de plataforma na solução; x86 e x64. Também existem dois tipos, Debug and Release, e o TFSBuild.proj está definido para criar as quatro combinações. Não houve ocorrência de AnyCPU em nenhum lugar. De acordo com a pergunta mencionada acima, tentei alterar o projeto Wpf para usar o AnyCPU para que ele fosse criado primeiro. Neste ponto, o projeto wix usava a configuração exata e o projeto Wpf usava o sabor com AnyCPU. No entanto, fazer isso não pareceu mudar nada.

Estou usando o Tfs2010 RTM, Vs2010 RTM e a versão mais recente do Wix, que no momento em que este artigo foi escrito era 3.5.1602.0, de 02/04/2010. Alguém mais se deparando com isso?

27-04-2010: Depois de uma boa quantidade de escavação e reprodução em uma máquina de compilação de VM clonada, acredito que sei o que está acontecendo e também o que está falhando, mas não sei como corrigi-lo.

A situação é que esse bug parece exibir sintomas com base na ordenação pura e simples do projeto no arquivo de solução. Parece que o arquivo de solução apenas constrói cegamente os projetos na ordem em que aparecem, confiando em sua capacidade de detectar referências não construídas e construí-las sob demanda, quando necessário.

No meu arquivo de solução específico, meu projeto Wix foi encomendado antes do meu projeto de aplicativo Wpf. Isso resultou no projeto Wix sendo construído primeiro e, embora a dependência do projeto Wpf tenha sido detectada corretamente, a tarefa MSBuild real foi ignorada devido à variável indefinida $ (BuildProjectReferences). Mencionei alguns comentários da publicação principal deste fio. Com a verbosidade do MSBuild ainda no diagnóstico, BuildProjectReferences pode ser visto como indefinido na construção do projeto Wix, e pode ser definido como verdadeiro ao criar o projeto Wpf na tarefa de compilar o projeto Wix. No entanto, quando testado, ele avalia indefinidamente novamente, a tarefa é pulada e a compilação Wix falha porque não consegue encontrar a saída de compilação do projeto Wpf não construído.

Resumindo: a dependência do projeto é ignorada devido à variável $ (BuildProjectReferences) incorreta. Curiosamente, essa variável está presente apenas no arquivo Wix2010.targets, e não no wix.targets; Eu acho que é por isso que isso está aparecendo depois que eu instalei o Tfs2010 e o Vs2010.

A solução: Como garantir que o BuildProjectReferences seja transmitido corretamente para as tarefas subsequentes do MSBuild? Existe algo especial com o escopo variável acontecendo?

14-09-2010: Foi aberto um bug para esse problema no conjunto de ferramentas do WiX:http://sourceforge.net/tracker/?func=detail&atid=642714&aid=2990231&group_id=105970 e corrigido há um tempo atrás. Felizmente, isso não é mais um problema. Nesse caso, abra um novo bug.

Para endereçar seu comentário diretamente, nada na minha solução possui uma configuração de AnyCPU em seus arquivos de compilação. Eu criei as configurações do AnyCPU apenas para testar a solução sugerida pelo segmento ao qual vinculei minha postagem original. Depois que não funcionou, removi as configurações do AnyCPU novamente.

Além disso, os projetos estão no mesmo arquivo de solução, no entanto, em pastas de solução separadas (pasta de interface, pasta do instalador), se isso importa.

Curiosamente, eu ia fazer um pequeno exemplo de sandbox para ilustrar o problema que estava tendo, no entanto, depois de criar minha pequena solução de amostra, não foi possível reproduzir o erro. Isso me faz pensar que talvez seja o resultado do uso de um projeto de equipe que foi atualizado a partir de um projeto de equipe do Tfs2008, em vez de um que foi criado recentemente no Tfs2010. Posso tentar ramificar meu projeto em um novo para testar essa teoria se não conseguir descobrir por que a solução de teste funciona.

p.s. além disso, sou novo no stackoverflow - por que diabos os comentários têm tamanho limitado se o fluxo de trabalho "responda sua própria pergunta" se destina apenas a fornecer respostas concretas?

Então, eu joguei a verbosidade de compilação para diagnóstico e a li hoje, e uma linha em particular se destacou para mim:

Task "MSBuild" skipped, due to false condition; ('@(_ProjectReferenceWithConfiguration)'!='' and '$(BuildingInsideVisualStudio)' != 'true' and '$(BuildProjectReferences)' == 'true' and '@(_MSBuildProjectReferenceExistent)' != '') was evaluated as ('..\WpfApp\WpfApp.csproj'!='' and '' != 'true' and '' == 'true' and '..\WpfApp\WpfApp.csproj' != '').

Isso foi visto como meu projeto instalador estava tentando criar meu projeto wpf, pois o projeto wpf é referenciado. Em particular, por algum motivo, $ (BuildProjectReferences) está sendo avaliado como '' quando tenho quase certeza de que deve ser 'verdadeiro'.

No entanto, no início do log, no início da tarefa MSBuild para o projeto WpfApp, vi o seguinte:

Task "MSBuild" (TaskId:15)
...
Initial Properties:
...
BuildProjectReferences = true

Portanto, a propriedade estava realmente correta até o início da tarefa, mas aparentemente foi substituída? Não sei ao certo como essas propriedades são definidas.