Visual Studio 2010 - LINK: error fatal LNK1181: no se puede abrir el archivo de entrada "■/.obj"

Question

Tengo VS 2010 en Windows 7. Creo un nuevo proyecto, escogí el lenguaje C++, proyecto Win32, DLL, Exportar símbolos, luego terminar. Ahora, cuando puedo compilar el proyecto sin ningún cambio en lo que VS genera, lo entiendo ...

LINK: LNK1181 error fatal: puede archivo de entrada no está abierto "■/obj"

también tienen VS 2008 instalar en la misma máquina Sigo los mismos pasos y compila. ¿Qué estoy haciendo mal?

Editar Bien, he descubierto que este error se debe a una versión anterior del vinculador que se utiliza. No estoy seguro por qué. En VS2010, los directorios del proyecto se configuran de manera diferente que en VS2008. Una vez que lo descubra, quizás pueda resolver mi problema.

Answer 1

Bueno, ha pasado un tiempo desde la publicación de estas preguntas. Descubrí una solución hace un tiempo, así que ahora voy a responderla yo mismo. Pero si tiene alguna idea mejor o información adicional de la que otros puedan beneficiarse, envíela.

Descubrí que después de crear mi proyecto C++, necesito eliminar las hojas de propiedades "Microsoft.Cpp.Win32.User". Si no lo hago, entonces obtengo el extraño error anterior, pero si los elimino, el proyecto simple compila bien. Para eliminarlos ...

1. Seleccione Ver-> Otro Windows-> Gestor Propery
2. Expandir el grupo de propiedades (el nombre del proyecto)
3. expandir todas las configuraciones (la mía son "depuración | Win32" y "Release | Win32")
4. de selección múltiple todas las hojas de propiedades "Microsoft.Cpp.Win32.User" (una en cada configuración)
5. Eliminar

Answer 2

Visual Studio 2012 - ENLACE : error fatal LNK1181: no se puede abrir el archivo de entrada "■/.obj" Estoy usando VS 2012 !!!!

He rastreado esto un poco más. Para mí, esto NO ocurre cuando intento crear la versión de mi aplicación de x64 bits. He descubierto que mi proyecto .vcxproj tiene un 'ImportGroup Condición' que tiene este aspecto:

<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="PropertySheets"> 
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> 
    </ImportGroup> 

También tengo una para mi x64 acumulación que tiene este aspecto:

<ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="PropertySheets"> 
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> 
    </ImportGroup> 

Así que tomó una mira los archivos:

Users\??????????\AppData\Local\Microsoft\MSBuild\v4.0 
Microsoft.Cpp.Win32.user.props 
Microsoft.Cpp.x64.user.props 

La diferencia es que la de cada uno es diferente. x64 está básicamente vacío, mientras que Win32 tiene tres rutas.

La sección de la versión de Win32 contiene tres rutas, <ExecutablePath>, <IncludePath> y <LibraryPath>.

HE ENCONTRADO que la eliminación de la ruta <ExecutablePath> hace que este problema desaparezca. Estoy mirando más profundamente en ese camino para ver si aparece algo en mí, pero pensé que podría pasarlo en caso de que otros puedan encontrar lo que está mal en ese camino.

Answer 3

También me encontré con el mismo problema al compilar un proyecto de VC++ en Visual Studio 2017. El compilador se quejó de lo siguiente.

LINK : fatal error LNK1181: cannot open input file " ■/.obj"

arriba en el análisis de la cuestión, se encuentra que el proyecto "Propiedades de configuración - Directorios de VC++ - ejecutables directorios" como se muestra a continuación figura un camino a la carpeta de Microsoft Visual Básico C:\Program Files (x86)\Microsoft Visual Studio\VB98 que tiene su propio link.exe.

El error de vinculador se produjo debido al hecho de que Visual Studio estaba invocando vinculador de Visual Basic en lugar de Visual C++ enlazador!

Esto sucedió porque la ruta al vinculador de Visual Basic aparece primero en el cuadro de diálogo anterior y, por lo tanto, Visual Studio encontró primero el enlace de Visual Basic.exe mientras recorría la ruta a Directorios ejecutables.

Una de la solución es actualizar el orden de inclusión de ruta en ejecutables por Directorios trayectoria de movimiento a partir de la carpeta VB98 primera a última. Se puede lograr editando archivos de propiedades requeridos como Microsoft.Cpp.Win32.user.props presentes en el directorio $(USERPROFILE)\appdata\local\microsoft\msbuild\v4.0.