Building a basic C++ project with Visual Studio 2012. When I make changes to source files:
the corresponding object files are compiled
the .tlog files for the compiler are updated
the PDB file is updated
the .tlog files for the linker however are not changed
the linker claims All outputs are up-to-date. and does not build a new executable.
The only way to get the executable to be built is deleting it. It seems something with the tracking system is wrong and I was wondering if anyone can shed some light on this issue.
Here is the msbuild output after I change two files, full paths and some other stuff omitted (this output is for the VS2010 toolset, but 2012 behaves the same):
1>Target "ClCompile" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets"...
Using "CL" task from assembly "Microsoft.Build.CppTasks.Win32, Version=4.0.0.0...
Task "CL"
Read Tracking Logs:
cl.read.1.tlog
CL.2520.read.1.tlog
...
Outputs for ....
XXX.OBJ
YYY.OBJ
...
xxx.cpp will be compiled as xxx.cpp was modified...
yyy.cpp will be compiled as yyy.cpp was modified...
Write Tracking Logs:
cl.write.1.tlog
CL.2520.write.1.tlog
...
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\CL.exe ....
Tracking command:
C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\Tracker.exe ....
xxx.cpp
yyy.cpp
Done executing task "CL".
1>Done building target "ClCompile" in project "xxx.vcxproj".
so far, so good. Now the linker kicks in (well, it doesn't):
1>Target "Link" in file "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets"....
Using "Link" task from assembly "Microsoft.Build.CppTasks.Win32, Version=4.0.0.0...
Task "Link"
Using cached output dependency table built from:
link.write.1.tlog
Using cached input dependency table built from:
ink.read.1.tlog
Outputs for ....
MY.EXE
MY.PDB
All outputs are up-to-date.
Done executing task "Link".
Task "Message"
xxx.vcxproj -> my.exe
Done executing task "Message".
1>Done building target "Link" in project "xxx.vcxproj".
After checking all options we have in the property sheets one-by-one, it seems the sole source of this problem is that we have the intermediate directory set to a directory on another drive. We always do out of source builds in %TEMP%, and most of the time the projects reside on another drive.
Filed a bug report here including simple steps that reproduce the problem. Hopefully this gets fixed soon. Current soltuion is to set IntDir to a direcyory on the same drive as the project.
UPDATE
The bug report filed for this issue was closed as 'by design': it seems the Intermediate Directory should not be %TEMP% or %TMP% or any subdirectory of those. Disturbing, but at least I know what was wrong now.
Related
I have 3 projects; Project1.Web, Project1.Service and Project1.Common.
Both Project1.Web and Project1.Service have dependencies on Project1.Common.
If I rebuild the solution which contains all 3 projects; all works correctly.
If I change a file in Project1.Web; files are built to Project1.Web\bin - all works correctly.
If if change a file in Project1.Service files are built to Project1.Service\bin\Debug AND some are copied to Project1.Web\bin. The copied file is Project1.Common.dll, but Project1.Web.dll is not built (or copied).
The file modified in Project1.Service is not shared, its just modified to trigger an incremental build of Project1.Service.
Does anyone know why Visual Studio would be copying a build artifact to a a directory that is not part of the incremental build?
Currently this sequence of events leaves Project1.Web is a non-working state as Project1.Service and Project1.Web have dependencies on different versions of the same assembly via a third party assembly. If we decide to make a change to Project1.Service then it has the side-effect of breaking Project1.Web.
I've tried/checked the following:
There are no dependencies between Project1.Web and Project1.Service (either direction).
The file modified in Project1.Service is not shared; and there are no pre/post build events defined.
Executing msbuild on the Project1.Service.csproj project file does not have the same effect.
Denying write/create permission on the bin directory under Project1.Web does not cause the incremental build to fail.
No output is emitted in the detailed or diagnostic msbuild output that references Project1.Web (from within Visual Studio)
Using procmon, I can see that devenv is using mswebprj.dll (C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\mswebprj.dll) - which invokes the copy of the file.
Since VS2010, Microsoft Visual Studio introduces the Platform Toolset concept that encapsulate the traditional global INCLUDE, LIB, PATH settings inside various Toolsets. I admit that's an improvement for flexibility, but it should not be a blackbox that makes us foolish.
Now my question is, how do I know what the resulting INCLUDE, LIB, PATH are when I apply a Toolset to my project. I think it is not realistic to analyze those hundreds of .targets and .props files(in C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120) manually to get the result. Most of the time, we just need the result. Is there any concise way to achieve that?
==== UPDATE ====
Stijn provides the right answer for me. Now I can see PATH= , LIB= , INCLUDE= ... from the build log. But, a minor question, what is the difference of LIB and LIBPATH?
1>Using "SetEnv" task from assembly "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.Build.CppTasks.Common.dll".
1>Task "SetEnv"
1> PATH=C:\VS2013\VC\bin;;C:\Program Files (x86)\Microsoft SDKs\Windows\v8.1A\bin\NETFX 4.5.1 Tools;C:\VS2013\Common7\Tools\bin;C:\VS2013\Common7\tools;C:\VS2013\Common7\ide;C:\Program Files (x86)\HTML Help Workshop;;C:\Program Files (x86)\MSBuild\12.0\bin\;C:\Windows\Microsoft.NET\Framework\v4.0.30319\;C:\Windows\SysWow64;;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;;C:\Windows-Kits\8.1\bin\x86;C:\Windows-Kits\8.1\tools\tracing\x86
1>Done executing task "SetEnv".
1>Task "SetEnv"
1> LIB=C:\VS2013\VC\lib;C:\VS2013\VC\atlmfc\lib;;
1>Done executing task "SetEnv".
1>Task "SetEnv"
1> LIBPATH=C:\VS2013\VC\atlmfc\lib;C:\VS2013\VC\lib;
1>Done executing task "SetEnv".
1>Task "SetEnv"
1> INCLUDE=D:\u8vc\USBview\C++\;C:\VS2013\VC\include;C:\VS2013\VC\atlmfc\include;;
The easisest way is probably to adjust the msbuild log settings so the INCLUDE/LIB/PATH environment variables are printed to the output window. In Visual Studio's options you can either:
set Projects and Solutions->VC++ Project Settings->Show Envirohnment In Log to Yes
set Projects and Solutions->Build and Run->MSBuild project build output verbosity to Detailed or Diagnostic
Then in the build log grep for INCLUDE etc
For command line builds use the /v:d switch with MSBuild.
After a great deal of searching and head banging, i'm asking this question.
I started a new Windows Forms Application in Visual Studio 2010. Gave it a name and stored it in a location. Nothing added or edited in the same. No changes in the project properties either.
Here is a copy of the Solutions Explorer.
I'm building the empty form and I get the following error.
1>------ Build started: Project: TestProject, Configuration: Debug Win32 ------
1>Build started 27/11/2013 1:35:27 PM.
1>InitializeBuildStatus:
1> Touching "Debug\TestProject.unsuccessfulbuild".
1>GenerateTargetFrameworkMonikerAttribute:
1>Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files.
1>CoreResGen:
1> Processing resource file "Form1.resX" into "Debug\TestProject.Form1.resources".
1>LINK : fatal error LNK1104: cannot open file 'Debug\AssemblyInfo.obj'
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.41
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Now I have checked every damn page relevant to the error (6 hrs. of googling!!)
Here is a list of the possible errors as suggested by MSDN. Now I'm new to MSVS 10, so I figure out that the .obj file is not present in the Debug Window, but AssemblyInfo.cpp is present. What should I do in the project settings so that the .obj gets compiled and the error goes away.
Update: Still no answers!! I'm amazed how NOBODY is getting this issue. Here is what I have tried soo far and the following happens:
Opened new Visual C++ Windows Forms Application (no modifications!)
Write ABSOLUTELY NO CODE.
Build Project
And the error occurs.
Next
Opened an old solution, where the .obj files were present.
Made a rebuild of the solution.
Same Error.
I look up the solution in the windows explorer. All .obj files are gone(which should happen as a rebuild would clean the .obj files). But what remains are onlt the .log files.
Thus, I have isolated the error that the compilation is not occuring as the linker files are not being created. As a result, the linker error LNK1104 or LNK1181 happen.
Can somebody tell me why is this problem. Has anyone seen this before. Can anyone provide a solution, if possible??
The compiler says there are not modification in any of the files "Skipping target "GenerateTargetFrameworkMonikerAttribute" because all output files are up-to-date with respect to the input files." So it'll skip the compilation phase (which generates the .obj files).
But the linker needs these files and for some reason they don't exist (at least that's what you claim is happening).
So you can try to force the compilation by doing a clean and than rebuild.
EDIT:
This particular issue can also be caused by specifying a dependency to a lib file that has spaces in its path. The path needs to be surrounded by quotes for the project to compile correctly.
On the Configuration Properties -> Linker -> Input tab of the project’s properties, there is an Additional Dependencies property.
C:\Program Files\<lib> -> "C:\Program Files\<lib>"
This problem got solved long ago.
1>LINK : fatal error LNK1104: cannot open file 'Debug\AssemblyInfo.obj'
1>
1>Build FAILED.
This was happening because the file Debug\AssemblyInfo.objwas simply not being created. This was due an error in the VS registries.
I did a clean, fresh install of windows and VS. This fixed the registry issues, and the file was being created perfectly.
I hope this helps people. Cheers!
I had a similar problem recently and it turned out to be due to the fact that I'd forgotten to unset /P in my compiler settings. Even though it seems like your problem is distinct, we both got the same error message.
When you preprocess to a file, cl stops producing .obj files.
I have a batch file that builds an ASP.NET web application project, but it's not taking in the Entity Framework resource files in the Core Compile process.
The build script is:
set proj_name=MyProject
set proj_path=C:\...\path-to-project\
set pkg_name=MyProject.zip
set build_config=Release
set platform=AnyCPU
set msbuild=%windir%\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
%msbuild% "%proj_path%%proj_name%.csproj" /t:package /p:OutPath="%proj_path%obj" /p:OutputPath="%proj_path%bin" /p:Configuration=%build_config% /p:Platform=%platform%
While the script completes without errors, but the web app crash with Unable to load the specified metadata resource error.
But if I do a Visual Studio Publish, everything works fine. So that points me to look into my build output.
After carefully comparing the Visual Studio Publish output and my build script output, I found in the CoreCompile section, the csdi, msl and ssdl files are missing from my build script output. But the files are there on the file system and part of the Solution and Project. So I'm not sure why they are not included during the build. Below, is part of the build output:
Visual Studio Publish output:
/debug:pdbonly /optimize+ /out:obj\Release\Dnr.MotorPool.dll
/resource:obj\Release\edmxResourcesToEmbed\DataAccess\MyDataModel.csdl,DataAccess.MyDataModel.csdl
/resource:obj\Release\edmxResourcesToEmbed\DataAccess\MyDataModel.msl,DataAccess.MyDataModel.msl
/resource:obj\Release\edmxResourcesToEmbed\DataAccess\MyDataModel.ssdl,DataAccess.MyDataModel.ssdl
/target:library
/utf8output all the cs files...
My build script output:
/debug:pdbonly /optimize+ /out:obj\Release\Dnr.MotorPool.dll
/target:library
/utf8output all the cs files...
So clearly, there are 3 missing files. How do I modify my build script then?
%msbuild% "%proj_path%%proj_name%.csproj" /T:Rebuild;Package
I have inherited a WiX project from a contractor that recently left.
When I build the WiX installer project, there is no problem - the .msi is built and output as expected.
But when I "rebuild" the WiX installer project, again the .msi is built just fine by light.exe, but it subsequently gets deleted by a "CoreClean".
Further info: The wix project packages (and references) a single web project.
This is a snippet of the output:
ICE105: ICE105 - Validates the package to make sure that it can be installed in true Per-User mode
ICE105: Created 05/01/2008. Last Modified 05/21/2008.
Laying out media.
Moving file 'C:\Users\codemonkey\AppData\Local\Temp\nxkfdvui\AmazonWebsiteInstaller.msi' to 'C:\web\main\Amazon.Webby.Install\bin\Release\AmazonWebsiteInstaller.msi'.
Done executing task "Light".
...
...
Target "CoreClean" in file "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets" from project "C:\web\main\Amazon.Webby.Install\Amazon.Webby.Install.wixproj" (target "Clean" depends on it):
Task "ReadLinesFromFile"
Done executing task "ReadLinesFromFile".
Task "FindUnderPath"
Comparison path is "bin\Release\".
Done executing task "FindUnderPath".
Task "FindUnderPath"
Comparison path is "obj\Release\".
Done executing task "FindUnderPath".
Task "Delete"
Deleting file "C:\web\main\Amazon.Webby.Install\bin\Release\AmazonWebsiteInstaller.msi".
Deleting file "C:\web\main\Amazon.Webby.Install\bin\Release\AmazonWebsiteInstaller.wixpdb".
Deleting file "obj\Release\MainWixComponents.wixobj".
Deleting file "obj\Release\UploadContent.wixobj".
Deleting file "obj\Release\WebSiteContent.wixobj".
Deleting file "obj\Release\Product.Generated.wixobj".
Done executing task "Delete".
...
...
I can't find any delete task in the installer project file that involve the msi or output folder, so it's a result of visual studio doing a rebuild and thinking it needs to clean out files that it doesn't.
This seems to be the relevant section in "C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.x\wix2010.targets" causing the delete of the newly built msi:
<!--
==================================================================================================
CoreClean
Cleans all of the compile and link outputs as well as any intermediate files generated along
the way.
==================================================================================================
-->
<PropertyGroup>
<CoreCleanDependsOn></CoreCleanDependsOn>
</PropertyGroup>
<Target
Name="CoreClean"
DependsOnTargets="$(CoreCleanDependsOn)">
...
<!-- Delete those files. -->
<Delete Files="#(_CleanPriorFileWritesInOutput);#(_CleanPriorFileWritesInIntermediate)" TreatErrorsAsWarnings="true">
<Output TaskParameter="DeletedFiles" ItemName="_CleanPriorFileWritesDeleted" />
</Delete>
...
Any ideas?
Thanks.
I know it's old but this is mentioned as a fixed bug in SourceForge:
http://sourceforge.net/tracker/?func=detail&atid=642714&aid=1719357&group_id=105970
Are you using a version post 3.0.4102.0?
There does seem to be some debate as to whether the bug is really fixed in the comments.
To resolve this I took all the InitialTargets steps (which were msbuild.exe calls) out of the wixproj file and moved them into a batch script called from the pre-build event project property. I did this because there was another problem - the targeted projects were being built as the project was loaded, which meant that it took a long time to open the solution. At any rate, moving everything into a batch file resolved both problems.