When compiling a C++ application with VisualStudio I noticed that each output line has a number in front of it. What does the "\d>" stand for?
Example:
4>ContentTimecodeConverter.cpp
1>avus_mpeg_stream_out.obj : warning LNK4221: no public symbols found; archive member will be inaccessible
4>ContentTarget.cpp
4>ContentBrowserWidget.cpp
1>Build log was saved at "file://d:\compile\release\libabc\BuildLog.htm"
1>libabc - 0 error(s), 1 warning(s)
You have concurrent building enabled, an option that enables building multiple projects at the same time. Each build running on one of the cores you have. Which inevitably causes their output to get intermingled. The number helps you keep track of which project produced the message.
It is configured with Tools + Options, Projects and Solutions, Build and Run, "maximum number of parallel build projects" setting.
It is a source of build breaks if you don't set the project dependencies correctly.
Related
I am just setting up a basic build with a very bare bones WebApi App, and I am getting a failed build, but without any errors or warnings... how can i figure out what is going wrong?
Project "d:\a\1\s\My.Project.Api.sln" (1) is building "d:\a\1\s\My.Project.Api\My.Project.Api.csproj" (2) on node 1 (default targets).
_CleanRecordFileWrites:
Creating directory "obj\Release\".
Done Building Project "d:\a\1\s\My.Project.Api\My.Project.Api.csproj" (default targets) -- FAILED.
Done Building Project "d:\a\1\s\My.Project.Api.sln" (default targets) -- FAILED.
Build FAILED.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.15
##[error]Process 'msbuild.exe' exited with code '1'.
Even any way I can get a useful log or error message would be great!
Edit:
I added /v:diag for the build arguments for verbose logging, but it really isn't seeming to help.
Before Visual Studio build task, you should use nuget restore to download packages your project is referring.
So please add a Nuget task before Visual Studio build task. Detail setting for NuGet task as below:
Command: restore
Path to solution, packages.config, or project.json: **/*.sln or select relative path for My.Project.Api.sln
Feeds to use: Feeds in my NuGet.config
In your build definition, there is a variable called system.debug which is set to false. Change this to true at the template or at the time of triggering and you will get the debug lines written by the build tasks. Inspect the debug lines and you might find the issue.
I have an ASP.NET core 1.0 project I created in Visual Studio 2015 (update 3). If I try to build the project within VS I get the following in my output window and there are no errors in the Error List:
1>------ Build started: Project: QuickStartIdentiyServer4, Configuration: Debug Any CPU ------
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
However, if I build the project using the dotnet CLI command (dotnet build) it builds and runs just fine.
UPDATE:
Apparently, .net core does not work properly when running Visual Studio as Admin. You would think everything should work as Admin, I guess not... go figure.
There are simply too many reasons why this type of thing might happen. The easiest way to diagnose the problem is to change the build output verbosity under options to verbose. This might help put you on the trail:
With regards to this type of thing happening with .Net Core and ASP Core. I have noticed that the project.json dependencies json fragment is a bit buggy especially if you start renaming projects and changing their file system location.
If you see in the diagnostic below you know there is some dangling reference issue:
Done building target "_GetDependencyFragmentFiles" in project "<<?YOUR_CORE_PROJECT?>>.xproj" -- FAILED
May be you are not seeing build errors. Go to Error List window and change 'Show Issues generated' box from 'Build + Intellisense' to 'Build Only' and try to build again.
See if this helps.
I have a custom MSBuild target included in my C++ project that produces a data file in the $(OutDir) folder for each item of a given item type. I have the item type hooked up with a property page schema so you can select it on files in the solution explorer and my target declares input and outputs so incremental builds work. I have also added my target to the $(BuildDependsOn) property so it is automatically evaluated during the Build target Visual Studio invokes.
Everything seems to work except for one thing: If I delete one of my output data files in the $(OutDir) and then build Visual Studio does nothing and says my project is up to date. If I delete the exe file the project produces or touch the modified time of one of the MSBuild scripts Visual Studio re-evaluates the targts and finds the output file is missing, causing it to be re-built using my target.
From the MSBuild diagnostic logging it seems like Visual Studio is internally maintaining some list of output files and input files that it checks to avoid evaluating the MSBuild script at all. How do I add my output files to this list?
MsBuild/VS indeed have a mechanism to determine what is up-to-date with respect to the input files, it revolves around an executable tracker.exe which scans .tlog files to figure out what a project's output files are. There might be more to it, and if you look around on the internet you can probably get more info about this.
But the thing is you don't really need to understand every single detail of it: you can find a simple usage example for it when inspecting how the built-in CustomBuildStep works and apply that to your case. I'll briefly explain how I got to this because I think it might be useful for you as well in dealing with msbuild questions like these.
If you add
<ItemDefinitionGroup>
<CustomBuildStep>
<Command>echo foo > $(OutDir)\foo.txt</Command>
<Outputs>$(OutDir)\foo.txt</Outputs>
</CustomBuildStep>
</ItemDefinitionGroup>
either manually or via the project's property pages for Custom Build Step you'll see the beahviour is eactly what you need: if foo.txt is deleted a build will start, while a build is marked up-to-date if it is not (well, and when the rest of the outputs are also up-to-date).
Hence the key is to do what CustomBuildStep does under the hood, and figuring that out is just a matter of using your tool of choice to search all occurrences of CustomBuildStep in all files under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120 (adjust path for platform/VS version used).
This leads us to Microsoft.CppCommon.Targets where the target named CustomBuildStep (mind you, that's the same name as the entry in the ItemDefinitionGroup above) invokes the actual CustomBuildStep command. It also has this particularily interesting bit:
<!-- Appended tlog to track custom build events -->
<WriteLinesToFile Encoding="Unicode"
File="$(TLogLocation)$(ProjectName).write.1u.tlog"
Lines="#(CustomBuildStep->'^%(Identity)');#(CustomBuildStep->MetaData('Outputs')->FullPath()->Distinct())"/>
So this writes the path of the Outputs to a .tlog file in the directory used by the tracker and makes it work as desired. Also see here for more information about the format.
tl;dr Use WriteLinesToFile to append full paths of your targets' outputs to a file like $(TLogLocation)$(ProjectName).write.1u.tlog. I'm saying like because write.tlog, write.u.tlog etc also work.
Visual Studio uses something called Visual Studio Common Project System (CPS) (https://github.com/Microsoft/VSProjectSystem) (VS 2017)
to manage projects, including build process.
Within CPS anything that implements IBuildUpToDateCheckProvider interface can be used
as a 'UpToDateChecker' for a project.
'UpToDateChecker' is invoked before invoking MsBuild. Its main purpose is to determine whether or not invoke MsBuild to build project, or to mark project as 'Up To Date' and skip msbuild all along.
This 'UpToDateChecker' is exactly what prints into diagnostic build output:
1>------ Up-To-Date check: Project: "ProjectName", Configuration:
Debug x86 ------ Project is not up-to-date: build input 'header.h' was
modified after build output 'a.out'. Input time: 12/27/2018 4:43:08
PM, Output time: 1/1/0001 2:00:00 AM
As for C++ Projects, for VS 2017 its default 'UpToDateChecker' is VCProjectBuildUpToDateCheck
( Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll ).
As starter, it looks into tlogs directory ( usually something like Debug\x86\.tlog) for these files:
.lastbuildstate
unsuccessfulbuild
all '.read..tlog' - input files, marked as 'build input' in diagnostic build output
all '.write..tlog' - output files, marked as 'build output' in diagnostic build output
There's actually more checks, but most fails occur when checking these 4 types
The original question here relates to C++ projects, but for anyone finding this while searching for information about modern (SDK-style) C#/VB/F# projects, you can customise Visual Studio's fast up-to-date check as described in this document:
https://github.com/dotnet/project-system/blob/master/docs/up-to-date-check.md
In a nutshell, you specify inputs and outputs as items:
UpToDateCheckInput — Describes an input file that MSBuild would not otherwise know about
UpToDateCheckBuilt — Describes an output file that MSBuild would not otherwise know about
It can be very helpful to increase the diagnostic logging level for the up-to-date check via this setting:
You can find out why a project is being rebuilt by enabling the verbosity of the fast up to date checker in the registry key:
New-ItemProperty `
-Name U2DCheckVerbosity `
-PropertyType DWORD -Value 1 `
-Path HKCU:\Software\Microsoft\VisualStudio\14.0\General -Force
You should be able to see in the build log messages like
Project 'Caliburn.Micro.Silverlight.Extensions' is not up to date. Project item 'C:\dev\projects\Caliburn.Micro.Silverlight.Extensions\NavigationBootstrapperSample.cs.pp' has 'Copy to Output Directory' attribute set to 'Copy always'.
[1] https://blogs.msdn.microsoft.com/kirillosenkov/2014/08/04/how-to-investigate-rebuilding-in-visual-studio-when-nothing-has-changed/
To enable logging for old-style projects (i.e. non-SDK-style projects, common in the .NET Framework era):
Open a "Developer Command Prompt" for the particular version of Visual Studio you are using.
Enter command:
vsregedit set "%cd%" HKCU General U2DCheckVerbosity dword 1
The message Set value for U2DCheckVerbosity should be displayed.
Run the same command with a 0 instead of a 1 to disable this logging.
More information at: https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#net-framework-projects
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 use CMake generated solution for Visual Studio 2010.
In my solution I have several lib projects and one exe project.
For Debug build configuration I use output names like lib1_d.lib, lib2_d.lib etc...
For Release build configuration I use lib1.lib, lib2.lib ...
thanks to CMake I have one extra build configuration I use - RelWithDebugInfo. I use same output names for this build configuration as for Release.
Now here is the problem:
Assuming everything is cleaned.
I hit F5 (run / start debugging) RelWithDebugInfo. All project are built (exe is depending on them) and project runs successfully.
I switch to Release and hit F5 again. All project are built and project runs successfully. (libraries in output directory are overwritten)
I switch back to RelWithDebugInfo and hit F5. VS quickly goes through and gives All outputs are up-to-date. ... Build succeeded. And DOES NOT overwrite lib files in output directory. So application crashes because it uses libraries for other build configuration.
This problem occurs for both ordering Release->RelWithDebugInfo and RelWithDebugInfo->Release
I haven't find a solution, how to add other prefix to RelWithDebugLibraries my SO question
Is there a way, to force Visual Studio 2010 to always overwrite outputs? Preferably by some flag which I can provide from CMake.
The VS build system solves this problem by using different build directories for different configurations. By default, 32-bit Debug output goes to the Debug directory, Release output goes to the Release directory, 64-bit Debug output goes to x64\Debug directory, etcetera. This way different configurations never step on each other's output files.
Looks to me like the mistake you made with your added RelwithDebugInfo configuration is that you didn't modify the output file names. So the build system sees an up-to-date output file from another configuration and doesn't think it necessary to rebuild them.
Coming up with variations of build output file names does get to be impractical once you go past two, do consider the VS-way to do this.