c++ visual-studio-2010 build

c++ - Resolviendo el problema de reconstrucción de Visual Studio 2010 AlwaysCreate



visual-studio-2010 build (10)

  1. Ver en la ventana de salida qué archivo es reconstruir

  2. Vaya al menú Tools -> Options , luego navegue a Project and Solutions -> Build and Run . Cambie la MSBuild Project build output verbosity a

    Diagnostic

  3. Construir, tengo registro largo

  4. Encuentre el archivo (de 1) en el registro, lea el diagnóstico. Puede encontrar, por ejemplo, el nombre del encabezado que tiene fecha en el futuro o ausente.

Tengo un proyecto de C ++ que actualmente estoy portando de VS2008 a VS2010. Cuando compilo el proyecto, Visual Studio 2010 informa que la compilación es exitosa, pero si luego presiono F5 para iniciar el depurador, me dicen que el proyecto no está actualizado. Si ignoro esta advertencia, puedo continuar con la depuración, pero si presiono, todo el proyecto (muchos cientos de archivos de origen) se reconstruye desde cero. La salida contiene lo siguiente;

1>------ Build started: Project: SCCW-VC2010, Configuration: Debug Win32 ------ 1>Build started 15/11/2010 14:47:40. 1>InitializeBuildStatus: 1> Creating "Debug/SCCW-VC2010.unsuccessfulbuild" because "AlwaysCreate" was specified. 1>Midl: 1> All outputs are up-to-date. 1>ClCompile: 1> tinedit.cpp 1> _WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h) 1> Automatically linking with sfl504d.lib 1> Automatically linking with ot1104d.lib 1>c:/program files/rogue wave/stingray studio 10.4/include/toolkit/sectndlg.h(134): warning C4996: ''strcpy'': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. 1> c:/program files/microsoft visual studio 10.0/vc/include/string.h(105) : see declaration of ''strcpy'' 1> Automatically linking with og1204d.lib 1> Automatically linking with RWUXThemeD10.lib 1> profile.cpp 1> ZOffsetDialog.cpp

Media hora más tarde, una vez finalizada la compilación, se inicia el depurador. Mi conjetura es que el mensaje

Creando "Debug / SCCW-VC2010.unsuccessfulbuild" porque se especificó "AlwaysCreate".

es parte del problema, pero no puedo vincular esto a la configuración de un proyecto. He encontrado ayuda en google , pero nada que haya funcionado hasta ahora. ¿Alguien más tuvo este problema y sabe de una solución?

Edición: De acuerdo con la sugerencia de Jalf en los comentarios a continuación, he creado un nuevo proyecto, he importado todos mis archivos a ese proyecto y el nuevo proyecto tiene los mismos problemas. Específicamente, copié sobre todos los siguientes grupos;

<ClCompile Include="../MyDir/MyFile.cpp"/> <ClInclude Include="../MyDir/MyFile.h" /> <None Include="res/MyFile.ico" /> (and all similar resources) <Library Include="../MyDir/MyFile.lib" />

Edit2: Después de ir a través de todos los encabezados incluidos, encontré 3 que no existían. Eliminarlos y reconstruir todo en el proyecto original parece haber solucionado el problema. Algunas de las publicaciones del blog que mencionan este problema se refieren a él como un error, y dos días después de un tiempo perdido, tiendo a estar de acuerdo. Gracias por las respuestas y comentarios proporcionados.

Edit3: ¡ Y un día después el problema está de vuelta! Hacer cualquier edición en cualquier archivo en el proyecto una vez más provoca una reconstrucción completa. Según la respuesta de John Dibling, el proyecto incluye algunas bibliotecas estáticas, incluida Stingray. Estoy abandonando el VS2010 y volviendo al VS2008, ya que tengo fechas límite. Para información relacionada, vea los siguientes enlaces;

VS2010 siempre piensa que el proyecto no está actualizado pero nada ha cambiado

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/38c08137-3bb0-4143-b97f-72d077646318

http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx

Edición final El lanzamiento de VS2010 SP1 ha resuelto este problema, y ​​las compilaciones ahora son rápidas y eficientes.

Decidió revisar esto con la versión de lanzamiento de SP1. Volví a crear un nuevo proyecto desde cero, que salió en 81k en comparación con el proyecto anterior actualizado de 1.4 mb que llevaba todo tipo de basura con él. Inicialmente, encontré el mismo problema, pero logré resolverlo de la siguiente manera;

  • Se cambiaron los encabezados precompilados para crear (/ Yc)
  • Compilado un archivo fuente
  • Se cambiaron los encabezados precompilados para usar (/ Yu)
  • Hizo una reconstrucción completa

El siguiente problema que noté fue que cualquier adición de recursos estaba causando una recompilación de todos los archivos que contenían incluyendo resource.h Esto se solucionó usando los consejos del siguiente hilo de conexión de Microsoft y agregando manualmente las siguientes líneas a mi proyecto;

<ItemGroup> <ClNoDependencies Include="Resource.h" /> </ItemGroup>

El enlace se encuentra en uno de los comentarios aquí, pero es fácil pasarlo por alto, así que vuelvo a publicar los pasos básicos aquí desde este enlace: Artículo de MSDN

De hecho, encontré este enlace por mi cuenta, y solo después me di cuenta de que esto ya se mencionó aquí.

1. Since it can be difficult to recover from a damaged devenv.exe.config file, consider copying the file to devenv.exe.config.original before modifying it so you have a backup copy you can revert to if things go awry. 2. Open your VisualStudioInstallFolder/Common7/IDE/devenv.exe.config file. Note this will be in %ProgramFiles(x86)% on 64-bit Windows. 3. Open a text editor with admin privileges. 4. Add this snippet to your devenv.exe.config file just below the <configSections /> block: For Visual Studio 2012 and below... <system.diagnostics> <switches><add name="CPS" value="4" /></switches> </system.diagnostics> For Visual Studio 2013 <system.diagnostics> <switches><add name="CPS" value="Verbose" /></switches> </system.diagnostics> 5. Save the text file.

Uso Visual Studio 2010 + SP1 y ambos fragmentos de código XML parecen funcionar.

Ahora necesita una herramienta que pueda mostrar ventanas DebugOutput como DebugView .

1. Start DebugView 2. Rebuild 3. Build 4. In DebugView window search for the string ‘missing’ or ''not up to date'', better still to save the DebugView log entries and open it in notepad and then search.

En mi caso, pareció ayudar a construir el (los) proyecto (s) de implementación. Los he configurado para que no se construyan cuando presiono F7 sino manualmente. Algunas personas sugieren crear una nueva solución + proyectos, pero esa no es una muy buena opción cuando los proyectos tienen muchos ajustes manuales y reglas de construcción personalizadas.

He tenido este problema muchas veces y siempre fue frustrante. Te diré cuál fue el problema en mi caso, pero primero tengo que preguntarte:

  • ¿Hizo una reconstrucción completa antes de intentar ejecutar la primera vez, o simplemente una reconstrucción?
  • Una vez que hace una reconstrucción completa, ¿le pide una vez más que la reconstrucción si no ha realizado cambios?

El problema en mi caso era algo complejo. Tenía reglas de compilación personalizadas que copia los binarios de Stingray desde su directorio de origen (donde vivían) a un directorio en mi árbol de compilación. Los binarios se marcaron como una dependencia, de modo que se copiaron antes de cada compilación en caso de que se cambiaran.

La dependencia verificada miró las marcas de tiempo de estos archivos para ver cuándo se modificaron. Si blah.lib tuviera una fecha de modificación del pasado diciembre en su directorio de origen, entonces, cuando se copie, tendría la misma fecha de modificación. La dependencia verificada indicaría que "hey este archivo es bastante antiguo, tenemos que reconstruirlo", y luego me preguntaría si quería hacer una reconstrucción completa.

Por un tiempo me las arreglé simplemente diciendo "No", pero al final solucioné el problema cambiando la regla de compilación personalizada para escribir un nuevo archivo de texto después de hacer la copia del archivo. Eso haría que el nuevo archivo de texto fuera la dependencia, y no el archivo blah.lib , y que hiciera feliz al compilador.

Los documentos de MSDN implican que esta propiedad es específica para proyectos de implementación.

findstr /si AlwaysCreate en sus archivos de proyecto findstr /si AlwaysCreate debería mostrarle los culpables si no puede rastrearlos en la GUI.

Sé que esta es una publicación muy, muy antigua, pero para el beneficio de todos los que todavía tienen este problema, decidí publicar mi aporte. porque se especificó "AlwaysCreate" no tiene nada que ver con el proyecto que se está reconstruyendo.

Es al revés. Si usted o Visual Studio deciden reconstruir todo, esto crea la creación del archivo "* .unsuccessfulbuild".

Algún otro problema (generalmente el encabezado que no existe) causará que se reconstruya todo lo que lleva a mostrarse porque se especificó "AlwaysCreate".

"AlwaysCreate" forma parte de la configuración del entorno de compilación de Visual Studio y forma parte del archivo XML Microsoft.CppBuild.targets. Contiene la siguiente línea: Toque AlwaysCreate = "true" Files = "$ (LastBuildUnsuccessful)" /

Si se establece en verdadero, el archivo " .unsuccessfulbuild" siempre se creará independientemente de que la compilación sea exitosa o no. Si se cambia a falso, " .unsuccessfulbuild no se crea. Si es verdadero, el archivo * .unsuccessfulbuild se creará como vacío durante la duración del proceso de compilación y luego se eliminará si la compilación es exitosa. No estoy seguro de por qué se creó este archivo; incluso si la compilación tiene errores, el archivo está vacío pero no se elimina como en el caso de la compilación exitosa.

Posiblemente la existencia de este archivo tenga algún significado conocido solo para el entorno de compilación VS. Si desea jugar con esta configuración, borre la tecla táctil de

Si la fecha del archivo es anormal, se produce ese caso. VS Compiler debe recompilar todos los archivos con fecha futura. - Ejemplo -

Current date : June 30, 2015 File date : July 1, 2015 The file is always compiled during today.

No está relacionado con la directiva AlwaysCreate .

Si no hay razones "legítimas" para la reconstrucción constante (por ejemplo, referencias a archivos de encabezado faltantes), intente eliminar el archivo .sdf la solución (cuando la solución está cerrada, por supuesto) y la reconstrucción. Eso acaba de funcionar para mí.

Tuve el mismo problema en proyectos convertidos y desde cero. Recibí una pista de una página de MS sobre archivos perdidos. Revisé mi proyecto y encontré que hacía referencia a un archivo que no existía. Lo reemplazó con el archivo correcto, y el problema desapareció.