O Visual Studio 2010 sempre acha que o projeto está desatualizado, mas nada mudou


194

Eu tenho um problema muito semelhante ao descrito aqui .

Também atualizei uma solução mista de projetos C ++ / CLI e C # do Visual Studio 2008 para o Visual Studio 2010. E agora no Visual Studio 2010, um projeto C ++ / CLI sempre fica desatualizado.

Mesmo que tenha sido compilado e vinculado pouco antes e F5seja atingido, a caixa de mensagens "O projeto está desatualizado. Deseja construí-lo?" parece. Isso é muito irritante porque o arquivo DLL é muito baixo e exige que todos os projetos da solução sejam reconstruídos.

Minhas configurações de pdb estão definidas como o valor padrão ( solução sugerida para esse problema ).

É possível descobrir o motivo pelo qual o Visual Studio 2010 força uma reconstrução ou acha que um projeto está atualizado?

Alguma outra idéia de por que o Visual Studio 2010 se comporta dessa maneira?



Respostas:


224

Apenas para o Visual Studio / Express 2010. Veja outras respostas (mais fáceis) para VS2012, VS2013 etc.

Para localizar o (s) arquivo (s) ausente (s) , use as informações do artigo Habilitar o log do sistema de projeto C ++ para habilitar o log de depuração no Visual Studio e informe apenas o que está causando a reconstrução:

  1. Abra o devenv.exe.configarquivo (encontrado em %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ou em %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). Para versões Express, o arquivo de configuração é nomeado V*Express.exe.config.
  2. Adicione o seguinte após a </configSections>linha:

    <system.diagnostics>
      <switches>
        <add name="CPS" value="4" />
      </switches>
    </system.diagnostics>
    
  3. Reinicie o Visual Studio
  4. Abra o DbgView e verifique se está capturando a saída de depuração
  5. Tente depurar (pressione F5 no Visual Studio)
  6. Pesquise o log de depuração por qualquer linha do formulário:

    Informações sobre o devenv.exe: 0: O projeto 'Bla \ Bla \ Dummy.vcxproj' não está atualizado porque a entrada de compilação 'Bla \ Bla \ SomeFile.h' está ausente.

    (Apenas pressione Ctrl + F e procurei not up to date) Essas serão as referências que fazem com que o projeto fique perpetuamente "desatualizado".

Para corrigir isso, remova qualquer referência aos arquivos ausentes do seu projeto ou atualize as referências para indicar seus locais reais.

Nota: Se estiver usando 2012 ou posterior, o snippet deve ser:

<system.diagnostics>
  <switches>
   <add name="CPS" value="Verbose" />
  </switches>
</system.diagnostics>

4
> Abra o DbgView e verifique se está capturando a saída de depuração. Como garantir que a captura seja iniciada? Eu tenho o mesmo problema com projetos de reconstrução. Mas não há nenhuma informação no DebugView. Ativei a primeira opção 5 no menu 'Capture' do DebugView. (E obrigado por boas ligações em resposta!)
sergtk

3
Isso nos ajudou a descobrir; no entanto, também tivemos que excluir nosso diretório intermediário de compilação antes que a última referência .H desaparecesse - provavelmente para atualizar o StdAfx.obj? De qualquer forma, depois de excluir todas as pastas intermediárias de compilação e limpar os arquivos do projeto, também estamos prontos.
AHelps

2
Obrigado - agora, por que não está na janela de saída regular?
Martin Beckett

4
Se você estiver usando o VS2012, há um trecho ligeiramente diferente para colar no arquivo de configuração. Isso está ligado a partir do artigo original, mas apenas no caso: Habilitar C ++ e sistema de projeto Javascript rastreamento VS2012
rmaVT

3
FYI, isso parece não funcionar mais no VS2013 - após editar o arquivo de configuração, ele não gera nada de interesse no DebugView.
Nathan Reed

166

No Visual Studio 2012, consegui o mesmo resultado mais facilmente do que na solução aceita.

Alterei a opção no menu FerramentasOpçõesProjetos e soluçõesCompilar e executar → * Projeto MSBuild compila verbosidade de saída "de Mínimo para Diagnóstico .

Então, na saída de construção, encontrei as mesmas linhas pesquisando "não atualizado":

O projeto 'blabla' não está atualizado. O item de projeto 'c: \ foo \ bar.xml' possui o atributo 'Copiar para Diretório de Saída' definido como 'Copiar sempre'.


6
Isso também funciona no VS2013, onde o ajuste do arquivo de configuração parece não funcionar mais.
Nathan Reed

1
Isso funcionou muito bem para mim. Acontece que eu tinha uma referência circular (projeto1 -> projeto2, projeto2 -> projeto1.dll), que fazia com que a maior parte da solução fosse criada a cada vez. Nem estava em uso.
Kobi

7
Com C #, eu não poderia encontrar qualquer coisa com "não até à data", a palavra mágica parece ser "é mais recente que"
Pete

3
1>Project not up to date because build input 'C:\...\ReadMe.txt' is missing.: O !!?!
precisa saber é o seguinte

3
No VS2013, talvez você também precise procurar was modified atno modo de diagnóstico porque eu não tinha not up to datesaídas.
Java

59

Isso aconteceu comigo hoje. Consegui rastrear a causa: O projeto incluiu um arquivo de cabeçalho que não existia mais no disco.

A remoção do arquivo do projeto resolveu o problema.


2
Não, eu não tenho nenhum arquivo de cabeçalho que não existe no disco. Mas como você conseguiu rastrear a causa? Como você descobriu que havia um arquivo ausente? Talvez eu possa descobrir algo mais sobre o meu problema verificando da mesma maneira que você.
Chris U

1
Havia uma solução diferente quando isso aconteceu comigo. Provavelmente bastante obscuro, mas eu estava compilando o projeto de um computador, depois de outro, e descobri que acidentalmente havia definido o horário para AM em um computador e PM no outro. A diferença drástica de horário fez com que um dos computadores sempre compilasse tudo ou nunca compilasse nada, mesmo quando eu modifiquei os arquivos de origem.
Kev

1
Isso funcionou para mim, apesar do arquivo de cabeçalho existente. Usando a resposta abaixo para ativar o log, ele pensou que estava faltando um arquivo de cabeçalho. Eu removi sua dependência, a adicionei novamente e a reconstrução mínima funcionou novamente!
Ed Bayiates #

a inclinação do clock fará com que a maioria dos sistemas de construção a implodir
paulm

15

Também enfrentamos esse problema e descobrimos como resolvê-lo.

O problema foi o indicado acima "O arquivo não existe mais no disco".

isto não está correto. O arquivo existe no disco, mas o arquivo .VCPROJ está referenciando o arquivo em outro lugar.

Você pode 'descobrir' isso acessando a "exibição do arquivo de inclusão" e clicando em cada arquivo de inclusão até encontrar o que o Visual Studio não consegue encontrar. Você então adiciona esse arquivo (como um item existente) e exclui a referência que não pode ser encontrada e tudo está OK.

Uma pergunta válida é: como o Visual Studio pode criar se não sabe onde estão os arquivos de inclusão?

Acreditamos que o arquivo .vcproj tem algum caminho relativo para o arquivo incorreto em algum lugar que não é exibido na GUI do Visual Studio, e isso explica por que o projeto realmente será construído, mesmo que a exibição em árvore das inclusões esteja incorreta.


4
A razão pela qual o VC pode criar é porque são arquivos de cabeçalho - e os arquivos de cabeçalho não são compilados. Se algum dos arquivos de cabeçalho for realmente usado por um arquivo .C / .CPP, e somente então a compilação falhará. Portanto, o verificador de dependência (que procura o arquivo de cabeçalho) marca o projeto como necessitando de uma reconstrução, mas o compilador real (que simplesmente ignora a lista de arquivos de cabeçalho) pode ter êxito.
AHelps

4
Inacreditavelmente ... isso também acontece se você tiver uma referência antiga a um arquivo de texto (que NÃO faz parte da compilação mesmo que existisse !!) no seu arquivo .vcxproj. Eu havia gerado um projeto com o assistente e ele incluía um arquivo ReadMe.txt, que eu excluí do disco, mas esqueci de remover do vcxproj.
DLRdave

Não consigo encontrar nenhum arquivo que não possa abrir (exceto um, mas que esteja no disco rígido. Ele diz que algo como esse tipo de arquivo não pode ser aberto no SKU do Visual Studio 2010 Express ou algo assim.
Anonymous Penguin

2
O que é a "exibição de arquivo de inclusão" e como você a acessa?
Ben

1
A vista Incluir arquivo talvez seja a seção Incluir arquivos no Gerenciador de Soluções.
Jaywalker

12

A resposta aceita me ajudou no caminho certo para descobrir como resolver esse problema para o projeto errado que eu tinha que começar a trabalhar. No entanto, eu tive que lidar com um número muito grande de cabeçalhos de inclusão inválidos. Com a saída de depuração detalhada, a remoção de uma fazia com que o IDE congelasse por 30 segundos enquanto produzia o spew de depuração, o que tornava o processo muito lento.

Fiquei impaciente e escrevi um script Python rápido e sujo para verificar os arquivos de projeto (Visual Studio 2010) para mim e gerar todos os arquivos ausentes de uma só vez, juntamente com os filtros nos quais eles estão localizados. Você pode encontrá-lo como um Gist aqui: https://gist.github.com/antiuniverse/3825678 (ou este fork que suporta caminhos relativos )

Exemplo:

D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
  fx_cs_blood.h   (cstrike\fx_cs_blood.h)
  hud_radar.h   (cstrike\hud_radar.h)
[Game Shared Header Files]:
  basecsgrenade_projectile.h   (..\shared\cstrike\basecsgrenade_projectile.h)
  fx_cs_shared.h   (..\shared\cstrike\fx_cs_shared.h)
  weapon_flashbang.h   (..\shared\cstrike\weapon_flashbang.h)
  weapon_hegrenade.h   (..\shared\cstrike\weapon_hegrenade.h)
  weapon_ifmsteadycam.h   (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
  basepaenl.h   (swarm\gameui\basepaenl.h)
  ...

Código fonte:

#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET

ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'

#Works with relative path also
projectFileName = sys.argv[1]

if not os.path.isabs(projectFileName):
   projectFileName = os.path.join(os.getcwd(), projectFileName)

filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()

for inc in filterRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    incFilter = inc.find(ns+'Filter')
    if incFileRel != None and incFilter != None:
        filterDict[incFileRel] = incFilter.text
        if incFilter.text not in missingDict:
            missingDict[incFilter.text] = []

projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()

for inc in projRoot.iter(ns+'ClInclude'):
    incFileRel = inc.get('Include')
    if incFileRel != None:
        incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
        if not os.path.exists(incFile):
            missingDict[filterDict[incFileRel]].append(incFileRel)

for (missingGroup, missingList) in missingDict.items():
    if len(missingList) > 0:
        print("["+missingGroup+"]:")
        for missing in missingList:
            print("  " + os.path.basename(missing) + "   (" + missing + ")")

Seu código foi modificado para oferecer suporte a caminhos relativos. Sinta-se livre para atualizar sua essência e remover o link do meu garfo!
ixe013

Isso funcionou muito bem para mim! Que economia de tempo! Obrigado! Eu não tinha NADA na saída de diagnóstico que me dizia o que havia de errado, mas seu utilitário me mostrou!
Ed Bayiates

Outra garfo para enum um dir e chamá-lo em cada vcxproj encontrado gist.github.com/paulsapps/4992d2d460f4ef44538d62c9e875ca78
paulm

8

Excluí um cpp e alguns arquivos de cabeçalho da solução (e do disco), mas ainda tive o problema.

O problema é que todo arquivo que o compilador usa entra em um arquivo * .tlog no diretório temporário. Quando você remove um arquivo, esse arquivo * .tlog não é atualizado. Esse é o arquivo usado pelas compilações incrementais para verificar se o seu projeto está atualizado.

Edite esse arquivo .tlog manualmente ou limpe seu projeto e reconstrua-o.


Foi isso para mim! Passei horas depois de corrigir os arquivos de inclusão ausentes, AINDA estava desatualizado, o registro mostrou uma captura inconclusiva do que estava faltando. Necessário para se livrar desses arquivos TLOG! Obrigado!
Ed Bayiates

6

Eu tive um problema semelhante, mas no meu caso não havia arquivos ausentes, houve um erro na definição do arquivo de saída pdb: esqueci o sufixo .pdb (descobri com o truque de log de depuração).

Para resolver o problema, alterei, no arquivo vxproj, a seguinte linha:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

para

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

6

Eu tive esse problema no VS2013 (atualização 5) e pode haver dois motivos para isso, ambos os quais você pode encontrar ativando a saída de compilação "Detalhada" em "Ferramentas" -> "Projetos e soluções" -> "Compilar e executar" .

  1. "Forcing recompile of all source files due to missing PDB "..."
    Isso acontece quando você desabilita a saída de informações de depuração nas opções do compilador (em Configurações do projeto: „C / C ++“ -> “Formato de informações de depuração” para „Nenhum“ e „Linker“ -> “Gerar informações de depuração” para „Não“:) . Se você deixou "C / C ++" -> "Nome do arquivo do banco de dados do programa" no padrão (que é "$ (IntDir) vc $ (PlatformToolsetVersion) .pdb"), o VS não encontrará o arquivo devido a um erro ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
    Para corrigi-lo, basta limpar o nome do arquivo para "" (campo vazio).

  2. "Forcing rebuild of all source files due to a change in the command line since the last build."
    Também parece ser um bug conhecido do VS ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- a linha de comando desde a última compilação ) e parece ter sido corrigida nas versões mais recentes (mas não no VS2013). Eu não sabia de nenhuma solução alternativa, mas se você, por todos os meios, postá-lo aqui.


1
É por isso que o meu problema. Nenhuma das mensagens "não atualizadas" estava na minha e demorou uma eternidade para rastrearmos isso. Também removê-la ou defini-la para $ (IntDir) $ (ProjectName) PDB funcionou para nós (não se esqueça de mudá-lo para ambas as configurações de depuração e de lançamento)
John Grabanski

4

Não sei se mais alguém tem esse mesmo problema, mas as propriedades do meu projeto foram "Configuration Properties" -> C/C++ -> "Debug Information Format"definidas como "None" e, quando retornei ao "Program Database (/ Zi)" padrão, que impedia a recompilação do projeto toda vez .


1
+1 também funciona para mim, no Visual Studio 2013. Especificamente, quando eu alterno novamente para Nenhum, ele funciona bem novamente.
user541686

4

Outra solução simples referenciada pelo Visual Studio Forum .

Alterando a configuração: menu FerramentasOpçõesProjetos e soluçõesConfigurações do projeto VC ++Modo Solution Explorer para Mostrar todos os arquivos .

Então você pode ver todos os arquivos no Solution Explorer.

Encontre os arquivos marcados pelo ícone amarelo e remova-os do projeto.

Está certo.


4

Visual Studio 2013 - "Forçando a recompilação de todos os arquivos de origem devido à falta do PDB". Ativei a saída de compilação detalhada para localizar o problema: ativei a saída de compilação "Detalhada" em "Ferramentas" → "Projetos e soluções" → "Compilar e executar".

Eu tinha vários projetos, todos em C ++, defino a opção nas configurações do projeto: (C / C ++ → Formato de informações de depuração) para Program Database (/ Zi) para o projeto problemático. No entanto, isso não interrompeu o problema para esse projeto. O problema veio de um dos outros projetos C ++ na solução.

Defino todos os projetos C ++ como "Program Database (/ Zi)". Isso resolveu o problema.

Novamente, o projeto que relatou o problema não era o projeto do problema. Tente definir todos os projetos como "Banco de dados do programa (/ Zi)" para corrigir o problema.


O VS2015 é o mesmo em relação à configuração para saída de compilação detalhada
LOAS

3

Encontrei esse problema hoje, mas foi um pouco diferente. Eu tinha um projeto DLL CUDA na minha solução. A compilação de uma solução limpa estava OK, mas, caso contrário, falhava e o compilador sempre tratava o projeto CUDA DLL como não atualizado.

Eu tentei a solução deste post .

Mas não há nenhum arquivo de cabeçalho ausente na minha solução. Então eu descobri o motivo no meu caso.

Eu mudei o Diretório Intermediário do projeto antes, embora não tenha causado problemas. E agora, quando alterei o Diretório intermediário do projeto CUDA DLL de volta para $ (Configuration) \, tudo funcionou corretamente novamente.

Acho que há um pequeno problema entre a personalização de compilação CUDA e o diretório intermediário não padrão.


Usando o VS2013 (C #), experimentei definir o IntermediateOutputPath. Se isso apontar para uma pasta em uma unidade diferente da solução, a construção incremental para de funcionar - o MSBuild reclama que algum arquivo de origem está sempre desatualizado com algum arquivo intermediário (geralmente um PDB). Veja minha postagem no blog .
Robert Schmidt

3

Eu tive um problema semelhante e segui as instruções acima (a resposta aceita) para localizar os arquivos ausentes, mas não sem coçar a cabeça. Aqui está o meu resumo do que fiz. Para ser exato, não faltam arquivos, pois eles não precisam do projeto para construir (pelo menos no meu caso), mas são referências a arquivos que não existem no disco e que não são realmente necessários.

Aqui está a minha história:

  1. No Windows 7, o arquivo está localizado em %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Existem dois arquivos semelhantes devenv.exe.config.confige devenv.exe.config. Você quer mudar mais tarde.

  2. No Windows 7, você não tem permissão para editar este arquivo nos arquivos de programa. Basta copiá-lo em outro lugar (área de trabalho) e alterá-lo para o local dos arquivos do programa.

  3. Eu estava tentando descobrir como conectar o DebugView ao IDE para ver os arquivos ausentes. Bem, você não precisa fazer nada. Basta executá-lo e ele capturará todas as mensagens. Verifique se a Capture Eventsopção menu está selecionada no Capturemenu que, por padrão, deve ser selecionado.

  4. O DebugView NÃO exibirá todos os arquivos ausentes de uma só vez (pelo menos não para mim)! Você teria o DebugView em execução e, em seguida, o projeto no Visual Studio 2010. Ele solicitará a project out of datemensagem, selecione Sim para criar e o DebugView mostrará o primeiro arquivo que está faltando ou está causando a reconstrução. Abra o arquivo do projeto (não o arquivo de solução) no bloco de notas, procure esse arquivo e exclua-o. É melhor fechar o projeto e reabri-lo novamente ao fazer essa exclusão. Repita esse processo até o DebugView não mostrar mais nenhum arquivo ausente.

  5. É meio útil definir o filtro de mensagens para não estar atualizado no botão da barra de ferramentas DebugView ou na opção EditarFiltro / Destaque . Dessa forma, as únicas mensagens exibidas são aquelas que não possuem uma string 'atualizada'.

Eu tinha muitos arquivos que eram referências desnecessárias e a remoção deles corrigiu o problema seguindo as etapas acima.

Segunda maneira de encontrar todos os arquivos ausentes de uma só vez

Existe uma segunda maneira de encontrar esses arquivos de uma só vez, mas envolve (a) controle de origem e (b) integração com o Visual Studio 2010. Usando o Visual Studio 2010 , adicione seu projeto a um local desejado ou local fictício na origem ao controle. Ele tentará adicionar todos os arquivos, incluindo aqueles que não existem no disco também, mas referenciados no arquivo do projeto. Vá para o software de controle de origem, como o Perforce , e deve marcar esses arquivos que não existem no disco com um esquema de cores diferente. O Perforce os mostra com uma trava preta neles. Estas são as suas referências ausentes. Agora você tem uma lista de todos eles e pode excluí-los do arquivo do projeto usando o Bloco de Notas e seu projeto não reclamará por estar desatualizado .


2

Para mim, foi a presença de um arquivo de cabeçalho inexistente em "Arquivos de cabeçalho" dentro do projeto. Depois de remover esta entrada (clique com o botão direito do mouse em> Excluir do Projeto), recompile pela primeira vez e, em seguida, diretamente

========== Compilação: 0 bem-sucedido, 0 com falha, 5 atualizado, 0 ignorado ==========

e nenhuma tentativa de reconstrução sem modificação foi feita. Eu acho que é uma verificação antes da compilação implementada pelo VS2010 (não tenho certeza se documentada, poderia ser) que aciona o sinalizador "AlwaysCreate".


2

Se você estiver usando o comando MSBuild da linha de comando (não o IDE do Visual Studio), por exemplo, se você estiver direcionando o AppVeyor ou se preferir apenas a linha de comando, poderá adicionar esta opção à linha de comando do MSBuild:

/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8

Conforme documentado aqui (aviso: verbosidade usual do MSDN). Quando a construção terminar, procure a sequência will be compiledno arquivo de log criado durante a construção MyLog.log,.


1
/ verbosidade: detalhado também fornecerá as mesmas informações, mas não é tão detalhado. Você pode procurar por "será compilado como".
Shane Gannon

1
Você também deve procurar "compilation Fonte requerida", que também encontrará links
Shane Gannon

2

Estou usando o Visual Studio 2013 Professional com a Atualização 4, mas não encontrei resolução com nenhuma das outras sugestões; no entanto, consegui resolver o problema do meu projeto de equipe.

Aqui está o que eu fiz para causar o problema -

  • Criou um novo objeto de classe (Projeto -> Adicionar Classe)
  • Renomeei o arquivo pelo Solution Explorer e clicou em yes quando perguntado se eu queria renomear automaticamente todas as referências para corresponder

Aqui está o que eu fiz para resolver o problema -

  • Vá para a página inicial do Team Explorer
  • Clique em Source Control Explorer
  • Faça uma busca detalhada na pasta onde estão todos os arquivos de classe / projeto
  • Encontre o nome do arquivo ORIGINAL na lista e exclua-o clicando com o botão direito
  • Construir

Se esse for o seu caso, certifique-se de excluir o arquivo fantasma em vez do arquivo real que você deseja manter no projeto.


1

Eu tive esse problema e encontrei o seguinte:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Projeto Visual C ++ continuamente desatualizado ( winwlm.h macwin32.h rpcerr.h macname1.hausente)

Problema:

No Visual C ++ .Net 2003, um dos meus projetos sempre afirmava estar desatualizado, mesmo que nada tenha mudado e nenhum erro tenha sido relatado na última compilação.

A abertura do arquivo BuildLog.htm para o projeto correspondente mostrou uma lista de erros PRJ0041 para esses arquivos, nenhum dos quais aparece no meu sistema em nenhum lugar: winwlm.h macwin32.h rpcerr.h macname1.h

Cada erro é mais ou menos assim:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

Seu projeto ainda pode ser desenvolvido, mas pode continuar desatualizado até que este arquivo seja encontrado.

Solução:

Inclua em afxres.hvez de resource.hdentro do arquivo .rc do projeto.

O arquivo .rc do projeto continha "#include resource.h". Como o compilador de recursos não respeita os #ifdefbloqueios do pré-processador , ele se propaga e tenta encontrar os arquivos de inclusão que deve estar ignorando. Windows.h contém muitos desses blocos. A inclusão de afxres.h corrigiu os avisos do PRJ0041 e eliminou o diálogo de erro "O projeto está desatualizado".


1

No meu caso, um dos projetos contém vários arquivos IDL. O compilador MIDL gera um arquivo de dados DLL chamado 'dlldata.c' para cada um deles, independentemente do nome do arquivo IDL. Isso levou o Visual Studio a compilar os arquivos IDL em todas as compilações, mesmo sem alterações em nenhum dos arquivos IDL.

A solução alternativa é configurar um arquivo de saída exclusivo para cada arquivo IDL (o compilador MIDL sempre gera esse arquivo, mesmo se a opção / dlldata for omitida):

  • Clique com o botão direito do mouse no arquivo IDL
  • Selecione Propriedades - MIDL - Saída
  • Digite um nome de arquivo exclusivo para a propriedade DllData File

1

Passei muitas horas arrancando meu cabelo por causa disso. A saída da compilação não foi consistente; projetos diferentes "não estão atualizados" por razões diferentes de uma compilação para a compilação seguinte seguinte. Acabei descobrindo que o culpado era o DropBox (3.0.4). Uno minha pasta de origem de ... \ DropBox à minha pasta de projetos (não tenho certeza se esse é o motivo), mas o DropBox de alguma forma "toca" os arquivos durante uma compilação. Sincronização pausada e tudo está constantemente atualizado.


1

Existem várias razões possíveis e, como observado, você precisa primeiro diagnosticá-las definindo a verbosidade do MSBuild como 'Diagnóstico'. Na maioria das vezes, o motivo declarado seria auto-explicativo e você seria capaz de agir imediatamente, mas, ocasionalmente, o MSBuild alegaria erroneamente que alguns arquivos são modificados e precisam ser copiados.

Se for esse o caso, você precisará desativar o encapsulamento NTFS ou duplicar sua pasta de saída para um novo local. Aqui está em mais palavras.


1

Isso aconteceu comigo várias vezes e depois foi embora, antes que eu pudesse descobrir o porquê. No meu caso, foi:

Hora do sistema incorreta na configuração de inicialização dupla!

Acontece que minha inicialização dupla com o Ubuntu foi a causa raiz !! Eu tenho preguiça de consertar o Ubuntu para parar de mexer no meu relógio de hardware. Quando eu entro no Ubuntu, o tempo aumenta 5 horas para a frente.

Por azar, construí o projeto uma vez, com a hora errada do sistema, e depois a corrigo. Como resultado, todos os arquivos de compilação tinham registros de data e hora incorretos, e o VS pensaria que estão desatualizados e reconstruiria o projeto.


1

A maioria dos sistemas de construção usa registros de data e hora de dados para determinar quando as reconstruções devem ocorrer - o registro de data / hora de qualquer arquivo de saída é verificado com relação à hora da última modificação das dependências - se alguma das dependências for atualizada, o destino será reconstruído.

Isso pode causar problemas se alguma das dependências obter um carimbo de data / hora inválido, pois é difícil para o carimbo de hora de qualquer saída de compilação exceder o carimbo de data e hora de um arquivo supostamente criado no futuro: P


É possível obter o motivo pelo qual o VS2010 força uma reconstrução ou acha que um projeto está atualizado?
Chris U

No VS6 ou talvez no VS2005, havia um pequeno e estranho diálogo de propriedade que se obtinha ao clicar com o botão direito do mouse em um projeto que possuía guias mostrando as dependências e saídas de cada arquivo em um projeto. Eu não sei como obter o relatório equivalente no VS2008 (ou VS2010)
Chris Becke

1

Para mim, o problema surgiu em um projeto WPF em que alguns arquivos tinham a propriedade 'Build Action' definida como 'Resource' e 'Copy to Output Directory' definido como 'Copy if newer'. A solução parecia mudar a propriedade 'Copiar para Diretório de Saída' para 'Não copiar'.

O msbuild sabe que não deve copiar os arquivos 'Resource' para a saída - mas ainda aciona uma compilação se eles não estiverem lá. Talvez isso possa ser considerado um bug?

É extremamente útil com as respostas aqui, sugerindo como fazer com que o msbuild explique porque ele continua construindo tudo!


0

Se você alterar os argumentos do comando Debugging para o projeto, isso também acionará a mensagem do projeto que precisa ser reconstruída. Mesmo que o destino em si não seja afetado pelos argumentos de Depuração, as propriedades do projeto foram alteradas. Se você reconstruir, a mensagem deve desaparecer.


0

Eu tive um problema semelhante com o Visual Studio 2005 e minha solução consistiu em cinco projetos na seguinte dependência (primeiro criada na parte superior):

Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.

Eu estava descobrindo que o projeto Video_Codec queria uma compilação completa, mesmo após uma limpeza completa e depois a reconstrução da solução.

Corrigi isso, garantindo que o pdbarquivo de saída do C / C ++ e do vinculador correspondessem ao local usado pelos outros projetos em funcionamento. Também liguei o RTTI.


0

Outro no Visual Studio 2015 SP3, mas encontrei um problema semelhante no Visual Studio 2013 há alguns anos.

Meu problema foi que, de alguma forma, um arquivo cpp errado foi usado para cabeçalhos pré-compilados (então eu tinha dois arquivos cpp que criaram os cabeçalhos pré-compilados). Agora, por que o Visual Studio alterou os sinalizadores no cpp errado para 'criar cabeçalhos pré-compilados' sem o meu pedido? Não faço ideia, mas aconteceu ... talvez algum plug-in ou algo assim ???

De qualquer forma, o arquivo cpp errado inclui o arquivo version.h, que é alterado a cada compilação. Portanto, o Visual Studio recria todos os cabeçalhos e, por isso, todo o projeto.

Bem, agora está de volta ao comportamento normal.


0

Eu tinha um projeto VC ++ que estava sempre compilando todos os arquivos e havia sido atualizado anteriormente do VS2005 para o VS2010 (por outras pessoas). Descobri que todos os arquivos cpp no ​​projeto, exceto StdAfx.cpp, foram definidos como Criar (/ Yc) o cabeçalho pré-compilado. Alterei isso para que apenas StdAfx.cpp estivesse definido para criar o cabeçalho pré-compilado e o restante estivesse definido para Usar (/ Yu) o cabeçalho pré-compilado e isso corrigisse o problema para mim.


0

Estou no Visual Studio 2013 e acabei de atualizar para a atualização e compilação do Windows 10 de maio de 2019 de repente precisava ser refeita todas as vezes, independentemente das alterações. Tentei renomear o pch para ProjectName em vez de TargetName, procurei arquivos ausentes com o log detalhado e esse script Python, mas no final era minha vez de não ser sincronizado com os servidores da MS (em milissegundos).

O que resolveu isso para mim foi

  • "Ajustar data e hora" no painel de controle
  • "Sincronize agora"

Agora, meus projetos não precisam ser recompilados sem motivo.


0

Eu acho que você colocou uma nova linha ou outro espaço em branco. Remova-o e pressione F5 novamente.


-3

Os projetos .NET são sempre recompilados, independentemente. Parte disso é manter o IDE atualizado (como o IntelliSense). Lembro-me de fazer essa pergunta em um fórum da Microsoft anos atrás, e essa foi a resposta que me foi dada.


1
No VS2008, o projeto não era reconstruído todas as vezes. Isso é muito irritante, porque a dll é muito baixa e força quase todas as minhas dlls a serem reconstruídas. Algo deu errado na migração e não consigo descobrir o que.
Chris U

2
2008, 2010, 2012 e 2013 não fazem reconstruído projetos .NET toda
paulm

Há uma compilação em andamento (e lembre-se de que esta resposta tem 10 anos) para manter o intellisense funcional. I
Preet Sangha
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.