I am builidng CPPunit 1.12.1 using VS 2010. I able to build CPP unit successfully on VS 2008. I am building only CPPUnit library.
I am getting following error. How can i fix this error.
error MSB3073: The command "copy "D:\src\cppunit\.\Debug\cppunit.lib" ..\..\lib\cppunit.lib
:VCEnd" exited with code 1. C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 113 6 cppunit
I am also mentioning one of warnings which is related to error i think so.
C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(1151,5): warning MSB8012: TargetPath(D:\src\cppunit\.\Debug\cppunit.lib) does not match the Library's OutputFile property value (D:\src\cppunit\Debug\cppunitd.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).
These are post-build event errors.
Right click on your project-name in Visual Studio Solution Explorer:
Properties >> Post-Build Event
Remove the text from CommandLine textbox if you don't want post-build events. Or fix the path!
The issue is that the post-build step is something like: copy "$(TargetPath)" ....\lib\$(TargetName).lib.
Since the 'TargetName' value changes depending upon the build type, go in the project properties and change the 'target name' depending upon the selected build. In your case, if you check your 'warning' carefully, you will find that you are trying to copy the cppunit.lib to the ..\lib folder when actually your expected output is supposed to be cppunitd.lib. TargetName mismatch!
Another thing that I found helpful (it may be something only I observed) was building the 'release' build first, followed by the 'debug' build.
You have the configuration slightly messed up.
You are telling MSVC to create an output file in one directory and then use it from a different one - and it looks like at least one of the dirs doesn't exist.
It's nothign to do with cppunit
Related
I'm struggling with this for a long time now.
The setup:
c# project
c++ project
c# project has a reference for the c++ project with the following lines:
<ProjectReference Include="projectB.vcxproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>Content</OutputItemType>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</ProjectReference>
This works from withing visual-studio.
This works when using devenv from command line.
When using msbuild from command line - the output file of the c++ project is not copied over into the output directory of the c# project.
I wasn't able to fix that using msbuild. Read a lot about it, nothing worked. Tried to debug in using diag verbosity - but logs of msbuild and visual-studio are very different...
I can't turn to using devenv as the build machine doesn't have valid visual-studio.
In msbuild log with diagnostic verbosity I see:
Target "GetCopyToOutputDirectoryItems" skipped. Previously built successfully.
This is where in the visual-studio log - it looks different - and actually works on copying the referenced native files to the c# output directory.
Perhaps something related with build order?..
In msbuild log - I also see:
Target "_CopyOutOfDateSourceItemsToOutputDirectoryAlways" skipped, due to false condition; ( '#(_SourceItemsToCopyToOutputDirectoryAlways)' != '' ) was evaluated as ( '' != '' ).
While in the visual-studio build log I see this target executed (it comes right after GetCopyToOutputDirectoryItems target)
Update 3:
It seems that previous solutions cause unwanted side-effects such as breaking the build when running multi-threaded builds.
Current solution, that does seem to work is to add:
<Targets>Build;BuiltProjectOutputGroup</Targets>
to the ProjectReference section.
Update 2:
Changing:
Targets="%(_MSBuildProjectReferenceExistent.Targets)"
to
Targets="%(_MSBuildProjectReferenceExistent.Targets);GetTargetPath"
in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets, in the MSBuild task preceded by the comment Build referenced projects when building from the command line. - did the trick.
However, I have no confidence in this solution, as I don't understand the entire build process. This is just a guess.
Update 1:
using /p:DesignTimeBuild=true affects dependency build order. Can't work. Continue investigation...
Possible solution 1:
After putting a lot of messaged into C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
I finally got to the following:
QUIRKING FOR DEV10
I'm still not exactly sure what that is all about, and I saw that the developers plan to remove this quirk (see https://github.com/Microsoft/msbuild/issues/1890).
Suddenly DesignTimeBuild caught my eye in the following line:
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedProjectReferencePaths" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)'=='true' or '$(DesignTimeBuild)' == 'true'"/>
I know that inside visual-studio this work. Googling got me to https://github.com/Microsoft/msbuild/wiki/MSBuild-Tips-&-Tricks.
From there the path was short to adding /p:DesignTimeBuild=true to the msbuild command line.
That made it work. The referenced assembly was copied over.
I don't think this should be the solution, but it works, and don't seem to break anything else (yet).
Any other suggestions would be welcome.
I have installed the latest version of fltk 1.3.3. I run into build errors every time I want to build the "Demo" project in VS 2015. I have seen the same question for older versions of VS; none of them seem to help me resolve this issue. I've tried to change the debug information format to the other available values but this has not helped. In fact when I tried to build a release version, avast kicked in and blocked the whole thing. When it comes to dealing with the $(OutDir), $(TargetName) and $(TargetExt) property values, I'm totally out of my depth. This takes me to Microsoft.CppBuild.targets which is something I don't want to mess with. FLTK is SUCH a pain to do anything with from beginning to end. This is the message I get:
"MSB8012 TargetPath(C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\ide\VisualC6.\Debug/Demo\Demo.exe) does not match the Linker's OutputFile property value (C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\test\Demod.exe). 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 %(Link.OutputFile). Demo C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets 1189"
If there's anyone out there with some ideas as to how to resolve this, I'd greatly appreciate that. I've spent the whole day trying to figure this out.
It looks like the target specified by the linker (C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\test\Demod.exe) is different than the target specified by the compiler (C:\Users\Pablo\Desktop\c++ course files\Visual C++\fltk-1.3.2\ide\VisualC6.\Debug/Demo\Demo.exe).
If you right click on your project > Properties > Configuration Properties > General
Make sure that "Output Directory" and "Target Name" match Configuration Properties > Linker > Output File.
You could make them the same by setting Linker > General > Output File to
$(OutDir)$(TargetName)$(TargetExt)
If your Linker's output file is already set to that, then the macros are somehow wrong.
I'm trying to get a pure x64 build running for a complex build with many solutions (some for CI, some for devs) and hundreds of project and have run into "error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32"
I've reduced it to a simple configuration:
Solution A contains Project X & Project Y. Project X has a project
reference to Project Y.
Solution B contains also contains Project X.
None of the projects or solutions contain a Win32 platform - it's been deleted.
When I build solution B (as x64), I receive
error MSB8013: This project doesn't contain the Configuration and
Platform combination of Debug|Win32
The error message sometimes contains additional information:
This error may also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
The problem is the referencing project does "build using the same or an equivalent Configuration or Platform."
Looking at the msbuild diagnostic, project Y is being built because project X contains a project reference to it. But the configuration and platform properties are being deleted just before project Y is built:
1>Task "MSBuild" (TaskId:28)
1> Removing Properties: (TaskId:28)
1> Configuration (TaskId:28)
1> Platform (TaskId:28)
As a result Microsoft.Cpp.Default.props kicks in and sets these to Debug|Win32:
1>Task "Message" (TaskId:11)
1> Configuration=Debug (TaskId:11)
1>Done executing task "Message". (TaskId:11)
1>Task "Message" (TaskId:12)
1> Platform=Win32 (TaskId:12)
1>Done executing task "Message". (TaskId:12)
How can I prevent this and make msbuild pass the chosen configuration & platform?
(I understand the ultimate solution to use NuGet to manage package dependencies, but that isn't feasible in the short term)
I could resolve a similar issue by including all referenced projects into the solution - in this case including Project Y into solution B.
One fix is to hand edit the .vcxproj files to define the default platform:
Open the vcxproj file in a text editor
Add this line in the "Globals" PropertyGroup:
<Platform Condition="'$(Platform)' == ''">x64</Platform>
It seems it is a bug in Microsoft.CppBuild.targets file. On some machines I see two such files: one in C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets with ~120KB size, and C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets with 77KB size. Second one is buggy and gets wrong $(Configuration)|$(Platform) value which yields mentioned error. This problem is probably directly connected with this topic, as VCTargetsPath in my projects pointed into wrong (77KB) Microsoft.CppBuild.targets directory (I use VS2015 so it should use the one from V140 directory). I found two workarounds: 1) replace buggy file or 2) modify HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\14.0\14.0\VCTargetsPath10 registry to point right file.
I couldn't add a comment because of lack of rep, but in the same vein of user1825216's answer, I'm running MSBuild from a command line so I resolved this error by adding -p:Platform=x64 to the build command instead of modifying the .vcxproj.
I find it difficult to see what you're trying to achieve through this. Do you always want to build X AND Y? Even in the solution that has no reference to Y? Would be fairly illogical to me. Though, I can offer you some solutions to fixing / supressing this issue, based on what you want.
If you want to build X&Y with A and X with B
In Solution A, set the other project as a build dependency, instead of referencing project Y in project X. You can't set it as long as it refers to the other project (I always remove the reference in the .vcxproj, it's somewhere at the bottom of the project), but once you removed the inner project reference, you can have the solution reference to it and then it should work just fine.
When you build Solution A with MSBuild, it'll build X AND Y, while building solution B with MSBuild
Else
If you want to build X&Y with either solution
Sorry, but that's not really possible within MSBuild at the moment. I'd recommend adding project Y to the solution and referencing it, but then, why would you? You already have a project that has them both included, and if you want different outputs, you can easily make different configurations.
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
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 %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.
I had a VC2008 project very complicated.Inorder to understand it's inner workings I tried to simplify it and now I am getting 289 errors of the following type for most of the files:
Error 5 error C2471: cannot update program database 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb' c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
Error 6 fatal error C1083: Cannot open program database file: 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb': No such file or directory c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
My system : win7/VS2008
Solution 1: Locate *.vcxproj file in your solution, open in a text editor and search for 'DebugInformationFormat' and set it to 'OldStyle'. Reload your project and build. If you have multiple projects in your solution, this change needed for all the *.vcxproj files.
< DebugInformationFormat>OldStyle< /DebugInformationFormat>
Solution 2: From Visual Studio, on every project in your solution right click and open Properties. Expand 'Configuration Properties' > 'C/C++' > 'General'. Change the 'Debug Information Format' to 'C7 compatible (/Z7)'. Then build your solution.
This worked for me. (YMMV = Your mileage may vary:)
I've seen the same behaviour when converting a VS2003.Net solution to run on later IDEs. My guess is that your solution contains multiple projects which point to the same intermediate directory. In VS2005 and later, projects that don't depend on each other can be built in parallel so that if the same working dir is used, you can get file conflicts like this.
Check this as follows. In Solution Explorer, right click on one of the failing projects and select Properties. In Configuration Properties -> General section, make sure that every project has a different 'Intermediate Directory'. Try your build again using 'Rebuild Solution' to clean everything out.
Most of the times when I get "C2471: cannot update program database" it's because the PDB file is locked for some reason. Usually in my case that turns out to be because I have the program running in some other window, which loads the PDB file in to memory.
When that's not the reason, I find doing a rebuild-all magically fixes the problem.
I've encountered the same type of error myself with no end of frustration.
I finally fixed it by applying the Microsoft hot fix found in this knowledge base article: http://archive.msdn.microsoft.com/KB946040
This worked for me.
Kill mspdbsrv.exe and reload Visual C++
MSDN
You can delete the *.obj file and rebuild the solution again, This problem might solve. Below link might be helpful for you-
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/vs2008-c2471-cannot-update-program-database?forum=vclanguage