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

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?

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>

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

Alterei a opção no menu Ferramentas → Opções → Projetos e soluções → Compilar 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'.

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.

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.

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 + ")")

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.

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>

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.

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 .

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

Alterando a configuração: menu Ferramentas → Opções → Projetos e soluções → Configuraçõ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.

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.

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.

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 Editar → Filtro / 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 .

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".

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,.

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.

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".

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

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.

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.

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.

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

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!

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.

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.

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.

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.

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.

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

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.