In Visual Studio 2010 incremental builds are done using the File Tracker (Microsoft.Build.Utilities.FileTracker). It seems that it is responsible to the creation of these *.1.tlog files on the intermediate directory.
I couldn't find any reference to the syntax of these .tlog files.
They contain a list of paths to files that are read/written while the tracker tracks the execution of some tool, in order to check which files should be compiled in an incremental build. However, these files also contain some special characters such as "^" and "|".
Another thing I noticed was that these files are sometimes edited from Visual Studio targets files. For example, in Microsoft.CppCommon.targets on CustomBuildStep target I found the following line:
<!-- Appended tlog to track custom build events -->
<WriteLinesToFile File="$(IntDir)$(ProjectName).write.1.tlog" Lines="#(CustomBuildStep->'^%(Identity)');#(CustomBuildStep->MetaData('Outputs')->FullPath()->Distinct())"/>
So this probably means that the project file is dependent on the custom build step outputs.
My questions are:
Does anyone know of a reference for the .tlog file syntax?
In which cases is the tracker-log used on Visual studio? I know of the CL and maybe Link tasks that use it, but it seems that Visual Studio IDE itself uses it in order to decide whether to run msbuild at all for a certain project.
Thanks
EDIT
Another hint:
CanonicalTrackedInputFiles Class is document as "the filetracking log interpreter for .read. tracking logs in canonical form or those that have been rooted (^) to make them canonical"
When I have time I'll dig into it a bit more. Perhaps this class and others under Microsoft.Build.Utilities could be used to help us work with tlog files instead of working with the raw text tlog files directly.
See also: CanonicalTrackedOutputFiles Class, FlatTrackingData Class and of course FileTracker Class.
This stuff doesn't seem to be documented anywhere, so I've had to figure this out based on trial and error and by staring at some example targets/xml/props files:
The reason the custom build step writes to the tlog file by hand is that Build|Clean - and probably its command line counterpart - scrapes the tlog files to find which files to delete. It seems to look for all files matching *.write.tlog, or maybe *.1.write.tlog, in the intermediate folder, read the list of file names in each, and delete the files named. So, if the custom build steps knows what its outputs are, it can simply record them in a tlog file, and interact with Build|Clean that way.
(You can try this out yourself - build your project, create some temp files, add your own tlog file to your project's intermediate folder containing the paths to the temp files, then do a Build|Clean. Your temp files will be deleted along with the usual build artefacts.)
In a tlog file, a file with no prefix is the name of an output file. These files are deleted when you do a Build|Clean.
A file with a ^ before it a comment, I think - perhaps obviously, Build|Clean doesn't touch any of these.
As for |, I've only seen it in comment lines, used to separate different file names. I suspect this is just a convention, and not some special syntax, since if you put multiple output files on line, separated by |, Build|Clean doesn't delete them.
The tlog file format is now documented here: https://learn.microsoft.com/en-us/visualstudio/extensibility/visual-cpp-project-extensibility?view=vs-2017#tlog-files
Read .tlog format
Read .tlog files (.read..tlog) contain information about source files and their dependencies.
A caret (^) at the beginning of a line indicates one or more sources. Sources that share the same dependencies are separated by a vertical bar (|).
Dependency files are listed after the sources, each on its own line. All file names are full paths.
The tlog file is generated by the file tracking system in MSBuild. It isn't specific to individual compilers, it can capture any file reference by anything done in the MSBuild process, depending on how it is configured.
Related
I am looking at using MSBUILD from a command line to run the schema compare (*.scmp)
Within the solution we have several databases and the team aren't always that great at remembering to check changes (stor procs, tables etc..) into the solution. Although Visual studio can show the comparison, I can't find a way of exporting the list of errors, for me to chase the team about. Screen shots seem to be the only way.
I thought That I would see if there were any tools in order to produce a list of differences. I came across an example on the following:
http://blogs.msdn.com/b/ssdt/archive/2014/07/15/msbuild-support-for-schema-compare-is-available.aspx
I saw this example:
C:\SampleProject > msbuild /t:SqlSchemaCompare /p:SqlScmpFilePath="d:\sc.scmp" /p:target="d:\target.dacpac" /p:TextOutput="d:\1.out" /p:Deploy="true
However I can't get it to work. When I run the equivalent against my particular set up I get:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(843,5): SchemaCompare error : The tar
get participant is invalid or empty. at Microsoft.Data.Tools.Schema.Tasks.Sql.SqlSchemaCompareTask.Execute() [C:\TFS\Argon_Main Solution_Latest R
elease\Source\Blah\SomeData.DataDatabase.sqlproj]
Has anyone got any ideas?
Cheers
I ran across this issue the other day. Turns out the problem was i needed to use the VisualStudioVersion command line argument.
msbuild /t:SqlSchemaCompare /p:VisualStudioVersion=14.0 /p:SqlScmpFilePath="MySchemaCompare.scmp" /p:target="MyConnectionString" /p:TextOutput="..\output.out"
Your Microsoft.Data.Tools.Schema.SqlTasks.targets file should be located at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\{Your VS Version}\SSDT
I realize it's been a while since this was asked, but I'll answer anyway.
Firstly, it's unclear to me what you're trying to compare exactly. Do you want to compare two versions of the project to see the differences, or are you comparing a project to a database?
One thing I noticed is that you're specifying the target twice in the command line. Firstly, the .scmp file referenced via the SqlScmpFilePath parameter contains a source and target. Secondly, the target parameter also defines a target. The target parameter will override whatever is in the .scmp file.
Maybe this is intentional, though, if your .scmp file has the right source but you want to specify the target in the .dacpac file.
The .dacpac file can be found in the bin\Debug or bin\Release folder of your SSDT project after a build. For your command to work, you'll need to make sure "d:\target.dacpac" exists and is such a file.
The .scmp file is created by doing a Schema Compare in Visual Studio and then saving the comparison window after selecting the source and target. For your command to work, you'll need to make sure that "d:\sc.scmp" exists and is such a file.
Please let me know if this helps.
A default install of Visual Studio 2013 creates intermediate and output files in the source tree. This is makes housekeeping harder - I can't just nuke a whole directory to get rid of intermediate files, for example. It also makes it easy to accidentally add a whole bunch of said junk to source control by mistake.
How do you tell VS to put the files elsewhere?
Open your proj file in a text editor, and look for something like this, depending on your platform/configuration:
<OutputPath>bin\x64\Release\</OutputPath>
Change it to whatever path you want it to be.
At build time the locations of these files comes from the $(IntDir) and $(OutDir) build variables. These are defined by shared property sheet entries - shared as in shared by all projects built on a system. Updating that shared property sheet to put them elsewhere is a little tedious but only has to be done once.
For example, to change them such that intermediate files are placed in D:\Obj and output files are placed in D:\Exe:
From the View menu, select PropertyManager.
Expand any project node, e.g. MyProject.
Expand any platform configuration node, e.g. Debug | Win32.
Open the Microsoft.Cpp.Win32.user property sheet.
Select the General section
Set the Intermediate Directory to (note the trailing backslash!)
D:\Obj\$(SolutionName)\$(ProjectName)\$(Platform)\$(Configuration)\
Set the Output Directory to (note the trailing backslash!)
D:\Exe\$(SolutionName)\$(ProjectName)\$(Platform)\$(Configuration)\
Repeat these steps for the remaining platform configuration nodes, e.g. Debug | x64
The property sheets are shared by different build types (e.g. debug, release) within a configuration, but not across platforms. This is why you have to repeat the steps for each platform (e.g. Win32 & x64). But you only have to do this for one project because they all use the same set of property sheets.
BEWARE!
There is a possible issue with this setup. Because the full drive and path is omitted from the directories, if you have more than one copy of a project/solution they will both try to write their output to the same location, possibly leading to horribleness.
I'm currently trying to make splint available as an external tool in Visual Studio 2010.
It has problems with finding all includes for the file, since it seems that the INCLUDE variable is only set at build time and I haven't found any other possibility to extract the include files in any way.
My question: Would there be any way to extract the IncludeDir field from the current file's project's Properties page, ideally with the VC++'s AdditionalIncludeDirectories?
Note also that AdditionalIncludeDirectories is per file, as it can be changed for individual source files as well as on the project level, and if it contains macros it can evaluate differently for each source file too!
I'm not familiar with driving the MSBuild objects via the API, but that's used by the IDE. Whether that way or by simply running MSBuild.exe, you need to get it to figure out all the properties, conditions, etc. and then tell you the result. If everything is well behaved, you could create a target that also uses the ClCompile item array and emits the %(AdditionalIncludeDirectories) metadata somehow such as writing it to a file or passing it to your other tool somehow. That's what's used to generate the /I parameters to CL, and you can get the same values.
If things are not well behaved in that necessary values are changed during the detailed build process, you would need to get the same prelims done just like the ClCompile target normally does, too. Or just override ClCompile with your own (last definition of a target is used) so it certainly is in the same context.
Either way, there are places where build script files can be automatically included into all projects, so you can add your stuff there or use a command argument (I think) to MSBuild to add another Include.
—John
I've created a custom build step in Visual Studio 2010 that produces multiple files by running a command-line tool. The step creates these files as it should when invoking a build, but on a clean, it only cleans the first file I listed as an output of the step in the "Outputs" field of the custom build step. I've separated individual files with a semicolon and also tried the multi-line editor for the field and put each file on a separate line (VS inserts the semicolons when closing the multi-line editor). In any case, it doesn't seem to be the format of the field that's the issue - whatever file is first gets cleaned, the rest don't.
From reading the documentation, it seems that you should be able to have multiple files listed as output so that the step can properly clean any artifacts it produces. Does anything special need to be done to clean multiple files or is this a bug?
If the temporary output file extension filter doesn't work (which seems to be your case), try making a script that checks if any files were generated from a previous build; if so, delete them, if not do nothing, then carry on with the script you normally use. Set this as a prebuild step.
I had a custom VS shell and I couldn't select the temporary file extensions in that shell and this was the only solution I could use at the time. (obviously, if you're in a hurry, you can just call rm or del and not worry about checking first).
If you're good at perl, try using that, if not just use a normal batch file.
If it is a bug that happens to a lot of people, maybe they'll fix it someday. Personally I use VS2008 just cos I don't trust VS2010.
I am building a cross platform product and one of the requirements is across windows(win32,AMD64 and IA61). The product as is relatively simple CLI but we have a separate build team who checks out the code from CVS and build in separate build environments. I am able to build succesfully(using Visual C++ 2005) in one platform(AMD machine). But once I check in the code, check out the build fails.
The cause of the build failure is because the include library paths are wrongly specified in the property sheets. Specifically the output file folder under the Linker in property pages are specified wrongly. So these libraries get built in a different folder from where the other projects are expecting them.
However along with the source I check in the .sln files (and later .vcproj files) also everytime. Morover if I open the .sln file in the folder where the build is not succeeding, there is no difference between the one where I could succesfully build(pre check in). In fact using windiff I could not see any difference between the two build folders (except some .ncb and cvs log files).
So any idea what is going on? Where does VC++ 2005 take the include directories take the output folder path from if not from .sln? Is CVS somehow interfering with the process? Anything else I could try out.
Thanks in advance.
Just to update the problem was resolved. The root cause is the .vcproj files were not getting checked in CVS!! This is where the individual project settings were stored(I was under the impression that this is done in .sln files).
I think the problem can be that after you have changed the settings in one build configuration (for example x86-Release) but forgotten to change them for another configuration (for example ia64-Debug), and when configuration changes, you have this problem.
Another thing that I would check on your place is project dependencies. If those are set in the right way VS will look for project output exactly where it is outputted, even when you change the output folder.
Do you have any binary files checked in as ASCII?
The round trip to and from CVS can corrupt binary files that are incorrectly marked as ASCII because CVS performs character processing on ASCII files (e.g. to give you the correct end of line codes for your OS). Corruption can occur even in an all Windows environment.
See the Binary section in the CVS FAQ for more information.