I'm implementing an MSBuild framework to drive the building and deployment of many projects organized as a hierarchy.
<Target Name="_CoreBuild">
<MSBuild Projects="#(Project)" Targets="Build" Properties="Configuration=$(Configuration)">
<Output TaskParameter="TargetOutputs" ItemName="CompiledAssemblies" />
</MSBuild>
</Target>
In order to implement proper Clean/Clobber logic, I would like to retrieve the list of files that would be compiled if a build were performed with the current options.
<Target Name="_CoreClobber" DependsOnTargets="_CoreClean">
<!-- How to retrieve #(CompiledAssemblies) as if we were
building #(Project) and retrieving the #(TargetOutputs) item group.
-->
</Target>
I've tried various methods, including creating a custom task, in which I build a custom project file that imports the original project I want to retrieve the properties/items from. But that does not give me reliable values.
Is there a way to retrieve an MSBuild project's TargetOutputs item group without actually performing a build?
Never mind.
I stumbled upon the following similar question, and figured I had to use the GetTargetPath target, like so:
<Target Name="_CoreBuild">
<MSBuild Projects="#(Project)" Targets="GetTargetPath" Properties="Configuration=$(Configuration)">
<Output TaskParameter="TargetOutputs" ItemName="CompiledAssemblies" />
</MSBuild>
</Target>
Related
I am having a target which will build then checkin the assemblies.
<Target Name="CoreBuildCheckinSubSystem" DependsOnTargets="BuildDotNETSolutions;CheckinSubSystemDos">
</Target>
In this builddotnetSolution will build the list of solution in an order. So i do not want it to be buildinParallel but the CheckinSubsystemDos will checkin all the dlls. If the checkin process is being done in parallel it would save time for me.
How to make CheckinSubSystemDos alone in BuildInParallel?
An important thing to note about MSBuild, is that parallelization is done on the level of project. Targets within the same project are always executed sequentially, while two different project might (or might not) be executed in parallel. To rephrase it another way, if you want MSBuild to execute something concurrently, you have to create multiple projects and invoke them within the same <MSBuild> task.
In your case, the code would look like this. You have a list of projects or solutions to build:
<ItemGroup>
<MyProjects Include="One.proj"/>
<MyProjects Include="Two.proj"/>
<MyProjects Include="Three.proj"/>
</ItemGroup>
The build target would invoke <MSBuild> target sequentially:
<Target Name="BuildDotNETSolutions" ...>
<MSBuild Projects="#(MyProjects)" Targets="Build" BuildInParallel="false" />
</Target>
Your checkin target would invoke another target that is defined in the same projects -- call it MyCheckin:
<Target Name="CoreBuildCheckinSubSystem" DependsOnTargets="BuildDotNETSolutions;CheckinSubSystemDos">
<MSBuild Projects="#(MyProjects)" Targets="MyCheckin" BuildInParallel="true" />
</Target>
Another option for you is to create a sibling set of projects -- call it MyCheckinProjects and use them in you checkin target:
<ItemGroup>
<MyCheckinProjects Include="Checkin_One.proj"/>
<MyCheckinProjects Include="Checkin_Two.proj"/>
<MyCheckinProjects Include="Checkin_Three.proj"/>
</ItemGroup>
However I would suggest simply inserting a new target into existing projects.
I'm trying to select a list of test dlls that contain corresponding config files
MyTest.Tests.dll
MyTest.Tests.config
I have to use a createItem as the dlls are not available at the time of the script loading
<CreateItem Include="$(AssemblyFolder)\*.Tests.dll"
Condition="???"
<Output TaskParameter="Include" ItemName="TestBinariesWithConfig"/>
</CreateItem>
Is there a condition I can use or is this the wrong approach?
Thanks
Mac
EDIT:
ok, to clarify, I need to construct a xUnit.Net project file. I need to do this because I'm running the tests through the xUnit.Console runner via nCover (don't ask!) but the long and short of it is I can only use a project file. The problem I'm having is when I have a test dll with an associated .config file. Without the config file, the test runner will fail.
This means I need to conditionally add an extra attribute (config-file) in the test project file.
The project template file:
<?xml version="1.0" encoding="utf-8"?>
<xunit>
<assemblies>
<!-- SAMPLE <assembly filename="Tests.dll" shadow-copy="false" config-file="Tests.dll.config" /> -->
<!-- #TARGETS# -->
</assemblies>
</xunit>
The FileUpdate task for the test dlls with no config file.
<FileUpdate
Files="$(AssemblyFolder)\$(XUnitProjectFileName)"
Regex="<!-- #TARGETS# -->"
ReplacementText="<!-- #TARGETS# -->%0D%0A<assembly filename='$(AssemblyFolder)\%(TestBinaries.FileName)%(TestBinaries.Extension)' shadow-copy='false' />"
/>
So I need a way to conditionally add the extra attribute in the FileUpdate task depending on whether there is a corresponding config file for the test dll.
You could just use the MSBuild Task output as a source for your CreateItem Task.
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ProjectReferences Include="*.*proj" />
</ItemGroup>
<Target Name="BuildMyProjects">
<MSBuild
Projects="#(ProjectReferences)"
Targets="Build">
<Output
TaskParameter="TargetOutputs"
ItemName="AssembliesBuiltByChildProjects" />
</MSBuild>
</Target>
<Target Name="AddConfigMetadata" DependsOnTargets="BuildMyProjects">
<CreateItem
Include="#(AssembliesBuiltByChildProjects)"
AdditionalMetadata="config-file=%(Identity).config">
<Output
TaskParameter="Include"
ItemName="MySourceItemsWithMetadata" />
</CreateItem>
</Target>
<Target Name="WhatEverYouLikeToDo" DependsOnTargets="AddConfigMetadata">
<Message Text="%(MySourceItemsWithMetadata.config-file)" />
</Target>
</Project>
Your problem discription isn't really clear to me, but your .Tests.dll's should always be available because you should build your project first before testing it. Whenever you've build your project, you can run the CreateItem task. The CreateItem is a good approach to retrieve the .dll's but you don't need a condition for it.
So in your build file you should have something like this:
- Build project/solution
-> .dll's will be created
- Execute CreateItem
- Do something with the Item
With this awnser I'm assuming you're trying to automate your tests?
As part of a solution containing many projects, I have a project that references (via a <ProjectReference> three other projects in the solution, plus some others). In the AfterBuild, I need to copy the outputs of 3 specific dependent projects to another location.
Via various SO answers, etc. the way I settled on to accomplish that was:
<MSBuild
Projects="#(ProjectReference)"
Targets="Build"
BuildInParallel="true"
Condition="'%(Name)'=='ProjectA' OR '%(Name)'=='ProjectB' OR '%(Name)'=='ProjectC'">
<Output TaskParameter="TargetOutputs" ItemName="DependentAssemblies" />
</MSBuild>
<Copy SourceFiles="#(DependentAssemblies)" DestinationFolder="XX" SkipUnchangedFiles="true" />
However, I ran into problems with this. The <MSBuild step's IncrementalClean task ends up deleting a number of the outputs of ProjectC. When running this under VS2008, a build.force file being deposited in the obj/Debug folder of ProjectC which then triggers ProjectC getting rebuilt if I do a Build on the entire solution if the project containing this AfterBuild target, whereas if one excludes this project from the build, it [correctly] doesn't trigger a rebuild of ProjectC (and critically a rebuild of all dependents of ProjectC). This may be VS-specific trickery in this case which would not occur in the context of a TeamBuild or other commandline MSBuild invocation (but the most common usage will be via VS so I need to resolve this either way)
The dependent projects (and the rest of the solution in general) have all been created interactively with VS, and hence the ProjectRefences contain relative paths etc. I've seen mention of this being likely to causing issues - but without a full explanation of why, or when it'll be fixed or how to work around it. In other words, I'm not really interested in e.g. converting the ProjectReference paths to absolute paths by hand-editing the .csproj.
While it's entirely possible I'm doing something stupid and someone will immediately point out what it is (which would be great), be assured I've spent lots of time poring over /v:diag outputs etc. (although I havent tried to build a repro from the ground up - this is in the context of a relatively complex overall build)
As noted in my comment, calling GetTargetPath on the referenced project only returns the Primary output assembly of that project. To get all the referenced copy-local assemblies of the referenced project it's a bit messier.
Add the following to each project that you are referencing that you want to get the CopyLocals of:
<Target
Name="ComputeCopyLocalAssemblies"
DependsOnTargets="ResolveProjectReferences;ResolveAssemblyReferences"
Returns="#(ReferenceCopyLocalPaths)" />
My particular situation is that I needed to recreate the Pipeline folder structure for System.AddIn in the bin folder of my top level Host project. This is kinda messy and I was not happy with the MSDN suggested solutions of mucking with the OutputPath - as that breaks on our build server and prevents creating the folder structure in a different project (eg a SystemTest)
So along with adding the above target (using a .targets import), I added the following to a .targets file imported by each "host" that needs the pipeline folder created:
<Target
Name="ComputePipelineAssemblies"
BeforeTargets="_CopyFilesMarkedCopyLocal"
Outputs="%(ProjectReference.Identity)">
<ItemGroup>
<_PrimaryAssembly Remove="#(_PrimaryAssembly)" />
<_DependentAssemblies Remove="#(_DependentAssemblies)" />
</ItemGroup>
<!--The Primary Output of the Pipeline project-->
<MSBuild Projects="%(ProjectReference.Identity)"
Targets="GetTargetPath"
Properties="Configuration=$(Configuration)"
Condition=" '%(ProjectReference.PipelineFolder)' != '' ">
<Output TaskParameter="TargetOutputs"
ItemName="_PrimaryAssembly" />
</MSBuild>
<!--Output of any Referenced Projects-->
<MSBuild Projects="%(ProjectReference.Identity)"
Targets="ComputeCopyLocalAssemblies"
Properties="Configuration=$(Configuration)"
Condition=" '%(ProjectReference.PipelineFolder)' != '' ">
<Output TaskParameter="TargetOutputs"
ItemName="_DependentAssemblies" />
</MSBuild>
<ItemGroup>
<ReferenceCopyLocalPaths Include="#(_PrimaryAssembly)"
Condition=" '%(ProjectReference.PipelineFolder)' != '' ">
<DestinationSubDirectory>%(ProjectReference.PipelineFolder)</DestinationSubDirectory>
</ReferenceCopyLocalPaths>
<ReferenceCopyLocalPaths Include="#(_DependentAssemblies)"
Condition=" '%(ProjectReference.PipelineFolder)' != '' ">
<DestinationSubDirectory>%(ProjectReference.PipelineFolder)</DestinationSubDirectory>
</ReferenceCopyLocalPaths>
</ItemGroup>
</Target>
I also needed to add the required PipelineFolder meta data to the actual project references. For example:
<ProjectReference Include="..\Dogs.Pipeline.AddInSideAdapter\Dogs.Pipeline.AddInSideAdapter.csproj">
<Project>{FFCD0BFC-5A7B-4E13-9E1B-8D01E86975EA}</Project>
<Name>Dogs.Pipeline.AddInSideAdapter</Name>
<Private>False</Private>
<PipelineFolder>Pipeline\AddInSideAdapter\</PipelineFolder>
</ProjectReference>
Your original solution should work simply by changing
Targets="Build"
to
Targets="GetTargetPath"
The GetTargetPath target simply returns the TargetPath property and doesn't require building.
You may protect your files in ProjectC if you call a target like this first:
<Target Name="ProtectFiles">
<ReadLinesFromFile File="obj\ProjectC.csproj.FileListAbsolute.txt">
<Output TaskParameter="Lines" ItemName="_FileList"/>
</ReadLinesFromFile>
<CreateItem Include="#(_DllFileList)" Exclude="File1.sample; File2.sample">
<Output TaskParameter="Include" ItemName="_FileListWitoutProtectedFiles"/>
</CreateItem>
<WriteLinesToFile
File="obj\ProjectC.csproj.FileListAbsolute.txt"
Lines="#(_FileListWitoutProtectedFiles)"
Overwrite="true"/>
</Target>
My current workaround is based on this SO question, i.e, I have:
<ItemGroup>
<DependentAssemblies Include="
..\ProjectA\bin\$(Configuration)\ProjectA.dll;
..\ProjectB\bin\$(Configuration)\ProjectB.dll;
..\ProjectC\bin\$(Configuration)\ProjectC.dll">
</DependentAssemblies>
</ItemGroup>
This however will break under TeamBuild (where all the outputs end up in one directory), and also if the names of any of the outputs of the dependent projects change.
EDIT: Also looking for any comments on whether there's a cleaner answer for how to make the hardcoding slightly cleaner than:
<PropertyGroup>
<_TeamBuildingToSingleOutDir Condition="'$(TeamBuildOutDir)'!='' AND '$(CustomizableOutDir)'!='true'">true</_TeamBuildingToSingleOutDir>
</PropertyGroup>
and:
<ItemGroup>
<DependentAssemblies
Condition="'$(_TeamBuildingToSingleOutDir)'!='true'"
Include="
..\ProjectA\bin\$(Configuration)\ProjectA.dll;
..\ProjectB\bin\$(Configuration)\ProjectB.dll;
..\ProjectC\bin\$(Configuration)\ProjectC.dll">
</DependentAssemblies>
<DependentAssemblies
Condition="'$(_TeamBuildingToSingleOutDir)'=='true'"
Include="
$(OutDir)\ProjectA.dll;
$(OutDir)\ProjectB.dll;
$(OutDir)\ProjectC.dll">
</DependentAssemblies>
</ItemGroup>
I'm trying to make a reusable target in my MSBuild file so I can call it multiple times with different parameters.
I've got a skeleton like this:
<Target Name="Deploy">
<!-- Deploy to a different location depending on parameters -->
</Target>
<Target Name="DoDeployments">
<CallTarget Targets="Deploy">
<!-- Somehow indicate I want to deploy to dev -->
</CallTarget>
<CallTarget Targets="Deploy">
<!-- Somehow indicate I want to deploy to testing -->
</CallTarget>
</Target>
But I can't work out how to allow parameters to be passed into the CallTarget, and then in turn the Target itself.
MSBuild targets aren't designed to receive parameters. Instead, they use the properties you define for them.
<PropertyGroup>
<Environment>myValue</Environment>
</PropertyGroup>
<Target Name="Deploy">
<!-- Use the Environment property -->
</Target>
However, a common scenario is to invoke a Target several times with different parameters (i.e. Deploy several websites). In that case, I use the MSBuild MSBuild task and send the parameters as Properties:
<Target Name="DoDeployments">
<MSBuild Projects ="$(MSBuildProjectFullPath)"
Properties="VDir=MyWebsite;Path=C:\MyWebsite;Environment=$(Environment)"
Targets="Deploy" />
<MSBuild Projects ="$(MSBuildProjectFullPath)"
Properties="VDir=MyWebsite2;Path=C:\MyWebsite2;Environment=$(Environment)"
Targets="Deploy" />
</Target>
$(MSBuildProjectFullPath) is the fullpath of the current MSBuild script in case you don't want to send "Deploy" to another file.
You can 'foreach' over an ItemGroup with a target, only you have to do it in declaritive manner. You can even have additional metadata in items, like in the code example:
<ItemGroup>
<What Include="Dev">
<How>With bugs</How>
</What>
<What Include="Test">
<How>With tests</How>
</What>
<What Include="Chicken">
<How>Deep fried</How>
</What>
</ItemGroup>
<Target Name="Deploy">
<Message Text="#(What), %(How)" />
</Target>
Using an item group as a scalar value #(What) inside a target does the trick, and %(How) references a metadata element in a foreach item.
It's a natural way of doing things in msbuild, for example you can find this pattern everywhere in project files generated with Visual Studio.
There might be a better way to do this in MSBuild, but in Ant, I would use global properties to carry information from one task to the next. It was a lousy solution, but I didn't see a better way at the time. You should be able to do this in MSBuild, but bear in mind that you will need to use the CreateProperty task to dynamically assign a property.
On the other hand, it's pretty easy to implement tasks in C# (or VB or whatever). Maybe that's a better solution for you.
<CreateProperty
Value="file1">
<Output
TaskParameter="Value"
PropertyName="filename" />
</CreateProperty>
<CallTarget Targets="Deploy"/>
<Message Text="$(filename)"/>
<CreateProperty
Value="file2">
<Output
TaskParameter="Value"
PropertyName="filename" />
</CreateProperty>
<Message Text="$(filename)"/>
<CallTarget Targets="Deploy"/>
In MSBuild, I would like to call a task that extracts all the files in all the project in a specific solution and hold these files in a property that can be passed around to other tasks (for processing etc.)
I was thinking something along the lines of:
<ParseSolutionFile SolutionFile="$(TheSolutionFile)">
<Output TaskParameter="FilesFound" ItemName="AllFilesInSolution"/>
</ParseSolutionFile>
<Message Text="Found $(AllFilesInSolution)" />
which would output the list of all files in the projects in the solution and I could use the AllFilesInSolution property as input to other analysis tasks. Is this an already existing task or do I need to build it myself? If I need to build it myself, should the task output an array of strings or of ITaskItems or something else?
I don't know about tasks, but there are already properties that hold all items. Just look in your typical project file and you'll see which collection they're being added to.
Note the properties Content, Compile, Folder... any time you add a file to a project, it gets put in one of the main collections like this:
<ItemGroup>
<Content Include="Default.aspx" />
<Content Include="Web.config" />
</ItemGroup>
<ItemGroup>
<Compile Include="Default.aspx.cs">
<SubType>ASPXCodeBehind</SubType>
<DependentUpon>Default.aspx</DependentUpon>
</Compile>
<Compile Include="Default.aspx.designer.cs">
<DependentUpon>Default.aspx</DependentUpon>
</Compile>
</ItemGroup>
<ItemGroup>
<Folder Include="App_Data\" />
</ItemGroup>
Then you can do stuff like this to put the values from existing properties into your properties (the Condition attribute acts as a filter):
<CreateItem Include="#(Content)" Condition="'%(Extension)' == '.aspx'">
<Output TaskParameter="Include" ItemName="ViewsContent" />
</CreateItem>
Or you can do it manually (the Include attribute uses the existing property OutputPath, but it indicates a path that inclues all files):
<CreateItem Include="$(OutputPath)\**\*">
<Output TaskParameter="Include" ItemName="OutputFiles" />
</CreateItem>
There are more details in the MSDN MSBuild documentation that I read when I was mucking with custom build tasks and stuff that was very helpful. Go read up on the CreateItem task and you'll be able to make more sense out of what I posted here. It's really easy to pick up on.
I use the following for solutions with SSRS projects (which dont build under TFS w/o vs installed on the build box). Basically we require that the RDLs be bundled into a build output so we can mark a build for release.
<Target Name="CopyArtifactstoDropLocation">
<CreateItem Include="$(SolutionRoot)\**\*.*">
<Output TaskParameter="Include" ItemName="YourFilesToCopy" />
</CreateItem>
<Copy
SourceFiles="#(YourFilesToCopy)"
DestinationFiles="#(YourFilesToCopy->'$(DropLocation)\$(BuildNumber)\Release\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>
Just replace the usage of the Copy Task with whatever you need to do with your bundle. Granted this is going to get everything in your solution root, but if your using TFS then you should only have buildable artifacts.