How to set $(OutDir), $(TargetName), $(TargetExt), and %(Lib.OutputFile) with Visual Studio?

Question

I'm trying to build gtest on Visual Studio 2010. After converting the solution file, I tried to build, and I got the following warning messages.

Warning 1   warning MSB8012: 
TargetPath(C:\Users\sucho\Desktop\gtest-1.5.0\msvc\gtest/Debug\gtest.lib) does not match
the Library's OutputFile property value (C:\Users\sucho\Desktop\gtest-1.5.0\msvc\gtest\
Debug\gtestd.lib).

This may cause your project to build incorrectly. 
To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property
values match the value specified in %(Lib.OutputFile).  
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets

The message says I need to setup variables $(OutDir), $(TargetName) and $(TargetExt), together with property values specified in %(Lib.OutputFile).

How can I do that with Visual Studio (especially VS 2010)?

Serdab

Check this out: How to fix MSB8012 (Lib.OutputFile)? Visual Studio 2010 - $(TargetName) macro – Angwantibo

Answer 1

The warning is spurious -- assuming you're using Google Test, it works just fine

You can make it go away however. Right click on the offending project and select properties. Select "Librarian" in the tree view on the left hand side, and change the "Output File" item on the right by clicking on the box next to output file, and selecting "Inherit from parent or project defaults".

Skimmia

This is not the correct answer. This changes the name of the output file, both the debug and the release build of the .lib are now named gtest. Whatever was built last will overwrite the file. It got the OP in trouble when he ended up linking the release build of the .lib to the debug build of the code he wanted to test. He deleted that question later, I assume he sort of figured it out. – Impenitent

@Hans: Not true. Visual Studio already puts these files in separate folders. The extra "d" is only required if you decide to copy the libs into a single directory. – Skimmia

what if I want the name to stay same? I think answer provided by @HansPassant is more correct. – Paperback

@alariq: 1. I have no idea why you'd want to do that. 2. Even if you do, Hans' answer and mine essentially say the same thing. – Skimmia

@BillyONeal: this is a common problem when converting from one solution version to another. One more reason is if this is the case Then you'll also have to manually change Debugging->Command. Because it is set to $(TargetPath) by default. And the problem is that $(TargetName) (which is the part of $(TargetPath)) is not the same as output file. – Paperback

Answer 2

I see it. Right-click the gtest project, Properties, Configuration properties, General. Ensure that the Debug configuration is selected (upper left combo). Change the Target Name property to

 $(ProjectName)d

Note the added "d" to change the name from gtest to gtestd. The warning is otherwise benign.

Impenitent

Answer 3

I think no one has the right answer, i solved this way: in project properties pages, check if linker->General->Output file match configuration properties->General->target name & configuration properties->General->target extension.

You don't need to add any 'd', of course, is more simple set to Inherit from parent or project defaults, for all 3 variables.

Example:

Linker → General → Output File = "myproject.exe"

then:

Configuration Properties → General → Target Name = "myproject"

configuration properties → General → Target Extension = ".exe"

Wowser

ok so you want Output File to contain $(TargetName)$(TargetExt) right ? By default, it contains $(OutDir)$(TargetName)$(TargetExt) : so does it expect a path in it ? – Cotto

Answer 4

The background to this is that Microsoft changed the meaning of the $(TargetName) macro. It used to mean "whatever filename you put in Linker | Output File, minus the extension". They changed it to "by default, the name of your project". (This is something you should never do, in my view; they should have added a new macro).

Whereas VS2008 and earlier were able to parse the file name out of the Linker setting, apparently they were not able to parse it out in the migration to newer versions, leaving our configurations broken.

The warning itself is probably not important, but if you use $(TargetName), say by passing it to a batch file, this change will break your batch process.

For us, the solution has been to copy the file name (minus extension) from Linker | Output File to General | Target Name, and then set Linker | Output File to "inherit from parent/default". This is because we use suffixes like "d" (for debug), "u" for Unicode, _64 for 64-bit and so forth.

On the other hand, if your output file always matches the name of the project, then all you need to do is set Linker | Output File to "inherit default" and you're done, in principle - providing that the output directory you want for your compiled file matches General | Output Directory.

This change is absolutely infuriating because it involves moving literally hundreds of settings around, all due to sheer laziness on Microsoft's part, as far as I can see.

Walter

Answer 5

I was just trying to compile an application in Visual Studio 2019 that I had last compiled in Visual Studio 2005. I encountered the same warning.

I thought I would show what I did visually with screen shots.

Solution Name v Target Name

As you can see, my variables were both set to Import Text:

I could have just set the $(TargetName) to ImportText to solve my issue. However, we will leave those values as they are.

Linker / General Output File

This is how I had the output file setup:

Notice that I had overridden the output target name as ImportText. This was over 10 years ago and I did not have as much experience.

General / Target Name

So all I had to do was make the same adjustment here:

Now it compiles file.

Butene

The TargetName is now in Advanced tab in VS2019. Changed that still changes the $TargetExt variable. – Skilled

Answer 6

This kind of errors typically arise when upgrading old project to new version of Visual Studio (like in your case to VS2010) and also if project settings may have been manually changed (for example changing executable name). We know VS2010 uses these macros $(ProjectName) $(TargetName) $(OutDir) $(TargetExt) to control release/debug outputs but it is often mystery where to change them. We than typical resort to changing the name of output files directly through Project >> Properties. This means we now have to change the output files separately for debug and release build and if there was any dependencies, we will get error like This may cause your project to build incorrectly..

These macros/properties are VS2010 defaults but you can set them yourself in .vcproj files by editing it in notepad. Note search first for the property in the .vcproj file first, if its there than change its value, if not define it like below.

  <PropertyGroup Label="My Values">
    <ProjectName>New_Project_Name</ProjectName>
  </PropertyGroup>

Above I have defined a new <property group> to keep these values but you can define them anywhere. I define this at the top of the file right after debug/release configuration group so its visible everywhere. Make sure your project properties are setup properly to use them correctly (they should be what is VS2010 default settings). If you have changed them you should copy it from new test project. You can of course add the other Macros you want to set values for in the above group as well.

You can also verify the new values of this macros through project properties. For example click in Configuration Properties >> General and than in 'Target Name' box. Select edit. It will bring up a dialog box with the button 'MACROS >>'. Click that and it will show you what the value of each macro is. It should correctly reflect the new values that you set in .vcproj file.

Skilled

Thanks. I've been looking for how to set those build time symbols for a long time. – Ricker

@zadane - forgive my ignorance... For VS2010, OutputDirectory and OutputFile are set correctly after VCUpgrade. However, TargetName and TargetExt are missing. How can we use your trick to add TargetName and TargetExt to, say, VS2005 so it survives a VS2010 upgrade (and things "just work" for a VS2010 user)? Also see How to modify TargetName and TargetExt by changing the project file's XML? – Ingratitude

@Skilled - It looks like the system deleted it due to too few views; and no answers or comments. – Ingratitude

Answer 7

Just as Hans Passant posted, you need to modify the TargetName property manually. This is different between VS2005/2008 and VS2010. Please refer to http://social.msdn.microsoft.com/Forums/en-US/vcprerelease/thread/3c03e730-6a0e-4ee4-a0d6-6a5c3ce4343c

Glaze