Visual Studio 2010 - LINK : fatal error LNK1181: cannot open input file " ■/.obj"

I have VS 2010 on Windows 7. I create a new project, chose c++ language, Win32 project, DLL, Export symbols, then fin开发者_运维百科ish. Now when I compile the project without any changes to what VS generates, I get...

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

I also have VS 2008 install on the same machine. I follow the same steps and it compiles. What am I doing wrong?

Edit Okay, I've discovered that this error is due to an old version of the linker being used. I am not sure why. In VS2010, the project directories are set differently than in VS2008. Once I figure that out, maybe I can solve my own problem.

Well it has been a while since posting this questions. I figured out a workaround awhile ago, so now I am going to answer it myself. But if you have any better ideas or additional info others could benefit from, please post.

I found that after creating my C++ project, I need to remove the "Microsoft.Cpp.Win32.User" property sheets. If I don't, then I get the strange error above, but if I delete them, the simple project compiles fine. To delete them...

1. Select View->Other Windows->Propery Manager
2. Expand the property group (the name of your project)
3. Expand all configurations (mine are "Debug|Win32" and "Release|Win32")
4. Multi-select all "Microsoft.Cpp.Win32.User" property sheets (one under each configuration)
5. Delete

Visual Studio 2012 - LINK : fatal error LNK1181: cannot open input file “ ■/.obj” I'm using VS 2012!!!!

I have tracked this down a bit more. For me, this does NOT happen when I try to build the x64 bit version of my application. I have found that my project .vcxproj has an 'ImportGroup Condition' that looks like this:

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

I also have one for my x64 build that looks like this:

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

So I took a look at the files:

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

The difference is that the of each is different. x64 is basically empty while Win32 has three paths in it.

The section of the Win32 version, contains three paths, <ExecutablePath>, <IncludePath>, and <LibraryPath>.

I HAVE FOUND that removing the <ExecutablePath> path causes this problem to go away. I am looking deeper into that path to see if anything pops out at me, but I thought I'd pass it along in case any others can find what is wrong with that path.

Me too came across the same problem while compiling a VC++ project in Visual Studio 2017. The compiler complained the following.

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

Up on analyzing the issue, it is found that project "Configuration Properties - VC++ Directories - Executable Directories" as shown below contained a path to Microsoft Visual Basic folder C:\Program Files (x86)\Microsoft Visual Studio\VB98 which has its own link.exe.

The linker error occurred due to the fact that Visual Studio was invoking Visual Basic linker rather than Visual C++ linker!

This happened because path to Visual Basic linker is listed first in the above dialog and hence Visual Studio encountered Visual Basic linker.exe first while going through path to Executable Directories.

One of the solution is to update order of inclusion of path in Executable Directories by moving path to VB98 folder from first to last. It can be achieved by editing required property file(s) such as Microsoft.Cpp.Win32.user.props present in $(USERPROFILE)\appdata\local\microsoft\msbuild\v4.0 directory.

In my case (VS 2017), I had to delete the following entries in Linker -> Additional dependencies:

\
$(INHERIT)\

Possibly added by Qt pre-processor.