When I have an msbuild file foo.csproj and I want to Import a shared proj/targets file, how is the Project.InitialTargets attribute supposed (i.e. officially) to behave?
What I see with testing MSBUILD 2.0 and 4.x is that, given the following:
<Project InitialTargets="TestMain" ...>
...
<Import Project="Sub.targets"/>
...
<Target Name="TestMain">
<Message Text="Hello from Main" />
</Target>
and
<Project InitialTargets="TestSubInit" ...>
...
<Target Name="TestSubInit">
<Message Text="Hello from sub.targets" />
</Target>
then the InitalTargets are chained in order of inclusion, i.e. first the output is:
TestMain-Target:
Hello from Main
TestSubInit-Target:
Hello from sub.targets
I want to rely on this chaining behavior - is this documented somehow?
The chaining behaviour for the InitialTargets attribute is documented on the MSDN page for the <Project> element.
From the documentation:
If multiple imported files define InitialTargets, all targets
mentioned will be run, in the order the imports are encountered.
So, the ordering that you see seems to be documented.
Furthermore, the docs for the Import element state:
If the imported project does not have a DefaultTargets attribute,
imported projects are inspected in the order that they are imported,
... . For example, if ProjectA imports ProjectB and ProjectC (in that
order), and ProjectB imports ProjectD, MSBuild first looks for
DefaultTargets specified on ProjectA, then ProjectB, then ProjectD,
and finally ProjectC.
While this talks about the DefaultTargets attribute, it is a hint that the *Targets Attributes are treated in-order starting at the "main/"importing" project, so
... in the order the imports are encountered
would then mean that the "main" file is just put at the start of the "imports" list. (Which is what is observed.)
Related
I have a file named Common.targets defined like so:
<Project>
<PropertyGroup>
<TlbExpPath>"c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\tlbexp"</TlbExpPath>
<TlbOutPath>"$(OutDir)..\TLB\$(TargetName).tlb"</TlbOutPath>
</PropertyGroup>
<Target Name="TlbExp" AfterTargets="CopyFilesToOutputDirectory" Inputs="$(TargetPath)" Outputs="$(TlbOutPath)">
<Exec Command='$(TlbExpPath) "$(TargetPath)" /nologo /win64 /out:$(TlbOutPath) /verbose' />
</Target>
</Project>
When I inspect the output of the TlbOutPath property, it looks like:
"..\TLB\.tlb"
Apparently, $(OutDir) and $(TargetName) produce nothing when used within a PropertyGroup. I'm not sure why. How can I make these paths/values reusable while still having access to built-in properties when they are defined?
I'm using MSBuild that comes bundled with Visual Studio 2019. I add an Import element to my actual .csproj projects to include this target where I need it. The csproj projects use the SDK format for the projects, e.g. <Project Sdk="Microsoft.NET.Sdk">.
Here is an example of what the import looks like:
<Project Sdk="Microsoft.NET.Sdk">
<!-- etc -->
<ItemGroup>
<Reference Include="Microsoft.CSharp" />
<!-- etc -->
</ItemGroup>
<Import Project="$(RepositoryRoot)\Common.targets" />
</Project>
MSBuild: How may I access built-in properties while defining my own
custom properties?
This is quite an issue in the new sdk format project. I have tested it and got the same issue as you said which quite bother me a lot. Like $(OutDir),$(TargetName),$(OutputPath),$(TargetPath) and some other common system properties cannot be used in a new property while $(Configuration) and $(AssemblyName) works well.
And not only us but also someone else also face the same issue about it.See this thread.
For the traditional old csproj format project, there was no problem with these properties being used this way, but in the new SDK format project, it is impossible to assign some common properties such as $(OutDir),$(TargetName) and $(TargetPath) to a new property. As we know, most of the common properties are defined in the Microsoft.Common.props file(old csproj format) which is quite different from the new sdk format project which does not have such file.
In order to get an answer,l have reported this issue to DC Forum. See this.You can enter this link and add any detailed comments to describe this issue. And anyone who interested in this issue will also vote it so that it will get more Microsoft staff's attention. All these efforts will speed up and get the final answer.
This process may take a while or you could try my suggestion.
Suggestion
1) You can customize this property $(OutDir) in Common.targets file, and use $(TargetFramework) instead of $(TargetName) since $(TargetFramework) is defined in the xxxx.csproj file.
<Project>
<PropertyGroup>
<OutDir>bin\$(Configuration)\$(TargetFramework)\$(AssemblyName)\</OutDir>
<TlbExpPath>"c:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\tlbexp"</TlbExpPath>
<TlbOutPath>"$(OutDir)..\TLB\$(TargetName).tlb"</TlbOutPath>
<TargetPath>xxxx\xxxx.dll(exe)</TargetPath>--------the absolute path of the output file
</PropertyGroup>
<Target Name="TlbExp" AfterTargets="CopyFilesToOutputDirectory" Inputs="$(TargetPath)" Outputs="$(TlbOutPath)">
<Exec Command='$(TlbExpPath) "$(TargetPath)" /nologo /win64 /out:$(TlbOutPath) /verbose' />
</Target>
</Project>
2) use Directory.Build.targets file rather than a custom targets file.
A) You should add a file named Directory.Build.targets(it must be named this and have its own rule to be imported into xxx.csproj) under the project folder.
B) add the content of Common.targets into it without any changes and then build your project directly. The Directory.Build.targets will be imported into your project automatically while build.
This function works well and will not lose any properties. However, l stil bother why it works.
Conclusion
I think #2 is more suitable and easier for you to achieve your goal.
is there a way to use an Import directive in msbuild such that the value of the Project property is a variable, and that variable is defined in a target?
As it stands, it seems to me that Import directives are evaluated before any targets.
For instance:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PublishDir>none</PublishDir>
<AutomatedTestsTarget>none</AutomatedTestsTarget>
</PropertyGroup>
<Target Name="GetPublishDir">
...
</Target>
<Target Name="BeforeCompile" DependsOnTargets="GetPublishDir">
<PropertyGroup>
<AutomatedTestsTarget>$(PublishDir)\automated_tests.build</AutomatedTestsTarget>
</PropertyGroup>
</Target>
<Import Project="$(AutomatedTestsTarget)"/>
</Project>
Frankensolution
Quick solution (as per comment), two msbuild calls, first writes a file. Second does the import this way (by reading the path from the file):
<PropertyGroup>
<AppRootDir>$([System.IO.File]::ReadAllText($(MSBuildProjectDirectory)\directory.txt))\..\automation\</AppRootDir>
</PropertyGroup>
No. Imports happen during the "evaluation phase", and not the "execution phase".
During the evaluation phase of a build... imported files are incorporated into the build in the order in which they appear... Properties are defined and modified in the order in which they appear.
http://msdn.microsoft.com/en-us/library/dd997067.aspx
You may be able to split your configuration gathering & execution into separate msbuild projects, with one calling the other.
ie: Generate targets with MSBuild then import them in same session
Solution1.sln contains two projects:
ProjectA.csproj
ProjectB.csproj
ProjectB has a custom target called "Foo". I want to run:
msbuild Solution1.sln /t:Foo
This will fail because ProjectA doesn't define the "Foo" target.
Is there a way to make the solution ignore the missing target? (E.g., do nothing if the target doesn't exist for a specific project) without modifying the SLN or project files?
There is a two-part solution if you don't want to edit the solution or project files and you're happy for it to work from MSBuild command-line but not from Visual Studio.
Firstly, the error you get when you run:
MSBuild Solution1.sln /t:Foo
Is not that ProjectA does not contain a Foo target but that the solution itself does not contain a Foo target. As #Jaykul suggests, setting the MSBuildEmitSolution environment variable will reveal the default targets contained within the solution metaproj.
Using the metaproj as inspiration you can introduce a new file "before.Solution1.sln.targets" next to the solution file (the file name pattern is important) with contents like this:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Foo">
<MSBuild Projects="#(ProjectReference)" Targets="Foo" BuildInParallel="True" Properties="CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)" />
</Target>
</Project>
The MSBuild element is mostly just copied from the solution metaproj's Publish target. Adjust the target name and any other details to suit your scenario.
With this file in place, you'll now get the error that ProjectA does not contain the Foo target. ProjectB may or may not build anyway depending on inter-project dependencies.
So, secondly, to solve this problem we need to give every project an empty Foo target which is then overridden in projects that actually already contain one.
We do this by introducing another file, eg "EmptyFoo.targets" (name not important) that looks like this:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Foo" />
</Project>
And then we get every project to automatically import this targets file either by running MSBuild with an extra property, eg:
MSBuild Solution1.sln /t:Foo /p:CustomBeforeMicrosoftCommonTargets=c:\full_path_to\EmptyFoo.targets
Or include the CustomerBeforeMicrosoftCommonTargets property in the Properties attribute on the MSBuild element in the first targets file where you could optionally specify the full path relative to the $(SolutionDir) property.
However, if you're willing to run Foo in conjunction with any of the default solution targets (ie Build, Rebuild, Clean, or Publish) you could take some inspiration for how the Web Publishing Pipeline in MSBuild uses the DeployOnBuild property to call the Publish target on Web projects in a solution containing other project types that don't support publishing.
More info on the before.Solution1.sln.targets file here:
http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
You can target those by project name, like /t:project:target (might need quotes, I can't remember).
You can find all the generated targets by setting the environment variable MSBuildEmitSolution = 1 ... which causes msbuild to save to disk the temp .metaproj file which it generates for your solution. That file has all those targets defined in it, just open it up and take a look ;)
Maybe not the best answer but a reasonable hack.
msbuild ProjectA.csproj
msbuild ProjectB.csproj /t:Foo
When msbuild building solution - msbuild emits only limited set of targets into it's .metaproj file, and afaik - you can't build custom target through building sln file, you have to use original project1.csproj or custom build script.
Just for reference:
Use ContinueOnError when using MSBuildTask or -p:ContinueOnError=ErrorAndContinue when using (dotnet) msbuild
It may be in limited scenarios helpful: For example you have a list of .csproj files and want attach metadata only to specific project file items then you could write something like this:
<Target Name="UniqueTargetName" Condition="'$(PackAsExecutable)' == 'Package' Or '$(PackAsExecutable)' == 'Publish'" Outputs="#(_Hello)">
<ItemGroup>
<_Hello Include="$(MSBuildProjectFullPath)" />
</ItemGroup>
</Target>
<Target Name="BuildEachTargetFramework" DependsOnTargets="_GetTargetFrameworksOutput;AssignProjectConfiguration;_SplitProjectReferencesByFileExistence"
Condition="$(ExecutableProjectFullPath) != ''">
<Message Text="[$(MSBuildThisFilename)] Target BuildEachTargetFramework %(_MSBuildProjectReferenceExistent.Identity)" Importance="high" />
<MSBuild
Projects="%(ProjectReferenceWithConfiguration.Identity)"
Targets="UniqueTargetName"
ContinueOnError="true">
<Output TaskParameter="TargetOutputs" ItemName="_Hallo2" />
</MSBuild>
<Message Text="[$(MSBuildThisFilename)] ########### HELLO %(_Hallo2.Identity)" Importance="high" />
</Target>
I have a project structure that looks like this:
Parent
-- ChildProjects1
-- ChildProjects2
-- ChildProjects3
I have an msbuild file under each ChildProjects node that builds the relevant projects, creates zip files, tags them in subversion etc
However most of this logic is common between ChildProjects. I'm wondering if I can refactor this common logic to sit in another msbuild file at the parent level and have each child inherit this?
Any ideas on this appreciated.
You can put common Targets inside an a file that you include using the following syntax, you will also see it in your proj files:
<Import Project="path to file.targets"/>
Things to note:
The convention is to use a .targets extension but it doesn't matter.
Where you place the import is important depending on if you want to be able to override properties or targets in the imported targets file.
Targets are not like methods, you cannot call them more than once but you can influence the order in which they are called.
If you require reusable chunks that you want to call multiple times create a custom task library but check out the MSBuildExtensionPack first to see if it has what you want.
Call Target
In relation to the question about CallTarget. CallTarget will invoke the specified target(s) the same way that DependsOnTargets, BeforeTargets and AfterTargets do. The target will only be run if it has not already been run. See the following example:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Foo">
<Target Name="Foo" DependsOnTargets="Bar">
<Message Text="Foo" />
<CallTarget Targets="Bar" />
<CallTarget Targets="Bar" />
</Target>
<Target Name="Bar" AfterTargets="Foo" BeforeTargets="Foo">
<Message Text="Bar" />
</Target>
</Project>
Which will output the following:
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18449]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 24/02/2014 12:06:59.
Project "D:\Dev\Test.proj" on node 1 (default targets).
Bar:
Bar
Foo:
Foo
Done Building Project "D:\Dev\Test.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.69
Can someone please point me to a reference about target hooks in MSBuild?
I'm looking for something that will let me define targets to run before and after a specified target. I know this can be done using the DependsOnTargets property but I've seen references to using target hooks and I'd like to explore that area.
Thanks,
Zain
A good list of built-in overridable build process hooks can be found here. For custom targets, the only thing I can think of is to use either the DependsOnTarget attribute (like you mentioned) or the BeforeTargets/AfterTargets attribute (like #Ritch Melton mentioned.) Be careful, the BeforeTargets/AfterTargets are only available in MSBuild 4.0
If you understand the idea behind DependsOnTargets then open up the Microsoft.Common.targets file in the .Net SDK directory (C:\Windows\Microsoft.NET\Framework\v3.5). That file defines the build process for the MSBuild task and .Net projects created by Visual Studio. Look for tags called BeforeXXXX, and AfterXXXX. BeforeBuild and AfterBuild are referenced in the default.csproj file - Snippet:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<!-- To modify your build process, add your task inside one of the targets below and uncomment it. Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->
</Project>
There are others, like Clean, Rebuild, etc..
Define a Target (or Targets) to execute inside those Target elements, like this (Creates a directory, or list of directories based on the value in the Directories Property:
<Target Name="CreateDir">
<MakeDir Directories="D:\Dogs.txt"/>
</Target>
Then include those Targets in the BeforeXXX Target:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="BeforeBuild" BeforeTargets="CreateDir">
</Target>
</Project>