Visual Studio 2010 pensa sempre che il progetto non sia aggiornato, ma nulla è cambiato

Ho un problema molto simile come descritto qui .

Ho anche aggiornato una soluzione mista di progetti C ++ / CLI e C # da Visual Studio 2008 a Visual Studio 2010. E ora in Visual Studio 2010 un progetto C ++ / CLI è sempre scaduto.

Anche se è stato compilato e collegato poco prima e F5viene colpito, la finestra di messaggio "Il progetto non è aggiornato. Vuoi costruirlo?" appare. Questo è molto fastidioso perché il file DLL ha livelli molto bassi e forza la ricostruzione di quasi tutti i progetti della soluzione.

Le mie impostazioni pdb sono impostate sul valore predefinito ( soluzione suggerita di questo problema ).

È possibile ottenere il motivo per cui Visual Studio 2010 impone una ricostruzione o pensa che un progetto sia aggiornato?

Altre idee sul perché Visual Studio 2010 si comporti così?

Solo per Visual Studio / Express 2010. Vedi altre (più facili) risposte per VS2012, VS2013, ecc

Per trovare i file mancanti , utilizzare le informazioni dall'articolo Abilitare la registrazione del sistema di progetto C ++ per abilitare la registrazione di debug in Visual Studio e lasciare che ti dica cosa sta causando la ricostruzione:

1. Apri il devenv.exe.configfile (presente in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\o in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). Per le versioni Express il nome del file di configurazione V*Express.exe.config.

2. Aggiungi quanto segue dopo la </configSections>riga:

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

3. Riavvia Visual Studio
4. Apri DbgView e assicurati di catturare l'output di debug
5. Prova a eseguire il debug (premi F5 in Visual Studio)

6. Cerca nel registro di debug tutte le righe del modulo:

   devenv.exe Informazioni: 0: Progetto 'Bla \ Bla \ Dummy.vcxproj' non aggiornato perché manca l'input di compilazione 'Bla \ Bla \ SomeFile.h'.

   (Ho appena premuto Ctrl + F e cercato not up to date) Questi saranno i riferimenti che rendono il progetto perennemente "obsoleto".

Per correggere ciò, rimuovere eventuali riferimenti ai file mancanti dal progetto o aggiornare i riferimenti per indicarne la posizione effettiva.

Nota: se si utilizza 2012 o versioni successive, lo snippet dovrebbe essere:

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

In Visual Studio 2012 sono stato in grado di ottenere lo stesso risultato più facilmente rispetto alla soluzione accettata.

Ho cambiato l'opzione nel menu Strumenti → Opzioni → Progetti e soluzioni → Crea ed esegui → * Progetto MSBuild crea l'output dettagliato "da Minimo a Diagnostico .

Quindi nell'output di build ho trovato le stesse righe cercando "non aggiornato":

Il progetto "blabla" non è aggiornato. L'elemento del progetto 'c: \ foo \ bar.xml' ha l'attributo 'Copia nella directory di output' impostato su 'Copia sempre'.

Questo è successo a me oggi. Sono stato in grado di rintracciare la causa: il progetto includeva un file di intestazione che non esisteva più sul disco.

La rimozione del file dal progetto ha risolto il problema.

Abbiamo anche riscontrato questo problema e scoperto come risolverlo.

Il problema era come indicato sopra "Il file non esiste più sul disco."

Questo non è del tutto corretto. Il file esiste sul disco, ma il file .VCPROJ fa riferimento al file da qualche altra parte.

Puoi "scoprirlo" andando alla "visualizzazione del file include" e facendo clic su ciascun file include a sua volta fino a trovare quello che Visual Studio non riesce a trovare. Quindi aggiungi quel file (come elemento esistente) ed elimini il riferimento che non può essere trovato e tutto è OK.

Una domanda valida è: come può anche Visual Studio creare se non sa dove sono i file di inclusione?

Pensiamo che il file .vcproj abbia un percorso relativo al file offensivo da qualche parte che non viene mostrato nella GUI di Visual Studio e questo spiega perché il progetto verrà effettivamente creato anche se la vista ad albero delle inclusioni non è corretta.

La risposta accettata mi ha aiutato sulla strada giusta per capire come risolvere questo problema per il progetto incasinato con cui ho dovuto iniziare a lavorare. Tuttavia, ho dovuto affrontare un numero molto elevato di intestazioni di inclusione non valide. Con l'output dettagliato del debug, la rimozione di uno ha causato il blocco dell'IDE per 30 secondi durante l'output di spug di debug, il che ha reso il processo molto lento.

Sono diventato impaziente e ho scritto uno script Python veloce e sporco per controllare i file di progetto (Visual Studio 2010) per me e produrre tutti i file mancanti contemporaneamente, insieme ai filtri in cui si trovano. Puoi trovarlo come un Gist qui: https://gist.github.com/antiuniverse/3825678 (o questo fork che supporta percorsi relativi )

Esempio:

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

Codice sorgente:

#!/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 + ")")

Ho eliminato un cpp e alcuni file di intestazione dalla soluzione (e dal disco) ma ho ancora avuto il problema.

Il fatto è che ogni file utilizzato dal compilatore va in un file * .tlog nella directory temporanea. Quando si rimuove un file, questo file * .tlog non viene aggiornato. Questo è il file utilizzato dalle build incrementali per verificare se il progetto è aggiornato.

O modificare questo file .tlog manualmente o pulire il progetto e ricostruire.

Ho avuto un problema simile, ma nel mio caso non mancavano i file, c'era un errore nella definizione del file di output pdb: ho dimenticato il suffisso .pdb (ho scoperto con il trucco di registrazione del debug).

Per risolvere il problema ho modificato, nel file vxproj, la seguente riga:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

per

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Ho avuto questo problema in VS2013 (Aggiornamento 5) e ci possono essere due ragioni, entrambi i quali puoi trovare abilitando l'output di build "Dettagliato" in "Strumenti" -> "Progetti e soluzioni" -> "Build and Run" .

1. "Forcing recompile of all source files due to missing PDB "..."
   Ciò accade quando si disabilita l'output delle informazioni di debug nelle opzioni del compilatore (In Impostazioni progetto: „C / C ++“ -> “Formato informazioni di debug“ su „Nessuno“ e „Linker“ -> “Genera informazioni di debug“ su „No“:) . Se hai lasciato "C / C ++" -> "Nome file database programma" sul valore predefinito (che è "$ (IntDir) vc $ (PlatformToolsetVersion) .pdb"), VS non troverà il file a causa di un bug ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
   Per risolverlo, è sufficiente cancellare il nome del file su "" (campo vuoto).

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   Anche questo sembra essere un bug VS noto ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- the-command-line-since-the-last-build ) e sembra essere stato risolto nelle versioni più recenti (ma non VS2013). Non sapevo soluzioni alternative, ma se lo fai, pubblicalo qui.

Non so se qualcun altro ha lo stesso problema, ma le proprietà del mio progetto erano "Configuration Properties" -> C/C++ -> "Debug Information Format"impostate su "Nessuno" e quando sono tornato al "Database di programma (/ Zi)" predefinito, che ha impedito la ricompilazione del progetto ogni volta .

Un'altra soluzione semplice a cui fa riferimento il forum di Visual Studio .

Modifica della configurazione: menu Strumenti → Opzioni → Progetti e soluzioni → Impostazioni progetto VC ++ → Modalità Esplora soluzioni per mostrare tutti i file .

Quindi puoi vedere tutti i file in Esplora soluzioni.

Trova i file contrassegnati dall'icona gialla e rimuovili dal progetto.

Va bene.

Visual Studio 2013 - "Forzare la ricompilazione di tutti i file di origine a causa della mancanza del PDB". Ho attivato l'output di build dettagliato per individuare il problema: ho abilitato l'output di build "Dettagliato" in "Strumenti" → "Progetti e soluzioni" → "Build and Run".

Ho avuto diversi progetti, tutti in C ++, ho impostato l'opzione per le impostazioni del progetto: (C / C ++ → Formato informazioni di debug) su Programma database (/ Zi) per il progetto problema. Tuttavia, ciò non ha fermato il problema per quel progetto. Il problema derivava da uno degli altri progetti C ++ nella soluzione.

ho impostato tutti i progetti C ++ su "Programma Database (/ Zi)". Ciò ha risolto il problema.

Ancora una volta, il progetto che riportava il problema non era il progetto problema. Prova a impostare tutti i progetti su "Programma Database (/ Zi)" per risolvere il problema.

Ho riscontrato questo problema oggi, tuttavia era un po 'diverso. Ho avuto un progetto DLL CUDA nella mia soluzione. Compilare in una soluzione pulita era OK, ma per il resto non è riuscito e il compilatore ha sempre trattato il progetto DLL CUDA come non aggiornato.

Ho provato la soluzione da questo post .

Ma nella mia soluzione non è presente alcun file di intestazione mancante. Poi ho scoperto il motivo nel mio caso.

Ho cambiato la directory intermedia del progetto prima, anche se non ha causato problemi. E ora quando ho cambiato la directory intermedia del progetto CUDA DLL in $ (Configuration) \, tutto funziona di nuovo.

Immagino che ci sia qualche piccolo problema tra la personalizzazione della build CUDA e la directory intermedia non predefinita.

Ho avuto un problema simile e ho seguito le istruzioni sopra riportate (la risposta accettata) per individuare i file mancanti, ma non senza grattarmi la testa. Ecco il mio riassunto di ciò che ho fatto. Per essere precisi, questi non mancano file poiché non sono richiesti dal progetto per la costruzione (almeno nel mio caso), ma sono riferimenti a file che non esistono sul disco che non sono realmente richiesti.

Ecco la mia storia:

1. In Windows 7 il file si trova in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Ci sono due file simili devenv.exe.config.confige devenv.exe.config. Vuoi cambiarne uno dopo.

2. In Windows 7, non sei autorizzato a modificare questo file in file di programma. Basta copiarlo da qualche altra parte (desktop) cambiarlo e poi copiarlo nuovamente nella posizione dei file di programma.

3. Stavo cercando di capire come collegare DebugView all'IDE per vedere i file mancanti. Bene, non devi fare nulla. Basta eseguirlo e catturerà tutti i messaggi. Assicurarsi che l' Capture Eventsopzione di menu sia selezionata nel Capturemenu che per impostazione predefinita dovrebbe essere selezionata.

4. DebugView NON mostrerà tutti i file mancanti contemporaneamente (almeno non per me)! Avresti DebugView in esecuzione e quindi esegui il progetto in Visual Studio 2010. Verrà visualizzato il project out of datemessaggio, seleziona Sì per compilare e DebugView mostrerà il primo file mancante o che la ricostruzione. Aprire il file di progetto (non il file della soluzione) nel Blocco note e cercare quel file ed eliminarlo. È meglio chiudere il progetto e riaprirlo di nuovo mentre si esegue questa eliminazione. Ripetere questo processo fino a quando DebugView non mostra più alcun file mancante.

5. È utile impostare il filtro messaggi in modo che non sia aggiornato dal pulsante della barra degli strumenti DebugView o dall'opzione Modifica → Filtro / Evidenzia . In questo modo gli unici messaggi che visualizza sono quelli che contengono una stringa `non aggiornata '.

Avevo molti file che erano riferimenti inutili e rimuovendoli tutti risolto il problema seguendo i passaggi precedenti.

Secondo modo per trovare tutti i file mancanti contemporaneamente

Esiste un secondo modo per trovare tutti questi file contemporaneamente, ma prevede (a) il controllo del codice sorgente e (b) integrazione di esso con Visual Studio 2010. Utilizzando Visual Studio 2010 , aggiungi il tuo progetto alla posizione desiderata o alla posizione fittizia nel sorgente controllo. Tenterà di aggiungere tutti i file, inclusi quelli che non esistono anche sul disco ma a cui si fa riferimento nel file di progetto. Vai al tuo software di controllo del codice sorgente come Perforce , e dovrebbe contrassegnare questi file che non esistono sul disco in una combinazione di colori diversa. Perforce li mostra con un lucchetto nero su di essi. Questi sono i riferimenti mancanti. Ora hai un elenco di tutti e puoi eliminarli tutti dal tuo file di progetto usando Blocco note e il tuo progetto non si lamenterebbe di non essere aggiornato .

Per me era la presenza di un file di intestazione inesistente su "File di intestazione" all'interno del progetto. Dopo aver rimosso questa voce (clic con il tasto destro> Escludi dal progetto) la prima volta ricompilata, quindi direttamente

========== Build: 0 riuscito, 0 fallito, 5 aggiornato, 0 ignorato ==========

e nessun tentativo di ricostruzione senza modifiche è stato fatto. Penso che sia un check-before-build implementato da VS2010 (non sono sicuro che sia documentato, potrebbe essere) che innesca il flag "AlwaysCreate".

Se si utilizza il comando MSBuild della riga di comando (non l'IDE di Visual Studio), ad esempio se si sta prendendo di mira AppVeyor o si preferisce semplicemente la riga di comando, è possibile aggiungere questa opzione alla riga di comando di MSBuild:

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

Come documentato qui (avviso: consueta verbosità MSDN). Quando la costruzione è terminata, cercare la stringa will be compilednel file di registro creato durante la compilazione, MyLog.log.

Sto usando Visual Studio 2013 Professional con Update 4 ma non ho trovato la soluzione con nessuno degli altri suggerimenti, tuttavia sono riuscito a risolvere il problema per il mio progetto Team.

Ecco cosa ho fatto per causare il problema -

• Creato un nuovo oggetto classe (Progetto -> Aggiungi classe)
• Rinominato il file tramite Solution Explorer e fatto clic su Sì quando mi viene chiesto se volevo rinominare automaticamente tutti i riferimenti in modo che corrispondano

Ecco cosa ho fatto per risolvere il problema -

• Vai alla Home di Team Explorer
• Fai clic su Explorer controllo sorgente
• Drill nella cartella in cui si trovano tutti i file di classe / progetto
• Trovato il nome file ORIGINALE nell'elenco e cancellato con il tasto destro del mouse
• Costruire

Se questo è il tuo caso, assicurati di eliminare il file fantasma anziché quello effettivo che desideri conservare nel progetto.

Ho avuto questo problema e ho trovato questo:

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

Progetto Visual C ++ continuamente obsoleto ( winwlm.h macwin32.h rpcerr.h macname1.hmancante)

Problema:

In Visual C ++ .Net 2003, uno dei miei progetti ha sempre affermato di non essere aggiornato, anche se nulla era cambiato e nessun errore era stato segnalato nell'ultima build.

L'apertura del file BuildLog.htm per il progetto corrispondente ha mostrato un elenco di errori PRJ0041 per questi file, nessuno dei quali appare sul mio sistema ovunque: winwlm.h macwin32.h rpcerr.h macname1.h

Ogni errore è simile al seguente:

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

Il tuo progetto potrebbe ancora essere compilato, ma potrebbe continuare a apparire obsoleto fino a quando non viene trovato questo file.

Soluzione:

Includi afxres.hinvece diresource.h all'interno del file .rc del progetto.

Il file .rc del progetto conteneva "#include resource.h". Poiché il compilatore di risorse non rispetta i #ifdefblocchi del preprocessore , si romperà e proverà a trovare i file di inclusione che dovrebbe ignorare. Windows.h contiene molti di questi blocchi. Includendo afxres.h, invece, sono stati corretti gli avvisi PRJ0041 ed eliminato la finestra di dialogo di errore "Il progetto non è aggiornato".

Nel mio caso uno dei progetti contiene più file IDL. Il compilatore MIDL genera un file di dati DLL chiamato 'dlldata.c' per ciascuno di essi, indipendentemente dal nome del file IDL. Ciò ha comportato la compilazione da parte di Visual Studio dei file IDL su ogni build, anche senza modifiche a nessuno dei file IDL.

La soluzione alternativa è configurare un file di output univoco per ciascun file IDL (il compilatore MIDL genera sempre tale file, anche se l'opzione / dlldata è omessa):

• Fare clic con il tasto destro del mouse sul file IDL
• Seleziona Proprietà - MIDL - Uscita
• Immettere un nome file univoco per la proprietà File DllData

Ho trascorso molte ore a strapparmi i capelli per questo. L'output di compilazione non era coerente; progetti diversi sarebbero "non aggiornati" per motivi diversi da una build alla successiva build consecutiva. Alla fine ho scoperto che il colpevole era DropBox (3.0.4). Collego la mia cartella di origine da ... \ DropBox nella cartella dei miei progetti (non sono sicuro se questo sia il motivo), ma DropBox in qualche modo "tocca" i file durante una compilazione. Sincronizzazione in pausa e tutto è costantemente aggiornato.

Ci sono alcuni potenziali motivi e, come notato, è necessario prima di tutto diagnosticare impostando la verbosità di MSBuild su "Diagnostica". Il più delle volte il motivo dichiarato sarebbe autoesplicativo e si sarebbe in grado di agire immediatamente, MA a volte MSBuild avrebbe erroneamente affermato che alcuni file sono stati modificati e devono essere copiati.

In tal caso, dovrai disabilitare il tunneling NTFS o duplicare la cartella di output in una nuova posizione. Eccolo in più parole.

Questo mi è successo più volte e poi è andato via, prima che potessi capire il perché. Nel mio caso era:

Tempo di sistema errato nella configurazione a doppio avvio!

A quanto pare, il mio doppio avvio con Ubuntu è stata la causa principale !! Sono stato troppo pigro per sistemare Ubuntu per smettere di scherzare con il mio orologio hardware. Quando accedo a Ubuntu, il tempo salta di 5 ore in avanti.

Per sfortuna, ho realizzato il progetto una volta, con l'ora di sistema sbagliata, quindi ho corretto l'ora. Di conseguenza, tutti i file di build avevano timestamp errati e VS pensava che fossero tutti obsoleti e avrebbe ricostruito il progetto.

La maggior parte dei sistemi di compilazione utilizza i timestamp dei dati per determinare quando devono avvenire le ricostruzioni - la data / ora di tutti i file di output viene verificata rispetto all'ora dell'ultima modifica delle dipendenze - se una delle dipendenze è più fresca, la destinazione viene ricostruita.

Ciò può causare problemi se una delle dipendenze ottiene in qualche modo un timestamp di dati non valido poiché è difficile che il timestamp di qualsiasi output di build superi mai il timestamp di un file presumibilmente creato in futuro: P

Per me, il problema si è presentato in un progetto WPF in cui alcuni file avevano la proprietà "Build Action" impostata su "Risorsa" e "Copia nella directory di output" impostato su "Copia se più recente". La soluzione sembrava essere quella di cambiare la proprietà "Copia nella directory di output" in "Non copiare".

msbuild sa di non copiare i file "Resource" nell'output, ma attiva comunque una build se non è presente. Forse potrebbe essere considerato un bug?

È estremamente utile con le risposte qui che suggeriscono come fare in modo che msbuild sparga i fagioli sul perché continua a costruire tutto!

Se si modificano gli argomenti del comando di debug per il progetto, ciò attiverà anche il messaggio che deve essere ricostruito. Anche se la destinazione stessa non è influenzata dagli argomenti di debug, le proprietà del progetto sono cambiate. Se si esegue la ricostruzione, tuttavia, il messaggio dovrebbe scomparire.

Ho avuto un problema simile con Visual Studio 2005 e la mia soluzione consisteva in cinque progetti nella seguente dipendenza (prima costruita in alto):

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.

Stavo scoprendo che il progetto Video_Codec voleva una build completa anche dopo una completa pulizia e ricostruzione della soluzione.

Ho risolto questo problema assicurandomi che il pdbfile di output sia del C / C ++ che del linker corrispondesse alla posizione utilizzata dagli altri progetti di lavoro. Ho anche attivato RTTI.

Un altro su Visual Studio 2015 SP3, ma alcuni anni fa ho riscontrato un problema simile su Visual Studio 2013.

Il mio problema era che in qualche modo veniva usato un file cpp sbagliato per le intestazioni precompilate (quindi avevo due file cpp che creavano le intestazioni precompilate). Ora, perché Visual Studio ha cambiato i flag sul cpp sbagliato per 'creare intestazioni precompilate' senza la mia richiesta Non ne ho idea, ma è successo ... forse qualche plugin o qualcosa ???

Ad ogni modo, il file cpp sbagliato include il file version.h che viene modificato su ogni build. Visual Studio ricostruisce quindi tutte le intestazioni e per questo l'intero progetto.

Bene, ora è tornato al comportamento normale.

Avevo un progetto VC ++ che compilava sempre tutti i file ed era stato precedentemente aggiornato da VS2005 a VS2010 (da altre persone). Ho scoperto che tutti i file cpp nel progetto tranne StdAfx.cpp erano impostati su Crea (/ Yc) l'intestazione precompilata. Ho modificato questo in modo che solo StdAfx.cpp fosse impostato per creare l'intestazione precompilata e il resto fosse impostato su Usa (/ Yu) l'intestazione precompilata e questo ha risolto il problema per me.

Sono su Visual Studio 2013 e appena aggiornato all'aggiornamento di Windows 10 maggio 2019 e la compilazione improvvisamente ha dovuto essere rifatta ogni volta, indipendentemente dalle modifiche. Ho provato a rinominare il pch in ProjectName anziché TargetName, ho cercato i file mancanti con il registro dettagliato e quello script Python, ma alla fine era il mio momento non sincronizzato con i server di MS (come millisecondi).

Ciò che ha risolto questo per me è stato

• "Regola data e ora" nel pannello di controllo
• "Sincronizza ora"

Ora i miei progetti non devono essere ricompilati senza motivo.

Penso che tu abbia inserito qualche riga o altro spazio bianco. Rimuovilo e premi di nuovo F5.

I progetti .NET vengono sempre ricompilati a prescindere. Parte di questo è di mantenere aggiornato l'IDE (come IntelliSense). Ricordo di aver fatto questa domanda su un forum Microsoft anni fa, e questa è stata la risposta che mi è stata data.