Common MSBuild project properties
- Common MSBuild project properties
- MSBuild .targets files
- Common MSBuild project properties
- MSBuild .targets files
- How to configure the intermediate output directory in C#
- MSBuild internals for C++ projects
-
%VSINSTALLDIR%MSBuild\Microsoft\VC\<version >\
Contains the primary target files (.targets) and property files (.props) that are used by the targets. By default, the $(VCTargetsPath) macro references this directory. The
placeholder refers to the Visual Studio version: v160 for Visual Studio 2019, v150 for Visual Studio 2017. -
%VSINSTALLDIR%MSBuild\Microsoft\VC\<version >\Platforms\<platform >\
Contains platform-specific target and property files that override targets and properties in its parent directory. This directory also contains a DLL that defines the tasks that are used by the targets in this directory. The <platform > placeholder represents the ARM, ARM64, Win32, or x64 subdirectory.
-
%VSINSTALLDIR%MSBuild\Microsoft\VC\<version >\Platforms\<platform>\PlatformToolsets\<toolset>\
Contains the directories that enable the build to generate C++ applications by using the specified
. The placeholder represents the ARM, ARM64, Win32, or x64 subdirectory. The placeholder represents the toolset subdirectory. - Move intermediates directory on C# projects in Visual Studio
- Advanced Property Page
- Migrating Projects Created with Visual Studio Versions Earlier than 2010
- How to set up C++ visual studio project
- Understanding the Clean target #2408
- How to configure the intermediate output directory in C#
- Visual Studio keeps adding property to my csproj. Why?
- Autogenerated IntermediateOutputPath in the .csproj file
- What's the goal of IntermediateOutputPath tag in the csproj? (I already checked MSDN documentation, but still not clear)
- How did Harry generat the code (because he doesn't know)?
- Is it possible to use a generic variable to get a file path that everybody could use? In the case, is this IntermediateOutputPath mandatory for the program to run?
Definitions from Microsoft
The following table lists frequently used properties that are defined in the Visual Studio project files or included in .targets files that MSBuild provides.
Project files in Visual Studio (.csproj, .vbproj, .vcxproj, and others) contain MSBuild XML code that runs when you build a project by using the IDE. Projects typically import one or more .targets files to define their build process. For more information, see MSBuild .targets files.
MSBuild includes several .targets files that contain items, properties, targets, and tasks for common scenarios. These files are automatically imported into most Visual Studio project files to simplify maintenance and readability.
Projects typically import one or more .targets files to define their build process. For example a C# project created by Visual Studio will import Microsoft.CSharp.targets which imports Microsoft.Common.targets. The C# project itself will define the items and properties specific to that project, but the standard build rules for a C# project are defined in the imported .targets files.
The following table lists frequently used properties that are defined in the Visual Studio project files or included in .targets files that MSBuild provides.
Project files in Visual Studio (.csproj, .vbproj, .vcxproj, and others) contain MSBuild XML code that runs when you build a project by using the IDE. Projects typically import one or more .targets files to define their build process. For more information, see MSBuild .targets files..
MSBuild includes several .targets files that contain items, properties, targets, and tasks for common scenarios. These files are automatically imported into most Visual Studio project files to simplify maintenance and readability.
Projects typically import one or more .targets files to define their build process. For example a C# project created by Visual Studio will import Microsoft.CSharp.targets which imports Microsoft.Common.targets. The C# project itself will define the items and properties specific to that project, but the standard build rules for a C# project are defined in the imported .targets files..
Material for My Articles
I'm trying to organize my workspace and want my intermediate objects to be put in the ..\build\obj folder in relation to my .csproj file. So I put:
in the .csproj file. The intermediate objects are now put in that location when the solution is built, but the problem is that an obj directory is still created in the directory the .csproj file is in (something to the effect of obj\Debug\TempPE) when the solution is opened. What is this directory for, and how can I relocate it?
A Solution: You could try to do this (don't forget that there are Debug and Release sections which will be used depending on what type of build you are targeting):
...
<BaseIntermediateOutputPath>..\build\obj </BaseIntermediateOutputPath >
<IntermediateOutputPath> $(BaseIntermediateOutputPath)$(Configuration)\ < /IntermediateOutputPath >
</PropertyGroup >
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " >
...
<BaseIntermediateOutputPath >..\build\obj </BaseIntermediateOutputPath >
<IntermediateOutputPath >$(BaseIntermediateOutputPath)$(Configuration)\ </IntermediateOutputPath >
</PropertyGroup >
When you set project properties in the IDE and then save the project, Visual Studio writes the project settings to your project file. The project file contains settings that are unique to your project. However, it doesn't contain all the settings required to build your project. The project file contains Import elements that include a network of additional support files. The support files contain the remaining properties, targets, and settings required to build the project.
Most targets and properties in the support files exist solely to implement the build system. This article discusses useful targets and properties you can specify on the MSBuild command line. To discover more targets and properties, explore the files in the support file directories.
Visual Studio 2019
This seems trivial with C++ projects as you can specify both the output and the intermediates directory. However with C#, at least through the Visual Studio 2008 User Interface it seems impossible to move the obj directory?
A Solution: If you add both of the following lines to each build configuration then the "obj" folder is not created by default and there is no need for a post-build action:
The Advanced property page is available in Visual Studio 2019 and later.
Migrating Projects Created with Visual Studio Versions Earlier than 2010
Start with a C++ empty project at a centralize location..
What Clean does and how?
That mental model doesn't capture the nuances of the current implementation of Clean, which is pretty complex.
The intuitive goal of the Clean target is to delete everything produced by previous non-clean runs. That goal is hard to achieve because the MSBuild engine doesn't have enough information to know what "the outputs of the build" are. A task implementation can create arbitrarily many files, and build input parameters or other state can cause different outputs to be produced.
To deal with that, the common targets implement an honor-system method of tracking the output of "the last build". Well-behaved targets emit their outputs into an item named @(FileWrites), which is serialized to $(CleanFile) in the obj directory (it ends with .FileListAbsolute.txt) in a target named _CleanRecordFileWrites. Clean can then read that list and delete files in it during a subsequent MSBuild invocation.
That is made more complicated by the possibility of incremental builds--builds that would have written a file, but it was up to date, so this build didn't do so. But you still want to delete those build outputs on Clean! So there's logic in common targets to preserve the list of files that were written last time, unless they really shouldn't be present any more (because you changed something). That's the AndPrior part of _CleanGetCurrentAndPriorFileWrites.
The next complicating factor is the possibility that multiple projects might be built to the same output directory. In that case, cleaning a single project should not delete the outputs of other projects. But it would, because some references get copied to the output folder. To account for this, there's a second item group @(FileWritesShareable). That list is treated specially: only items from it that are believed to be unique to this project are written to the $(CleanFile) for later deletion.
Basic Concepts and Definitions
I'm using Visual Studio 2012 RC to work with my C# solution. All my configuration-specific settings are stored within a single .props file which is then included by all my .csproj files.
Yet VS insists on putting this right in front of the include:
Those IntermediateOutputPath's can be inserted when MSBuild is given a bad path.
In our case, we had extra unnecessary slash after SolutionDir for output folders.
What wasn't working for us(note the extra slash):
What did work:
To help troubleshoot your particular case, try turning on diagnostic MSBuild output and logging under Tools->Options->Projects and Solutions->Build and Run-> MSBuild project build output verbosity. Then, search for the generated folder (ex. "Temp").
Using common proj/props/targets file is a great idea, but it does require fighting Visual Studio a little.
A Question:After updating the code from Git I have an error in the csproj, because the file path doesn't exist. Here is the code which initiates the error:
This filepath exists on Harry's computer, but not on mine. The guy with this name has no idea how he created this, so I assume Visual Studio created it. That's why I have three questions:
this post gives lot of definitions about these paths...
No comments:
Post a Comment