I'm following many blog/StackOv posts to make this. Still I get blue lines. And my vedlegg folder is deleted.
I'm using MSBuild for publishing from command line.
In most cases you can safely ignore squiggly lines in MSBuild file. The XSD files that Visual Studio uses for MSBuild only support subset of MSBuild syntactical expressions. Most of the properties, groups and metadata for standard targets are reflected there, but not any custom build elements.
You can interpret the squigglies as anything that is outside of standard MSBuild properties and tasks. I also notices in many cases even standard tasks and properties are not present in XML schema for MSBuild files supplied by Microsoft, which is an obvious bug, but there is very little useful you can get from those XSD files anyway.
Related
I'm looking for a way to call MSBuild with all possible configurations/platforms defined in the solution file.
I've looked here:
Using MSBuild to Build Multiple Configurations
which requires explicit knowledge of the configurations, as you must enumerate them on the command line,
and here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/066c9dbf-d191-4b8c-8ee1-b9709b56c500/msbuild-for-visual-studio-2010-build-all-configurations-of-a-vcxproj-file?forum=msbuild
which leads to another page that suggests defining another project file to encapsulate the msbuild calls. Unfortunately, it too requires explicit knowledge of the configurations.
So then, is there any way to obtain through the command line, the list of configurations/platforms availalbe to a given project? (It must be the same list that is modified in Visual Studio. ie: adding/removing a configuration in Visual Studio, saving, exiting, and getting the list, would reflect the changes.)
Parsing the solution file as XML is not an option, as it wouldn't be stable if Microsoft decided to change how it is formatted.
You can't parse a solution as XML it's not a markup file without having MSBuild emitting a meta project first. I recommend you play the odds and be pragmatic, read the .sln as a text file and RegEx it on SolutionConfigurationPlatforms pairs, then build the ItemGroup and batch it. If you are truly utterly paranoid about Microsoft completely reengineering the solution file syntax then look inside Microsoft.Build.Construction and/or .Evaluation, the internal SolutionParser, or Roslyn or even Mono since if the syntax changes then those parsers and loaders would be updated accordingly and in case of Microsoft.Build and Roslyn -- simultaneously.
I have a project in Visual Studio(VS). I'm trying to build this project into 2 executable. The executable merely differ by a pre-processor definition.
Creating multiple projects with different build options, is an option. But the projects has many files put in different folders. Plus the differences are really small. So I'd rather not do this at least for now.
Taken from here, another way of doing this would be to write a batch file that uses cl.exe to get the job done. However the problem with this is that cl takes source files as input and not the project file which means this is even worse than the previous solution. And the higher level devenv.exe which takes projects as input does not have an option to pass in preprocessor definitions.
Note:
A major downside of using any of the above approaches would be that I'd have to reconfigure if any files is added or removed from the original project.
Id suggest using same solution with 2 Build configurations and ruining MSBuild for each configuration.
MSBuild.exe your.sln /t:Rebuild /p:Configuration=Release1;Platform=AnyCPU
MSBuild.exe your.sln /t:Rebuild /p:Configuration=Release2;Platform=AnyCPU
Combined with Property Sheets is would be relatively simple way to build and maintain.
I've just learned the hard way that Visual Studio 2010 and MSBuild extremely lenient when it comes to which vcxproj MSBuild files they will successfully execute - they will overlook missing configurations for subtasks and single files and still successfully execute the build tasks. However this is causing problems for me as it is leading to inconsistent builds across multiple configurations, plus due to the internal inconsistencies in the project files I cannot necessarily edit them in Visual Studio's property view.
So far I have managed to get rid of the most problematic inconsistencies by editing the vcxproj files by hand but this is not really an acceptable strategy given that this particular solution contains over 80 project files.
Is there a tool that can check an MSBuild file for internal consistency and highlight missing configurations along the lines of "your project files says it offers configurations X, Y and Z but the custom build task for file X only supports configurations X and Z"?
Update: The specific problem I am trying to solve right now as opposed to the more general problem of linting the vcxproj file is that of missing conditionals for certain configurations. Unfortunately adding and updating the conditionals seems to require a little more than I can safely accomplish using a find-and-replace tool. Doing it programmatically and correctly would most likely require DOM manipulation and given that I am rather familiar with the internal structure of the build files so far it appears that using a text editor that is able to do basic structural XML validation is the quickest way to accomplish the task at hand.
What I would really like to see however would be a tool that can at least highlight these problems automatically to cut down on the time spent tracking them down.
Configurations are, in general, a VS concept. They are not built-in to MSBuild but achieved using Conditional attributes on property groups. Most likely your project files are valid MSBuild projects, but some of them don't build with default parameters - I'd suggest not to edit them by hand, but either
use a find-and-replace tool to fix them
write a small app that uses Microsoft.Build.Construction API to inspect and fix the project files
There's nothing that would perform this for you, I'm afraid.
This request is currently tracked under https://github.com/dotnet/msbuild/issues/1777
This is not a real answer yet, but as soon as the issue gets resolved to a tangible solution, I'll update it here.
I have a csproj file, being part of two different Visual Studio solutions. The project file should be able to behave slightly different, depending on the solution it will be used from. What I would need, is something usable as a 'Condition' - a property named for example $(SolutionName) - filled in automagically.
At least, this is my idea. I didn't found anything like that.
I also considered to have two small project files importing the common parts. This would prevent editing all these properties from inside Visual Studio, I guess. It would write changes only in the active 'master file', correct?
So, is there any other way to discriminate at project level using solution information?
Turns out there is a property named exactly $(SolutionName). Try this; first set an environment variable as:
> set MSBuildEmitSolution=1
Then build your solution file using MSBuild from the same command line
> MSBuild My.sln
You will find the MSBuild project transformation of your solution file, it will be named My.sln.metaproj.
Just open that in a text editor and you can see the other properties. Examine the "Build" target in this projectd file, you can see that all these properties are passed in to the MSBuild task when it builds your projects, so you should be able to discriminate conditions based on any of them.
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.