Información general sobre posibles problemas de actualización (Visual C++)

A lo largo de los años, el Compilador de Microsoft C++ ha experimentado numerosos cambios, como los introducidos en el propio lenguaje C++, la biblioteca estándar de C++, el entorno de ejecución de C (CRT) y otras bibliotecas como MFC y ATL. Como resultado, al actualizar una aplicación desde una versión anterior de Visual Studio, es posible que se produzcan errores del compilador y el enlazador, y se generen advertencias en el código que antes se compilaba correctamente. Cuanto más antiguo sea el código base original, más probable es que se produzcan dichos errores. En esta introducción, se resumen las clases de problemas más comunes que pueden aparecer y se proporcionan vínculos a información más detallada.

Nota:

Antes recomendábamos que las actualizaciones que abarcaban varias versiones de Visual Studio se realizasen de forma incremental de una en una. pero ya no se recomienda este método. Hemos detectado que casi siempre es más fácil actualizar a la versión más reciente de Visual Studio, independientemente de la antigüedad del código base.

Si tiene preguntas o comentarios sobre el proceso de actualización, puede enviarlos a vcupgrade@microsoft.com.

Dependencias de biblioteca y conjunto de herramientas

Nota:

Esta sección es válida para las aplicaciones y bibliotecas compiladas con Visual Studio 2013 y versiones anteriores. Los conjuntos de herramientas que se usan en Visual Studio 2015, Visual Studio 2017 y Visual Studio de 2019 tienen compatibilidad binaria. Para obtener más información, consulte Compatibilidad binaria de C++ entre versiones de Visual Studio.

Al actualizar una aplicación de Visual Studio 2013 o anterior a una versión más reciente, a menudo es aconsejable y necesario actualizar todas las bibliotecas y archivos DLL a los que enlaza la aplicación. Debe tener acceso al código fuente o el proveedor de la biblioteca debe proporcionar nuevos archivos binarios compilados con la misma versión principal del compilador. Si se cumple alguna de estas condiciones, puede omitir esta sección, que trata sobre los detalles de la compatibilidad binaria. Si no es ninguno de los dos casos, es posible que las bibliotecas no funcionen en la aplicación actualizada. La información incluida en esta sección le ayudará a comprender si puede continuar con la actualización.

Conjunto de herramientas

Los formatos de archivo .obj y .lib están bien definidos y cambian con poca frecuencia. A veces se realizan adiciones a estos formatos de archivo, pero no suelen afectar a la capacidad de los conjuntos de herramientas más recientes de consumir los archivos objeto y las bibliotecas que los conjuntos de herramientas anteriores producen. La excepción principal se produce si se efectúa la compilación con /GL (Optimización de todo el programa). Si realiza la compilación con /GL, solo puede enlazar el archivo objeto resultante con el mismo conjunto de herramientas que se haya usado para crearlo. Por lo tanto, si produce un archivo objeto con /GL y usa el compilador de Visual Studio 2017 (v141), deberá enlazarlo con el enlazador de Visual Studio 2017 (v141). Esto se debe a que las estructuras de datos internas de los archivos objeto no son estables entre distintas versiones principales del conjunto de herramientas. Los conjuntos de herramientas más recientes no comprenden los formatos de datos más antiguos.

C++ no tiene una interfaz binaria de aplicaciones (ABI) estable, pero Visual Studio mantiene una ABI de C++ estable para todas las versiones secundarias de una versión. Los conjuntos de herramientas de Visual Studio 2015 (v140), Visual Studio 2017 (v141), Visual Studio 2019 (v142) y Visual Studio 2022 (v143) varían únicamente en su versión secundaria. Todas tienen el mismo número de versión principal, que es 14. Para obtener más información, consulte Compatibilidad binaria de C++ entre versiones de Visual Studio.

Si dispone de un archivo objeto con símbolos externos y vinculación de C++, dicho archivo objeto podría no estar vinculado correctamente a los archivos objeto generados mediante otra versión principal del conjunto de herramientas. Existen muchos resultados posibles: el enlace podría no funcionar en absoluto (por ejemplo, si se cambia la decoración del nombre). El enlace podría realizarse correctamente, pero la aplicación podría producir un error en tiempo de ejecución (por ejemplo, si han cambiado los diseños de tipo). O bien, es posible que la aplicación siga funcionando y que nada vaya mal. Además, tenga en cuenta que, aunque la ABI de C++ no es estable, la ABI de C y el subconjunto de la ABI de C++ requeridos para COM son estables.

Si establece un vínculo con una biblioteca de importación, las versiones posteriores de las bibliotecas redistribuibles de Visual Studio que conserven la compatibilidad con ABI se podrán usar en el entorno de ejecución. Por ejemplo, si compila y enlaza la aplicación mediante el conjunto de herramientas de Visual Studio 2015 Actualización 3, puede usar cualquier elemento redistribuible posterior. Esto se debe a que las bibliotecas de 2015, 2017, 2019 y 2022 han conservado la compatibilidad binaria con versiones anteriores. El caso contrario no es cierto: no puede usar un elemento redistribuible para una versión anterior del conjunto de herramientas a la que haya utilizado para compilar los componentes del código.

Bibliotecas

Si utiliza #include con una versión determinada de los archivos de encabezado, debe enlazar el archivo objeto resultante a la misma versión de las bibliotecas. Por ejemplo, si el archivo fuente incluye el archivo <immintrin.h> de Visual Studio 2015 Actualización 3, debe enlazarlo con la biblioteca vcruntime de Visual Studio 2015 Actualización 3. Del mismo modo, si el archivo fuente incluye el archivo <iostream> de la versión 15.5 de Visual Studio 2017, debe enlazarlo con la biblioteca estándar de C++ de la versión 15.5 de Visual Studio 2017, msvcprt. No se admite mezclar y combinar.

En el caso de la biblioteca estándar de C++, se ha deshabilitado explícitamente la opción de mezclar y combinar mediante el uso de #pragma detect_mismatch en los encabezados estándar a partir de Visual Studio 2010. Si intenta enlazar archivos objeto incompatibles, o si los enlaza con una biblioteca estándar incorrecta, se producirá un error en el enlace.

Las versiones anteriores de CRT que mezclaban y combinaban nunca se admitieron, pero a menudo funcionaban porque la superficie de la API no cambió mucho con el tiempo. CRT universal interrumpió la compatibilidad con versiones anteriores para que en el futuro podamos mantener la compatibilidad con versiones anteriores. No tenemos pensado introducir en el futuro archivos binarios nuevos de CRT universal con versiones. En su lugar, hemos actualizado en contexto CRT universal.

Para proporcionar compatibilidad de enlace parcial con archivos objeto (y bibliotecas) compilados con versiones anteriores de los encabezados del entorno de ejecución de Microsoft C, proporcionamos una biblioteca (legacy_stdio_definitions.lib) con Visual Studio 2015 y versiones posteriores. Esta biblioteca proporciona símbolos de compatibilidad para la mayoría de las funciones y exportaciones de datos que se quitaron de CRT universal. El conjunto de símbolos de compatibilidad proporcionado por legacy_stdio_definitions.lib es suficiente para satisfacer la mayoría de las dependencias, incluidas todas las dependencias de bibliotecas incluidas en Windows SDK. Sin embargo, algunos símbolos se quitaron del CRT universal que no tiene símbolos de compatibilidad. Estos símbolos incluyen algunas funciones (por ejemplo, __iob_func) y algunas exportaciones de datos (por ejemplo, __imp___iob, __imp___pctype y __imp___mb_cur_max).

Si tiene una biblioteca estática que se ha compilado con una versión anterior de los encabezados del entorno de ejecución de C, se recomiendan las acciones siguientes (en este orden):

1. Recompile la biblioteca estática con la nueva versión de Visual Studio y los encabezados de CRT universal para admitir la vinculación con CRT universal. Este enfoque es totalmente compatible y la mejor opción.

2. Si no puede (o no quiere) recompilar la biblioteca estática, puede intentar enlazarla con legacy_stdio_definitions.lib. Si satisface las dependencias en tiempo de enlazado de su biblioteca estática, querrá probar a fondo la biblioteca estática ya que se utiliza en el archivo binario. Asegúrese de que no se vea afectada negativamente por ninguno de los cambios de comportamiento realizados en CRT universal.

3. Quizás legacy_stdio_definitions.lib no satisface las dependencias de la biblioteca estática o la biblioteca no funciona con CRT universal debido a los cambios de comportamiento. En este caso, se recomienda encapsular la biblioteca estática en un archivo DLL que enlace con la versión necesaria del entorno de ejecución de Microsoft C. Por ejemplo, si la biblioteca estática se compiló con Visual Studio 2013, compile también este archivo DLL con el conjunto de herramientas y las bibliotecas de C++ de Visual Studio 2013. Al compilar la biblioteca en una DLL, encapsula el detalle de implementación que es su dependencia en una versión determinada del tiempo de ejecución de Microsoft C. Tenga cuidado de que la interfaz DLL no filtre detalles del entorno de ejecución de C que usa, por ejemplo, si devuelve un elemento FILE* en el límite del archivo DLL o un puntero asignado por malloc que el autor de la llamada deba liberar (usar free).

El uso de varios CRT en un único proceso no es problemático por sí mismo. (De hecho, la mayoría de los procesos cargan varios archivos DLL de CRT. Por ejemplo, los componentes del sistema operativo Windows dependen de msvcrt.dll y CLR depende de su propio CRT privado). Los problemas surgen cuando se mezcla el estado de los diferentes CRT. Por ejemplo, no debe asignar memoria mediante msvcr110.dll!malloc e intentar desasignarla mediante msvcr120.dll!free, y no debe intentar abrir un archivo con msvcr110!fopen e intentar leer desde ese archivo mediante msvcr120!fread. Mientras no mezcle el estado de diferentes CRT, puede cargar de forma segura varios CRT en un único proceso.

Para obtener más información, vea Upgrade your code to the Universal CRT (Actualizar código a CRT universal).

Errores causados por la configuración del proyecto

Para comenzar el proceso de actualización, abra un proyecto, solución o área de trabajo antiguos en la versión más reciente de Visual Studio. Visual Studio creará un proyecto nuevo basado en la configuración del proyecto antiguo. Compruebe si el proyecto anterior tiene rutas de acceso de biblioteca o incluye rutas de acceso codificadas de forma rígida en ubicaciones no estándar. Es posible que los archivos de esas rutas de acceso no sean visibles para el compilador cuando el proyecto utiliza la configuración predeterminada. Para obtener más información, vea Configuración de OutputFile del vinculador.

En general, ahora es un buen momento para organizar el código del proyecto a fin de simplificar el mantenimiento del proyecto y ayudar a compilar el código actualizado de la manera más rápida posible. Si el código fuente ya está bien organizado y el proyecto antiguo está compilado con Visual Studio 2010 o versiones posteriores, puede editar manualmente el archivo del proyecto nuevo para admitir la compilación en el compilador antiguo y en el nuevo. En el ejemplo siguiente se muestra cómo se compila para Visual Studio 2015 y Visual Studio 2017:

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

LNK2019: externo sin resolver

En el caso de los símbolos sin resolver, es posible que tenga que corregir la configuración del proyecto.

• Si el archivo de código fuente se encuentra en una ubicación no predeterminada, ¿ha agregado la ruta de acceso a los directorios de inclusión del proyecto?

• Si el externo está definido en un archivo .lib, ¿ha especificado la ruta de acceso del archivo .lib en las propiedades del proyecto y se encuentra allí la versión correcta del archivo .lib?

• ¿Está intentando enlazar a un archivo .lib compilado con una versión diferente de Visual Studio? Si es así, consulte la sección anterior sobre las dependencias de biblioteca y de conjunto de herramientas.

• ¿Coinciden realmente los tipos de los argumentos en el sitio de llamada con una sobrecarga existente de la función? Compruebe que los tipos subyacentes sean los esperados, tanto en las definiciones de tipo de la firma de la función como en el código que llama a la función.

Para solucionar errores de símbolos sin resolver, puede usar dumpbin.exe para examinar los símbolos definidos en un archivo binario. Pruebe la siguiente línea de comandos para ver los símbolos definidos en una biblioteca:

dumpbin.exe /LINKERMEMBER somelibrary.lib

/Zc:wchar_t (wchar_t es de tipo nativo)

(En Microsoft Visual C++ 6.0 y versiones anteriores, wchar_t no estaba implementado como un tipo integrado. Se declaraba en wchar.h como una definición de tipo para unsigned short). El estándar de C++ requiere que wchar_t sea un tipo integrado. Si usa la versión de definición de tipo, pueden producirse problemas de portabilidad. Si realiza la actualización desde versiones anteriores de Visual Studio y aparece un error C2664 del compilador porque el código intenta convertir implícitamente un tipo wchar_t a unsigned short, se recomienda cambiar el código para corregir el error, en lugar de establecer /Zc:wchar_t-. Para más información, consulte /Zc:wchar_t (wchar_t es de tipo nativo).

Actualización con las opciones /NODEFAULTLIB, /ENTRY y /NOENTRY del enlazador

La opción /NODEFAULTLIB del enlazador (o la propiedad del enlazador Omitir todas las bibliotecas predeterminadas) indica al enlazador que no enlace automáticamente las bibliotecas predeterminadas, como CRT. Esto significa que cada biblioteca tiene que aparecer como entrada individual. Esta lista de bibliotecas se proporciona en la propiedad Dependencias adicionales en la sección Enlazador del cuadro de diálogo Propiedades del proyecto.

Los proyectos que usan esta opción presentan un problema al actualizar, ya que el contenido de algunas de las bibliotecas predeterminadas se ha refactorizado. Dado que cada biblioteca tiene que aparecer en la propiedad Dependencias adicionales o en la línea de comandos del enlazador, deberá actualizar la lista de bibliotecas para que use todos los nombres actuales.

En la siguiente tabla se muestran las bibliotecas cuyo contenido ha cambiado a partir de Visual Studio 2015. Para actualizar, debe agregar los nuevos nombres de biblioteca de la segunda columna a las bibliotecas de la primera columna. Algunas de las bibliotecas son bibliotecas de importación, pero esto no debe importar.

Si usaba:	Debe usar estas bibliotecas:
libcmt.lib	libcmt.lib, libucrt.lib, libvcruntime.lib
libcmtd.lib	libcmtd.lib, libucrtd.lib, libvcruntimed.lib
msvcrt.lib	msvcrt.lib, ucrt.lib, vcruntime.lib
msvcrtd.lib	msvcrtd.lib, ucrtd.lib, vcruntimed.lib

El mismo problema se aplica si usa la opción /ENTRY o la opción /NOENTRY, que también permiten omitir las bibliotecas predeterminadas.

Errores causados por la conformidad mejorada del lenguaje

El Compilador de Microsoft C++ ha mejorado continuamente su conformidad con el estándar de C++ a lo largo de los años. El código que se compiló en versiones anteriores podría no compilarse en versiones posteriores de Visual Studio. Esto se debe a que el compilador marca correctamente un error que antes ignoraba o permitía explícitamente.

Por ejemplo, el modificador /Zc:forScope se introdujo en las primeras versiones de MSVC. Permite un comportamiento no conforme para las variables de bucle. Este modificador ahora está en desuso y podría quitarse en versiones futuras. Se recomienda no usar ese modificador al actualizar el código. Para obtener más información, consulte /Zc:forScope- está en desuso.

Por ejemplo, es habitual que aparezca un error del compilador al actualizar cuando se pasa un argumento que no es const a un parámetro const. Las versiones antiguas del compilador no siempre lo marcaban como error. Para obtener más información, vea Las conversiones más estrictas del compilador.

Para obtener más información sobre mejoras de conformidad específicas, vea Historial de cambios en Visual C++ 2003-2015 y C++ conformance improvements in Visual Studio (Mejoras de conformidad de C++ en Visual Studio).

Errores relacionados con tipos enteros de <stdint.h>

El encabezado <stdint.h> define definiciones de tipos y macros que, a diferencia de los tipos enteros integrados, tienen una longitud específica garantizada en todas las plataformas. Algunos ejemplos son uint32_t y int64_t. El encabezado <stdint.h> se agregó en Visual Studio 2010. El código que se escribió antes de 2010 podría haber proporcionado definiciones privadas para esos tipos. Además, es posible que esas definiciones no siempre sean coherentes con las definiciones de <stdint.h>.

Si el error es C2371 y está implicado un tipo de stdint, probablemente significa que el tipo está definido en un encabezado, ya sea en el código o en un archivo de biblioteca de terceros. Al actualizar, debe eliminar todas las definiciones personalizadas de tipos de <stdint.h>, pero primero compare las definiciones personalizadas con las definiciones estándar actuales para asegurarse de que no incorpora nuevos problemas.

Puede pulsar F12 (Ir a definición) para ver dónde está definido el tipo en cuestión.

La opción del compilador /showIncludes puede resultar útil en este caso. En el cuadro de diálogo Páginas de propiedades del proyecto, seleccione la página Propiedades de configuración>C/C++>Avanzado y establezca Mostrar inclusiones en Sí. A continuación, recompile el proyecto. Verá la lista de archivos #include en la ventana de salida. Se aplica sangría a cada encabezado bajo el encabezado que lo incluye.

Errores relacionados con funciones de CRT

A lo largo de los años, se han realizado muchos cambios en el tiempo de ejecución de C. Se han agregado muchas versiones seguras de funciones y algunas se han quitado. Además, como se ha descrito anteriormente en este artículo, la implementación de CRT por parte de Microsoft se ha refactorizado en Visual Studio 2015 en nuevos archivos binarios y archivos .lib asociados.

Si un error está relacionado con una función de CRT, vea Historial de cambios en Visual C++ 2003-2015 o C++ conformance improvements in Visual Studio (Mejoras de conformidad de C++ en Visual Studio) para ver si los artículos contienen información adicional. Si el error es LNK2019, asegúrese de que no se haya quitado la función. De lo contrario, si está seguro de que la función todavía existe y el código que realiza la llamada es correcto, compruebe si el proyecto usa /NODEFAULTLIB. Si es así, debe actualizar la lista de bibliotecas para usar las nuevas bibliotecas universales (UCRT). Para más información, vea la sección anterior sobre la biblioteca y las dependencias.

Si el error está relacionado con printf o scanf, asegúrese de no definir de manera privada alguna función sin incluir stdio.h. Si es así, quite las definiciones privadas o enlace a legacy_stdio_definitions.lib. Puede configurar esta biblioteca en el cuadro de diálogo Páginas de propiedades, en Propiedades de configuración>Enlazador>Entrada, en la propiedad Dependencias adicionales. Si enlaza con Windows SDK 8.1 o versiones anteriores, agregue legacy_stdio_definitions.lib.

Si el error está relacionado con argumentos de cadena de formato, se trata probablemente de que el compilador es más estricto a la hora de aplicar el estándar. Para más información, vea el historial de cambios. Preste mucha atención a los errores que se produzcan, ya que pueden representar un riesgo de seguridad.

Errores debidos a cambios en el estándar de C++

El estándar de C++ en sí mismo ha evolucionado de maneras que no siempre son compatibles con versiones anteriores. C++11 introdujo semántica de transferencia de recursos, nuevas palabras clave y otras características de biblioteca estándar y de lenguaje. Estos cambios pueden provocar errores del compilador e incluso un comportamiento diferente del entorno de ejecución.

Por ejemplo, un programa de C++ antiguo podría incluir el encabezado iostream.h. Este encabezado quedó en desuso en las primeras versiones de C++ y, finalmente, se eliminó por completo de Visual Studio. En este caso, debe usar <iostream> y volver a escribir el código. Para obtener más información, consulte Actualización del código antiguo de iostream.

C4838: advertencia de conversión de restricción

Ahora, el estándar de C++ especifica que las conversiones de valores enteros sin signo a con signo son conversiones de restricción. El compilador no emitía esta advertencia en versiones anteriores a Visual Studio 2015. Inspeccione cada aparición para asegurarse de que la restricción no afecta a la corrección del código.

Advertencias para usar funciones de CRT seguras

A lo largo de los años, se han introducido versiones seguras de funciones de tiempo de ejecución de C. Aunque las versiones no seguras antiguas siguen estando disponibles, se recomienda que cambie el código para usar las versiones seguras. El compilador emitirá una advertencia del uso de versiones no seguras. Puede decidir deshabilitar u omitir estas advertencias. Para deshabilitar la advertencia en todos los proyectos de la solución, abra Ver>Administrador de propiedades, seleccione los proyectos, haga clic con el botón derecho en los elementos seleccionados y elija Propiedades. En el cuadro de diálogo Páginas de propiedades, en Propiedades de configuración>C/C++>Avanzadas, seleccione Deshabilitar advertencias específicas. Elija la flecha desplegable y, a continuación, elija Editar. Escriba 4996 en el cuadro de texto. (No incluya el prefijo "C"). Para obtener más información, consulte Migración para usar CRT seguro.

Errores debidos a cambios en las API de Windows o SDK obsoletos

A lo largo de los años, se han agregado API de Windows y tipos de datos y, a veces, se han cambiado o eliminado. Además, han aparecido y desaparecido otros SDK que no pertenecían al sistema operativo principal. Los programas antiguos pueden contener llamadas a API que ya no existen. También pueden contener llamadas a las API de otros SDK de Microsoft que ya no son compatibles. Podría ver errores sobre las API de Windows que faltan o las API de los SDK de Microsoft anteriores. Es posible que las API se hayan quitado o reemplazado por funciones más recientes y seguras.

En la documentación de la API de Windows, se enumeran los sistemas operativos mínimos o máximos admitidos. Para obtener información sobre una API de Windows específica, búsquela en el Índice de API para aplicaciones Windows de escritorio.

Versión de Windows

Al actualizar un programa que usa la API de Windows directa o indirectamente, debe decidir la versión mínima de Windows con la que es compatible. En la mayoría de los casos, Windows 7 es una buena elección. Para más información, vea Problemas de archivos de encabezado. La macro WINVER define la versión de Windows más antigua en la que puede ejecutarse el programa. Si el programa MFC establece WINVER en 0x0501 (Windows XP), obtendrá una advertencia porque MFC ya no admite XP, aunque el conjunto de herramientas del compilador tenga un modo XP. La compatibilidad del conjunto de herramientas del compilador con Windows XP finalizó en Visual Studio 2017.

Para obtener más información, consulte Actualización de la versión de Windows de destino y Más archivos de encabezado obsoletos.

ATL/MFC

ATL y MFC son API relativamente estables, pero en ocasiones se realizan cambios. Para más información, consulte Historial de cambios en Microsoft C/C++ de 2003 a 2015, Novedades de C++ en Visual Studio 2022 y Mejoras en la conformidad de C++, cambios de comportamiento y correcciones de errores en Visual Studio 2022.

LNK 2005 _DllMain@12 ya definido en MSVCRTD.lib

Este error puede producirse en las aplicaciones MFC. Indica un problema de ordenación entre la biblioteca CRT y la biblioteca MFC. Se debe enlazar primero MFC para que proporcione los operadores new y delete. Para corregir el error, use el modificador /NODEFAULTLIB para omitir estas bibliotecas predeterminadas: MSVCRTD.lib y mfcs140d.lib. Después, agregue estas mismas bibliotecas como dependencias adicionales.

32 bits frente a 64 bits

Si el código original está compilado para sistemas de 32 bits, tiene la opción de crear una versión de 64 bits en lugar de (o además de) una aplicación nueva de 32 bits. En general, debe hacer que el programa compile primero en modo de 32 bits y, después, intentarlo en 64 bits. La compilación para 64 bits es sencilla, pero en algunos casos puede revelar errores que estaban ocultos en las compilaciones de 32 bits.

Además, debe ser consciente de los posibles problemas en tiempo de compilación y en tiempo de ejecución relacionados con el tamaño del puntero, los valores de tiempo y tamaño, y los especificadores de formato específicos del tamaño en las funciones printf y scanf. Para obtener más información, consulte Configuración de proyectos de C++ para destinos x64 de 64 bits y Problemas comunes de migración a 64 bits en Visual C++. Para obtener más sugerencias de migración, consulte Guía de programación para Windows de 64 bits.

Unicode frente a MBCS/ASCII

Antes de que se estandarizase Unicode, muchos programas usaban el juego de caracteres multibyte (MBCS) para representar los caracteres que no estaban incluidos en el juego de caracteres ASCII. En proyectos de MFC anteriores, MBCS era la configuración predeterminada. Al actualizar este tipo de programa, verá advertencias que aconsejan usar Unicode en su lugar. Puede deshabilitar o ignorar la advertencia si decide que la conversión a Unicode es un costo de desarrollo que no merece la pena. Para deshabilitarla en todos los proyectos de la solución, abra Ver>Administrador de propiedades, seleccione todos los proyectos, haga clic con el botón derecho en los elementos seleccionados y elija Propiedades. En el cuadro de diálogo Páginas de propiedades, seleccione Propiedades de configuración>C/C++>Avanzadas. En la propiedad Deshabilitar advertencias específicas, abra la flecha desplegable y elija Editar. Escriba 4996 en el cuadro de texto. (No incluya el prefijo "C"). Elija Aceptar para guardar la propiedad y de nuevo Aceptar para guardar los cambios.

Para obtener más información, vea Migrar de MBCS a Unicode. Para obtener información general sobre MBCS frente a Unicode, consulte Texto y cadenas en Visual C++ e Internacionalización.

Consulte también

Actualización de proyectos de C++ desde versiones anteriores de Visual Studio
Mejoras de conformidad de C++ en Visual Studio