Panoramica dei potenziali problemi di aggiornamento (Visual C++)

Nel corso degli anni il compilatore Microsoft C++ ha subito molte modifiche, che si aggiungono a quelle apportate al linguaggio C++, alla libreria standard C++, al runtime C (CRT) e ad altre librerie, ad esempio MFC e ATL. Di conseguenza, quando si aggiorna un'applicazione da una versione precedente di Visual Studio, potrebbero essere visualizzati errori del compilatore e del linker e avvisi nel codice compilato in precedenza. Più la base di codice è vecchia, maggiore è la possibilità di tali errori. Questa panoramica riepiloga le classi più comuni di problemi che è probabile visualizzare e fornisce collegamenti a informazioni più dettagliate.

È possibile inviare domande o commenti sul processo di aggiornamento all'indirizzo vcupgrade@microsoft.com.

Dipendenze di librerie e set di strumenti

Quando si aggiorna un'app da Visual Studio 2013 o prima a una versione più recente, è spesso consigliabile e necessario aggiornare tutte le librerie e le DLL a cui l'app è collegata. È necessario avere accesso al codice sorgente oppure il fornitore della libreria deve fornire nuovi file binari compilati con la stessa versione principale del compilatore. Se una di queste condizioni è vera è possibile ignorare questa sezione, che illustra i dettagli della compatibilità binaria. In caso contrario, le librerie potrebbero non funzionare nell'app aggiornata. Le informazioni contenute in questa sezione consentono di comprendere se è possibile continuare con l'aggiornamento.

Set di strumenti

I formati di .obj file e .lib sono ben definiti e raramente cambiano. Talvolta vengono eseguite aggiunte a questi formati di file, ma tali aggiunte in genere non influenzano la capacità dei set di strumenti più recenti di usare file oggetto e librerie prodotte da set di strumenti meno recenti. L'eccezione principale è se si esegue la compilazione usando /GL (Ottimizzazione dell'intero programma). Se si esegue la compilazione usando /GL, è possibile collegare solo il file oggetto risultante usando lo stesso set di strumenti usato per produrlo. Pertanto, se si produce un file oggetto con /GL e si usa un compilatore di Visual Studio 2017 (v141), è necessario collegarlo usando il linker di Visual Studio 2017 (v141). Ciò è dovuto al fatto che le strutture di dati interne all'interno dei file oggetto non sono stabili nelle versioni principali del set di strumenti. I set di strumenti più recenti non comprendono i formati di dati meno recenti.

C++ non dispone di un'interfaccia binaria dell'applicazione stabile (ABI, Aplication Binary Interface). Visual Studio gestisce tuttavia un'ABI C++ stabile per tutte le versioni secondarie di una versione. Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142) e Visual Studio 2022 (v143) variano solo nella versione secondaria. Hanno tutti lo stesso numero di versione principale, vale a dire 14. Per altre informazioni, vedere Compatibilità binaria C++ tra le versioni di Visual Studio.

Se è presente un file oggetto che include simboli esterni con collegamento a C++, tale file oggetto potrebbe non collegarsi correttamente con file oggetto creati con un'altra versione principale del set di strumenti. Ci sono molti risultati possibili: il collegamento potrebbe non riuscire completamente (ad esempio, se la decorazione del nome è cambiata). Il collegamento potrebbe avere esito positivo, ma l'app potrebbe non riuscire in fase di esecuzione(ad esempio, se i layout dei tipi sono stati modificati). In alternativa, l'app potrebbe continuare a funzionare e nulla andrà storto. Si noti anche che, mentre l'ABI C++ non è stabile, l'ABI C e il subset dell'ABI C++ richiesto per COM sono stabili.

Se si effettua il collegamento a una libreria di importazione, in fase di esecuzione si potranno usare tutte le versioni successive delle librerie ridistribuibili di Visual Studio che mantengono la compatibilità ABI. Ad esempio, se si compila e si collega l'app usando il set di strumenti di Visual Studio 2015 Update 3, è possibile usare qualsiasi ridistribuibile in un secondo momento. Questo perché le librerie 2015, 2017, 2019 e 2022 hanno mantenuto la compatibilità binaria con le versioni precedenti. Il contrario non è vero: non è possibile usare una ridistribuibile per una versione precedente del set di strumenti rispetto a quella usata per compilare qualsiasi componente del codice.

Librerie

Se si dispone #include di una versione specifica dei file di intestazione, è necessario collegare il file oggetto risultante alla stessa versione delle librerie. Ad esempio, se il file di origine include Visual Studio 2015 Update 3 <immintrin.h>, è necessario collegarsi alla libreria di Visual Studio 2015 Update 3 vcruntime . Analogamente, se il file di origine include visual Studio 2017 versione 15.5 <iostream>, è necessario collegarsi alla libreria C++ standard di Visual Studio 2017 versione 15.5, msvcprt. La combinazione e la corrispondenza non sono supportate.

Per la libreria standard C++, la combinazione e la corrispondenza non sono state esplicitamente consentite dall'uso di #pragma detect_mismatch nelle intestazioni standard a partire da Visual Studio 2010. Se si tenta di collegare file oggetto incompatibili o se si collega alla libreria standard errata, il collegamento non riesce.

La versione precedente di CRT mix-and-matching non è mai stata supportata, ma spesso funzionava solo perché la superficie API non cambiava molto nel tempo. Con la libreria Universal CRT è stata interrotta la compatibilità con le versioni precedenti, che ora è soggetta a gestione. Non abbiamo intenzione di introdurre nuovi file binari Universal CRT con controllo delle versioni in futuro. Al contrario, ora viene aggiornata la libreria Universal CRT esistente.

Per garantire la compatibilità dei collegamenti parziali con i file oggetto (e le librerie) compilati con le versioni precedenti delle intestazioni di Microsoft C Runtime, è disponibile una libreria, legacy_stdio_definitions.lib, con Visual Studio 2015 e versioni successive. Questa libreria include simboli di compatibilità per la maggior parte delle funzioni e delle esportazioni dati che sono state rimosse da Universal CRT. Il set di simboli di compatibilità forniti da legacy_stdio_definitions.lib è sufficiente per soddisfare la maggior parte delle dipendenze, incluse tutte le dipendenze nelle librerie incluse in Windows SDK. Tuttavia, alcuni simboli sono stati rimossi da Universal CRT che non hanno simboli di compatibilità. Questi simboli includono sia alcune funzioni ( ad esempio ) che alcune esportazioni di dati ( ad esempio __iob_func, __imp___pctype__imp___iob, ). __imp___mb_cur_max

Se si dispone di una libreria statica compilata usando una versione precedente delle intestazioni di runtime C, è consigliabile eseguire le azioni seguenti, in questo ordine:

1. Ricompilare la libreria statica con la versione recente di Visual Studio 2017 e le intestazioni Universal CRT per garantire il supporto del collegamento con la libreria Universal CRT. Questo approccio è completamente supportato e l'opzione migliore.

2. Se non è possibile (o non si vuole) ricompilare la libreria statica, è possibile provare a collegarsi a legacy_stdio_definitions.lib. Se soddisfa le dipendenze in fase di collegamento della libreria statica, è necessario testare accuratamente la libreria statica come viene usata nel file binario. Assicurarsi che non sia influenzato negativamente da alcuna modifica comportamentale apportata a Universal CRT.

3. Ad esempio, le dipendenze della libreria statica non sono soddisfatte da legacy_stdio_definitions.lib o la libreria non funziona con Universal CRT a causa di modifiche del comportamento. In questo caso, è consigliabile incapsulare la libreria statica in una DLL che si collega alla versione richiesta di Microsoft C Runtime. Ad esempio, se la libreria statica è stata compilata usando Visual Studio 2013, compilare questa DLL usando anche il set di strumenti di Visual Studio 2013 e le librerie C++. Incorporando la libreria in una DLL si isola il dettaglio di implementazione rappresentato dalla dipendenza della libreria da una versione specifica del runtime Microsoft C. Prestare attenzione all'interfaccia DLL non perde i dettagli del runtime C usato, ad esempio, se restituisce un FILE* oggetto oltre il limite della DLL o un mallocpuntatore allocato dal chiamante deve free.

L'uso di più CRT in un singolo processo non è in e di per sé problematico. La maggior parte dei processi carica infatti più DLL CRT. Ad esempio, i componenti del sistema operativo Windows dipendono da msvcrt.dlle CLR dipende dal proprio CRT privato. I problemi si verificano quando si combina lo stato da diversi CRT. Ad esempio, non è consigliabile allocare memoria usando msvcr110.dll!malloc e tentare di deallocare la memoria usando msvcr120.dll!freee non è consigliabile tentare di aprire un file usando msvcr110!fopen e tentare di leggere da tale FILE usando msvcr120!fread. Purché non si esebri lo stato da diversi CRT, è possibile caricare più CRT in un unico processo.

Per altre informazioni, vedere Upgrade your code to the Universal CRT (Aggiornare il codice a Universal CRT).

Errori causati dalle impostazioni del progetto

Per iniziare il processo di aggiornamento, aprire un progetto/soluzione/area di lavoro precedente nella versione più recente di Visual Studio. In Visual Studio verrà creato un nuovo progetto basato sulle impostazioni di progetto precedenti. Controllare se il progetto precedente ha percorsi di libreria o includere percorsi hardcoded in percorsi non standard. È possibile che i file in tali percorsi non saranno visibili al compilatore quando il progetto usa le impostazioni predefinite. Per altre informazioni, vedere Configurazione della proprietà OutputFile del linker.

In generale, ora è un ottimo momento per organizzare il codice del progetto per semplificare la manutenzione del progetto e aiutare a ottenere il codice aggiornato per la compilazione il più rapidamente possibile. Se il codice sorgente è già ben organizzato e il progetto precedente viene compilato in Visual Studio 2010 o versione successiva, è possibile modificare manualmente il nuovo file di progetto per supportare la compilazione sia nel compilatore precedente che in quello nuovo. Nell'esempio seguente viene illustrato come compilare sia per Visual Studio 2015 che per Visual Studio 2017:

<PlatformToolset Condition="'$(VisualStudioVersion)'=='14.0'">v140</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)'=='15.0'">v141</PlatformToolset>

LNK2019: simbolo esterno non risolto

Se vengono rilevati simboli non risolti, potrebbe essere necessario correggere le impostazioni del progetto.

• Se il file di origine si trova in un percorso non predefinito, è stato aggiunto il percorso alle directory di inclusione del progetto?

• Se l'esterno è definito in un .lib file, è stato specificato il percorso lib nelle proprietà del progetto ed è la versione corretta del .lib file presente?

• Si sta tentando di collegare un .lib file compilato con una versione diversa di Visual Studio? In questo caso, vedere la sezione precedente relativa alle dipendenze di librerie e set di strumenti.

• I tipi degli argomenti nel sito di chiamata corrispondono di fatto a un overload esistente della funzione? Verificare che i tipi sottostanti siano previsti, sia per qualsiasi typedef nella firma della funzione che nel codice che chiama la funzione.

Per risolvere gli errori di simboli non risolti, è possibile usare dumpbin.exe per esaminare i simboli definiti in un file binario. Provare la riga di comando seguente per visualizzare i simboli definiti in una libreria:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t è un tipo nativo)

In Microsoft Visual C++ 6.0 e versioni precedenti wchar_t non è stato implementato come tipo predefinito. È stato dichiarato in wchar.h come typedef per unsigned short.) Lo standard C++ richiede che wchar_t sia un tipo predefinito. L'uso della versione typedef può causare problemi di portabilità. Se si esegue l'aggiornamento da versioni precedenti di Visual Studio e viene visualizzato l'errore del compilatore C2664 perché il codice sta tentando di convertire in modo implicito un wchar_t in unsigned short, è consigliabile modificare il codice per correggere l'errore, anziché impostare /Zc:wchar_t-. Per altre informazioni, vedere /Zc:wchar_t (wchar_t è un tipo nativo).

Aggiornamento con le opzioni /NODEFAULTLIBdel linker , /ENTRYe /NOENTRY

L'opzione /NODEFAULTLIB del linker (o la proprietà del linker Ignora tutte le librerie predefinite ) indica al linker di non collegare automaticamente nelle librerie predefinite, ad esempio CRT. Significa che ogni libreria deve essere elencata come input singolarmente. Questo elenco di librerie è disponibile nella proprietà Dipendenze aggiuntive, nella sezione Linker della finestra di dialogo Proprietà progetto.

I progetti che usano questa opzione evidenziano un problema durante l'aggiornamento, perché i nomi di alcune librerie predefinite sono cambiati. Dato che ogni singola libreria va elencata nella proprietà Dipendenze aggiuntive o nella riga di comando del linker, è necessario aggiornare l'elenco di librerie in modo che usi tutti i nomi correnti.

La tabella seguente elenca le librerie delle quali è stato cambiato il contenuto a partire da Visual Studio 2015. Per eseguire l'aggiornamento è necessario aggiungere i nomi libreria nuovi nella seconda colonna alle librerie nella prima colonna. Alcune di queste librerie sono librerie di importazione, ma non è importante.

Lo stesso vale se si usa l'opzione /ENTRY o l'opzione /NOENTRY, che hanno anche l'effetto di ignorare le librerie predefinite.

Errori causati da una migliore conformità del linguaggio

Nel corso degli anni è stata migliorata in modo continuativo la conformità del compilatore Microsoft C++ allo standard C++. Il codice compilato nelle versioni precedenti potrebbe non riuscire a essere compilato nelle versioni successive di Visual Studio. Ciò è dovuto al fatto che il compilatore contrassegna correttamente un errore che in precedenza è stato ignorato o consentito in modo esplicito.

Ad esempio, l'opzione /Zc:forScope è stata introdotta nella cronologia di MSVC. L'opzione consente un comportamento non conforme per le variabili di ciclo. Questa opzione ora è deprecata e potrebbe essere rimossa nelle versioni future. È consigliabile non usare questa opzione durante l'aggiornamento del codice. Per altre informazioni, vedere /Zc:forScope- deprecato.

Un esempio di errore comune durante l'aggiornamento si verifica quando un argomento non const viene passato a un parametro const. Le versioni precedenti del compilatore non lo contrassegnano sempre come errore. Per altre informazioni, vedere Conversioni più rigorose del compilatore.

Per altre informazioni sui miglioramenti specifici della conformità, vedere Cronologia delle modifiche di Visual C++ dal 2003 al 2015 e Miglioramenti della conformità di C++ in Visual Studio.

Errori relativi ai <stdint.h> tipi integrali

L'intestazione <stdint.h> definisce typedef e macro che, a differenza dei tipi integrali predefiniti, hanno una lunghezza specificata in tutte le piattaforme. Alcuni esempi sono uint32_t e int64_t. L'intestazione <stdint.h> è stata aggiunta in Visual Studio 2010. Il codice scritto prima del 2010 potrebbe avere fornito definizioni private per tali tipi. E queste definizioni potrebbero non essere sempre coerenti con le <stdint.h> definizioni.

Se l'errore è C2371 e viene coinvolto un stdint tipo, è probabile che il tipo sia definito in un'intestazione nel codice o in un file di libreria di terze parti. Quando si esegue l'aggiornamento, è necessario eliminare qualsiasi definizione personalizzata di <stdint.h> tipi, ma prima confrontare le definizioni personalizzate con le definizioni standard correnti per assicurarsi di non introdurre nuovi problemi.

È possibile premere F12, ovvero Vai a definizione, per visualizzare la posizione in cui è definito il tipo in questione.

L'opzione del /showIncludes compilatore può essere utile qui. Nella finestra di dialogo Pagine delle proprietà per il progetto selezionare la pagina Proprietà>di configurazione C/C++>Avanzate e impostare Mostra include su Sì. Ricompilare quindi il progetto. Verrà visualizzato l'elenco dei file nella finestra di #include output. Ogni intestazione è provvista di un rientro sotto l'intestazione che la include.

Errori relativi alle funzioni CRT

Nel corso degli anni sono state apportate numerose modifiche al runtime C. Sono state aggiunte molte versioni sicure delle funzioni e alcune sono state rimosse. Come descritto in precedenza in questo articolo, inoltre, l'implementazione di Microsoft di CRT è stata sottoposta a refactoring in Visual Studio 2015 in nuovi file binari e file associati .lib .

Se un errore riguarda una funzione CRT, cercare altre informazioni in Cronologia delle modifiche di Visual C++ dal 2003 al 2015 o in Miglioramenti della conformità di C++ in Visual Studio. Se l'errore è LNK2019, assicurarsi che la funzione non sia stata rimossa. In caso contrario, se si è certi che la funzione esista ancora e il codice chiamante sia corretto, verificare se il progetto usa /NODEFAULTLIB. In tal caso, è necessario aggiornare l'elenco delle librerie per usare le nuove librerie universali (UCRT). Per altre informazioni, vedere la sezione precedente relativa alla libreria e alle dipendenze.

Se l'errore riguarda printf o scanf, assicurarsi di non definire privatamente alcuna funzione senza includere stdio.h. In tal caso, rimuovere le definizioni private o il collegamento a legacy_stdio_definitions.lib. È possibile impostare questa libreria nella finestra di dialogo Pagine delle proprietà in Proprietà di configurazione>Linker>Input nella proprietà Dipendenze aggiuntive. Se si collega a Windows SDK 8.1 o versioni precedenti, aggiungere legacy_stdio_definitions.lib.

Se l'errore riguarda argomenti della stringa di formato, è probabile che il compilatore applichi lo standard in modo più restrittivo. Per altre informazioni, vedere la cronologia delle modifiche. Prestare particolare attenzione a eventuali errori in questa fase, in quanto possono rappresentare rischi per la sicurezza.

Errori causati dalle modifiche apportate allo standard C++

Lo standard C++ si è evoluto in modi che non sono sempre compatibili con le versioni precedenti. C++11 ha introdotto la semantica di spostamento, le nuove parole chiave e altre funzionalità della libreria standard e del linguaggio. Queste modifiche possono potenzialmente causare errori del compilatore e anche un comportamento di runtime diverso.

Ad esempio, un programma C++ precedente potrebbe includere l'intestazione iostream.h . Questa intestazione è stata deprecata nelle prime versioni di C++ e alla fine è stata completamente rimossa da Visual Studio. In questo caso, è necessario usare <iostream> e riscrivere il codice. Per altre informazioni, vedere Aggiornamento del codice precedenteiostream.

C4838: avviso di conversione verso un tipo di dati più piccolo

Lo standard C++ specifica ora che le conversioni da valori integrali senza segno a valori integrali con segno stanno restringendo le conversioni. Il compilatore non ha generato questo avviso prima di Visual Studio 2015. Esaminare ogni occorrenza per assicurarsi che la riduzione non influisca sulla correttezza del codice.

Avvisi per l'uso di funzioni CRT protette

Nel corso degli anni sono state introdotte versioni sicure delle funzioni runtime C. Le versioni precedenti e non sicure sono ancora disponibili, ma è consigliabile modificare il codice per usare le versioni sicure. Il compilatore genererà un avviso se si usano versioni non sicure. È possibile scegliere di disabilitare o ignorare questi avvisi. Per disabilitare l'avviso per tutti i progetti nella soluzione, aprire Visualizza>Gestione proprietà, selezionare tutti i progetti per i quali disabilitare l'avviso, quindi fare clic con il pulsante destro del mouse sugli elementi selezionati e scegliere Proprietà. Nella finestra di dialogo Pagine delle proprietà in Proprietà di configurazione>C/C++>Avanzate, selezionare Disabilita avvisi specifici. Scegliere la freccia a discesa e quindi scegliere Modifica. Immettere 4996 nella casella di testo. Non includere il prefisso 'C'. Per altre informazioni, vedere Conversione per l'uso di Secure CRT.

Errori causati dalle modifiche apportate alle API di Windows o agli SDK obsoleti

Nel corso degli anni sono stati aggiunti (e talvolta modificati o rimossi) tipi di dati e API di Windows. Inoltre, altri SDK che non appartengono al sistema operativo principale sono venuti e sono andati. I programmi meno recenti possono contenere chiamate alle API che non esistono più. Possono anche contenere chiamate alle API in altri SDK Microsoft non più supportati. Potrebbero verificarsi errori relativi alle API o alle API Di Windows mancanti dagli SDK Microsoft meno recenti. È possibile che le API siano state rimosse o sostituite da funzioni più recenti e più sicure.

La documentazione dell'API Windows elenca i sistemi operativi minimi o massimi supportati. Per informazioni su un'API Windows specifica, cercarla nell'indice API per le applicazioni Desktop di Windows.

Versione di Windows

Quando si aggiorna un programma che usa l'API Windows direttamente o indirettamente, è necessario decidere la versione minima di Windows da supportare. Nella maggior parte dei casi Windows 7 è una scelta ottimale. Per altre informazioni, vedere Problemi del file di intestazione. La macro WINVER definisce la versione meno recente di Windows nella quale è possibile eseguire il programma. Se il programma MFC imposta WINVER su 0x0501 (Windows XP) verrà visualizzato un avviso perché MFC non supporta più XP, anche se il set di strumenti del compilatore ha una modalità XP. Il supporto del set di strumenti del compilatore per Windows XP è terminato in Visual Studio 2017.

Per altre informazioni, vedere Aggiornamento della versione di Windows di destinazione e Altri file di intestazione obsoleti.

ATL/MFC

ATL e MFC sono API relativamente stabili, ma anch'esse vengono modificate occasionalmente. Per altre informazioni, vedere Cronologia modifiche di Visual C++ 2003 - 2015, Novità di Visual C++ in Visual Studio e Miglioramenti della conformità C++ in Visual Studio.

LNK 2005 _DllMain@12 già definito in MSVCRTD.lib

Questo errore può verificarsi nelle applicazioni MFC. Indica un problema di ordinamento tra la libreria CRT e la libreria MFC. MFC deve essere prima collegato in modo che new fornisca operatori e delete . Per correggere l'errore, usare l'opzione /NODEFAULTLIB Ignora queste librerie predefinite: MSVCRTD.lib e mfcs140d.lib. Aggiungere quindi queste stesse librerie come dipendenze aggiuntive.

32 bit e 64 bit

Se il codice originale viene compilato per i sistemi a 32 bit, è possibile creare una versione a 64 bit anziché (o oltre a) una nuova app a 32 bit. In genere è consigliabile completare la compilazione del programma in modalità a 32 bit, quindi provare a eseguire la compilazione a 64 bit. La compilazione in modalità a 64 bit è semplice, ma in alcuni casi evidenzia bug che non apparivano nelle build a 32 bit.

È inoltre necessario tenere presente i possibili problemi in fase di compilazione e di runtime relativi alle dimensioni del puntatore, ai valori di tempo e alle dimensioni e agli identificatori di formato specifici delle dimensioni in printf e scanf delle funzioni. Per altre informazioni, vedere Configurare Visual C++ per 64 bit, destinazioni x64 e Problemi comuni di migrazione a 64 bit di Visual C++. Per altri suggerimenti sulla migrazione, vedere Guida alla programmazione per Windows a 64 bit.

Unicode e MBCS/ASCII

Prima della standardizzazione di Unicode, molti programmi usavano il set di caratteri multibyte (MBCS) per rappresentare i caratteri non inclusi nel set di caratteri ASCII. Nei progetti MFC meno recenti, MBCS era l'impostazione predefinita. Quando si aggiorna un programma di questo tipo, verranno visualizzati avvisi che consigliano di usare Unicode. Se si decide che la conversione in Unicode non vale il costo di sviluppo, è possibile scegliere di disabilitare o ignorare l'avviso. Per disabilitare l'avviso per tutti i progetti nella soluzione, aprire Visualizza>Gestione proprietà, selezionare tutti i progetti per i quali disabilitare l'avviso, quindi fare clic con il pulsante destro del mouse sugli elementi selezionati e scegliere Proprietà. Nella finestra di dialogo Pagina delle proprietà selezionare Proprietà di configurazione>C/C++>Avanzate. Nella proprietà Disabilita avvisi specifici fare clic sulla freccia a discesa, quindi scegliere Modifica. Immettere 4996 nella casella di testo. Non includere il prefisso 'C'. Scegliere OK per salvare la proprietà, quindi scegliere OK per salvare le modifiche.

Per altre informazioni, vedere Porting da MBCS a Unicode. Per informazioni generali su MBCS e Unicode, vedere Testo e stringhe in Visual C++ e Internazionalizzazione .

Vedi anche

Aggiornamento di progetti da versioni precedenti di Visual C++
Miglioramenti della conformità di C++ in Visual Studio