Msbuild ItemGroup unexpectedly accumulates files to copy - msbuild

I am writing an msbuild script to deploy multiple targets. I am trying to reuse some elements and am getting an unexpected behavior.
When I run this proj file:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="All" DependsOnTargets="DeployTarget1;DeployTarget2">
</Target>
<Target Name="DeployTarget1">
<PropertyGroup>
<RootDir>.\source1</RootDir>
</PropertyGroup>
<ItemGroup>
<DeployFiles Include="$(RootDir)\**\*.dll" Exclude="$(RootDir)\bin\C_*.xml" />
</ItemGroup>
<Copy SourceFiles="#(DeployFiles)" DestinationFiles="#(DeployFiles->'D:\deploytest\dest1\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>
<Target Name="DeployTarget2">
<PropertyGroup>
<RootDir>.\source2</RootDir>
</PropertyGroup>
<ItemGroup>
<DeployFiles Include="$(RootDir)\**\*.dll" Exclude="$(RootDir)\bin\C_*.xml" />
</ItemGroup>
<Copy SourceFiles="#(DeployFiles)" DestinationFiles="#(DeployFiles->'D:\deploytest\dest2\%(RecursiveDir)%(Filename)%(Extension)')" />
</Target>
</Project>
DeployTarget1 copies the files from the source1 directory recursively to dest1 as I expect.
DeployTarget2 copies both source1 and source2 to dest2, this is not what I expected.
D:\deploytest>msbuild /t:All test.proj
Microsoft (R) Build Engine version 4.0.30319.17929
[Microsoft .NET Framework, version 4.0.30319.18052]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 8/20/2013 2:37:17 PM.
Project "D:\deploytest\test.proj" on node 1 (All target(s)).
DeployTarget1:
Copying file from ".\source1\test1.dll" to "D:\deploytest\dest1\test1.dll".
copy /y ".\source1\test1.dll" "D:\deploytest\dest1\test1.dll"
DeployTarget2:
Copying file from ".\source1\test1.dll" to "D:\deploytest\dest2\test1.dll".
copy /y ".\source1\test1.dll" "D:\deploytest\dest2\test1.dll"
Copying file from ".\source2\test2.dll" to "D:\deploytest\dest2\test2.dll".
copy /y ".\source2\test2.dll" "D:\deploytest\dest2\test2.dll"
Done Building Project "D:\deploytest\test.proj" (All target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.06
Does anyone know why this happens?
Can you point me to documentation on this "feature"?

ItemGroups are cummulative. Each time an item group if referenced, items are added to the existing group. If you want to have explicit groups, you either need to give them a unique name or you need to clear them before usage.
Use <DeployFiles Remove="**/*">
See also: https://stackoverflow.com/a/7915992/736079

Related

.NET Core msbuild ProjectReference

I have a solution that contains a console application with a .csproj file like the this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
</Project>
I also have a library project that uses the console application to generate a heap of C# code that get compiled into the library, the library .csproj file looks like this.
<Project Sdk="Microsoft.NET.Sdk" InitialTargets="RunGenerator">
<PropertyGroup>
<TargetFramework>netstandard1.4</TargetFramework>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="../generator/generator.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
<Target Name="RunGenerator">
<Exec Command="dotnet run -p "../generator/generator.csproj" input output" />
</Target>
</Project>
This fails because the dependency analysis says that a netstandard1.4 assembly cannot reference a netcoreapp1.1 assembly. That is correct except that I am not referencing the assembly.
I can work around that issue by building the generator project like this:
<Project Sdk="Microsoft.NET.Sdk" InitialTargets="RunGenerator">
<PropertyGroup>
<TargetFramework>netstandard1.4</TargetFramework>
</PropertyGroup>
<Target Name="RunGenerator">
<Exec Command="dotnet build "../generator/generator.csproj"" />
<Exec Command="dotnet run -p "../generator/generator.csproj" input output" />
</Target>
</Project>
The problem is that the generator project no longer takes part in the dependency analysis when these projects are built using the containing solution file and the explicit build of the generator project sometimes runs concurrently with another build of the same project initiated by the solution build and this results in errors because files are locked etc.
Is it possible to have a project dependency without checking the target framework?
Can anyone suggest a workaround?
Thanks.
Here are some MSBuild tips. You might need to combine a few of these ideas.
You can use your solution file to add an explicit project dependency. See https://learn.microsoft.com/en-us/visualstudio/ide/how-to-create-and-remove-project-dependencies (This question was originally asked here: Visual Studio 2010: How to enforce build order of projects in a solution?). Unfortunately, this is really hard to do if you don't have VS. The format is .sln files is kinda a nightmare.
To avoid the concurrent build issue, use the MSBuild task instead of the Exec task. See https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-task
<Target Name="CompileAnotherProject">
<MSBuild Projects="../generator/generator.csproj" Targets="Build" />
</Target>
dotnet-run invokes "dotnet build" automatically. This is actually problematic in concurrent builds. You can instead add a target to your generator.csproj that runs the app after it has been built. "dotnet filepath.dll" runs the compiled app without building it.
<Target Name="RunCodeGen" AfterTargets="Build">
<Exec Command="dotnet $(AssemblyName).dll input output"
WorkingDirectory="$(OutDir)" />
</Target>

.wixproj file does not refresh properties during build

I've just implemented a new build script file to share code signing details among projects and allowing us to easily switch depending on if our main certificate is available or not. This is in our main application project as well as two WiX projects (msi and exe).
It seems like WiX remembers settings from the last build - for example, if I build with cert.sign in the correct place, then remove it and build again, it recalls the settings loaded from cert.sign during the first build rather than using test.sign as expected. This is not an issue in regular .csproj files.
The .sign file I've set up (one per certificate):
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Certificate>test.pfx</Certificate>
<FilePath>$(SolutionDir)</FilePath>
<Pwd>cert_pwd</Pwd>
<TimeStamp>/tr http://timestamp.server.com</TimeStamp>
<AppName>My App</AppName>
<Url>www.example.com</Url>
</PropertyGroup>
</Project>
The main .csproj file (this works):
...
<Import Project="$(SolutionDir)..\..\.cert\cert.sign" Condition="Exists('$(SolutionDir)..\..\.cert\cert.sign')"/>
<Import Project="$(SolutionDir)\test.sign" Condition="!Exists('$(SolutionDir)..\..\.cert\cert.sign')"/>
<PropertyGroup>
<PostBuildEvent>signtool sign /f $(FilePath)$(Certificate) /p $(Pwd) $(TimeStamp) /d $(AppName) /du $(Url) $(TargetPath)</PostBuildEvent>
</PropertyGroup>
...
One of the .wixproj files (this doesn't work):
...
<Import Project="$(SolutionDir)..\..\.cert\cert.sign" Condition="Exists('$(SolutionDir)..\..\.cert\cert.sign')"/>
<Import Project="$(SolutionDir)\test.sign" Condition="!Exists('$(SolutionDir)..\..\.cert\cert.sign')"/>
<Target Name="SignMsi">
<Exec Command="signtool sign /f $(FilePath)$(Certificate) /p $(Pwd) $(TimeStamp) /d $(AppName) /du $(Url) #(SignMsi)" />
</Target>
...
Any ideas on how to fix this? Could it be an issue in the SignMsi and SignExe targets? I'm on Visual Studio 2015 u2, WiX v3.10.2.2516

Copy files kept on local machine onto a shared location on a remote machine using MSBuild

I have created a build file using MSBuild which builds solution and keep all the data into a folder. Now i want to copy all the data to a remote machine accessed via shared folder.
<PropertyGroup>
<PublishDir>\\remoteMachineName\QA</PublishDir>
<ServiceLocationQA>remoteMachineName\QA</ServiceLocationQA>
<MachineName>remoteMachineName</MachineName>
</PropertyGroup>
<ItemGroup>
<Source Include=".\buildartifacts\**\*.*"/>
<ServiceFilesToDeploy Include=".\buildartifacts\**\*.*" />
</ItemGroup>
<Copy SourceFiles=".\buildartifacts\**\*.*"
DestinationFiles="#(ServiceFilesToDeploy->'$(PublishDir)\%(RecursiveDir)%(Filename)%(Extension)')"
ContinueOnError="false" />
After executing the the build script, i get following error:
"DestinationFiles" refers to 48 item(s), and "SourceFiles" refers to 1 item(s). They must have the same number of items."
I just want to copy files kept on local machine onto a shared location on a remote machine using MSBuild. Please help
You need to iterate the files:
<Copy SourceFiles="%(ServiceFilesToDeploy.Identity)"
DestinationFiles="#(ServiceFilesToDeploy->'$(PublishDir)\%(RecursiveDir)%(Filename)%(Extension)')"
ContinueOnError="false" />
That way the copy task will be called for each file in ServiceFilesToDeploy.
You dont even need to do batching as the copy task understands itemgroups:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Test">
<PropertyGroup>
<PublishDir>\\remotemachine\test</PublishDir>
<BuildArtifacts>.\buildartifacts</BuildArtifacts>
</PropertyGroup>
<ItemGroup>
<Source Include="$(BuildArtifacts)\**\*.*"/>
</ItemGroup>
<Copy SourceFiles="#(Source)"
DestinationFolder="$(PublishDir)\%(RecursiveDir)"/>
</Target>
</Project>

How can I change AssemblyProduct, AssemblyTitle using MSBuild?

I have an MSBuild script which compiles my existing solution but I'd like to change some properties of one of the projects within the solution at compile-time, including but not limited to AssemblyProduct and AssemblyTitle.
Here's a snippet of my build script:
<Target Name="Compile" >
<MSBuild Projects="..\MySolution.sln"
Properties="Configuration=MyReleaseConfig;Platform=x86" />
</Target>
I've got one main executable and several DLLs that are compiled. I am aware of the MSBuild Extension Pack and I suspect it might help me to get to where I need to be, although I'm not sure how to proceed.
Can I selectively change AssemblyInfo properties at build time?
You're on the right track with the MSBuild Extension Pack.
I find the easiest way to conditionally generate the assembly details at build time is to add an "AssemblyVersion" target directly to my .csproj file(s) that require an updated AssemblyInfo file. You can add the target directly to each csproj file that requires an updated AssemblyInfo file, or as I prefer to do it, create a custom targets file with the AssemblyVersion target and have each csproj file include your custom targets file.
Either way you likely want to use the MSBuild Extension Pack or the MSBuild Community Tasks to use their respective AssemblyInfo task.
Here's some code from our build scripts:
<!-- Import the AssemblyInfo task -->
<Import Project="$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets"/>
<!-- Overriding the Microsoft.CSharp.targets target dependency chain -->
<!-- Call our custom AssemblyVersion target before build, even from VS -->
<PropertyGroup>
<BuildDependsOn>
AssemblyVersion;
$(BuildDependsOn)
</BuildDependsOn>
</PropertyGroup>
<ItemGroup>
<AssemblyVersionFiles Include="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/>
</ItemGroup>
<Target Name="AssemblyVersion"
Inputs="#(AssemblyVersionFiles)"
Outputs="UpdatedAssemblyVersionFiles">
<Attrib Files="%(AssemblyVersionFiles.FullPath)"
Normal="true"/>
<AssemblyInfo
CodeLanguage="CS"
OutputFile="%(AssemblyVersionFiles.FullPath)"
AssemblyCompany="$(CompanyName)"
AssemblyCopyright="Copyright $(CompanyName), All rights reserved."
AssemblyVersion="$(Version)"
AssemblyFileVersion="$(Version)">
<Output TaskParameter="OutputFile"
ItemName="UpdatedAssemblyVersionFiles"/>
</AssemblyInfo>
</Target>
Sneal's answer was very helpful, but I'd like to show what I actually ended up doing. Instead of editing csproj files (there are several) I instead added tasks to my build script. Here's a snippet:
<PropertyGroup>
<ProductName>MyApp</ProductName>
<CompanyName>MyCompany</CompanyName>
<Major>1</Major>
<Minor>0</Minor>
<Build>0</Build>
<Revision>0</Revision>
</PropertyGroup>
<ItemGroup>
<AssemblyVersionFiles Include="..\MyMainProject\Properties\AssemblyInfo.cs"/>
</ItemGroup>
<Target Name="AssemblyVersionMAIN" Inputs="#(AssemblyVersionFiles)" Outputs="UpdatedAssemblyVersionFiles">
<Attrib Files="%(AssemblyVersionFiles.FullPath)" Normal="true"/>
<AssemblyInfo
CodeLanguage="CS"
OutputFile="%(AssemblyVersionFiles.FullPath)"
AssemblyProduct="$(ProductName)"
AssemblyTitle="$(ProductName)"
AssemblyCompany="$(CompanyName)"
AssemblyCopyright="© $(CompanyName) 2010"
AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)"
AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)"
AssemblyInformationalVersion="$(Major).$(Minor).$(Build).$(Revision)">
<Output TaskParameter="OutputFile" ItemName="UpdatedAssemblyVersionFiles"/>
</AssemblyInfo>
</Target>
<Target Name="Compile" DependsOnTargets="AssemblyVersionMAIN">
<MSBuild Projects="..\MySolution.sln"
Properties="Configuration=Release;Platform=x86;Optimize=true" />
</Target>
Then, I can override my variables from the command line, or a batch script, like so:
set MAJ=1
set MIN=2
set BLD=3
set REV=4
msbuild buildScript.xml /t:Compile /p:Major=%MAJ% /p:Minor=%MIN% /p:Build=%BLD% /p:Revision=%REV%
<Target Name="SetVersion">
<ItemGroup>
<AssemblyInfoFiles Include="$(TargetDir)\**\AssemblyInfo.cs"/>
</ItemGroup>
<Message Text="change the Version number for:"/>
<Message Text="%(AssemblyInfoFiles.FullPath)"/>
<MSbuild.ExtensionPack.Framework.AssemblyInfo
AssemblyInfoFiles="#(AssemblyInfoFiles)"
AssemblyTitle="newTitle"
AssemblyMajorVersion="2"
AssemblyMinorVersion="0"/>
</Target>

Getting the Content item from a csproj using the MSBuild task

I have an MSBuild file and I am building C# projects like this:
<ItemGroup>
<ProjectsToBuild Include="./source/ProjectA/ProjectA.csproj"/>
<ProjectsToBuild Include="./source/ProjectB/ProjectB.csproj"/>
</ItemGroup>
<Target Name="Build">
<MSBuild Projects="#(ProjectsToBuild)" Targets="Build">
<Output ItemName="ProjectOutputs" TaskParameter="TargetOutputs"/>
</MSBuild>
<Message Text="#ProjectOutputs"/>
</Target>
I successfully get an Item containing all of the .dll files that were built:
Build:
c:\code\bin\ProjectA.dll;c:\code\bin\ProjectB.dll
I would also like to get the Content item from each project without modifying the .csproj files. After digging around in the Microsoft .targets files, I was almost able to get it working with this:
<MSBuild Projects="#(ProjectsToBuild)" Targets="ContentFilesProjectOutputGroup">
<Output ItemName="ContentFiles" TaskParameter="TargetOutputs"/>
</MSBuild>
<Message Text="#(ContentFiles->'%(RelativeDir)')"/>
The problem with this approach is the RelativeDir is not being set correctly. I am getting the full path instead of relative:
Build:
c:\ProjectA\MyFolder\MyControl.ascx;c:\ProjectB\MyOtherFolder\MyCSS.css;
instead of:
Build:
MyFolder\MyControl.ascx;MyOtherFolder\MyCSS.css;
Is there a property I can pass to the MSBuild task that will make RelativeDir behave correctly?
Or, even better, is there an easier way to get the Content item?
You can do this but it is not very intutive. I've discussed this type of technique a few times on my blog ( which is currently down :( ).
So create a new file, I named it GetContentFiles.proj which is shown here.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Projects Include="WindowsFormsApplication1\WindowsFormsApplication1.csproj"/>
</ItemGroup>
<!-- This target will be executed once for each file declared in the Project target -->
<Target Name="PrintFiles" Outputs="%(Projects.Identity)">
<Message Text="PrintFiles" Importance="high"/>
<MSBuild Projects="$(MSBuildProjectFile)"
Targets="GetContentFiles"
Properties="ProjectToGetFiles=%(Projects.Identity)">
<Output ItemName="projContent" TaskParameter="TargetOutputs"/>
</MSBuild>
<Message Text="ProjContent: #(projContent)" Importance="high"/>
<!-- Transform the projContent to have correct path -->
<!--
Get the relative path to the project itself, this serves as the base for
the Content files path
-->
<PropertyGroup>
<_ProjRelativeDir>%(Projects.RelativeDir)</_ProjRelativeDir>
</PropertyGroup>
<!-- This item will contain the item with the corrected path values -->
<ItemGroup>
<ProjContentFixed Include="#(projContent->'$(_ProjRelativeDir)%(RelativeDir)%(Filename)%(Extension)')"/>
</ItemGroup>
<!-- Create a new item with the correct relative dirs-->
<Error Condition="!Exists('%(ProjContentFixed.FullPath)')"
Text="File not found at [%(ProjContentFixed.FullPath)]"/>
</Target>
<Import Project="$(ProjectToGetFiles)" Condition="'$(ProjectToGetFiles)'!=''"/>
<Target Name="GetContentFiles" Condition="'$(ProjectToGetFiles)'!=''" Outputs="#(Content)">
<Message Text="Content : #(Content)" Importance="high"/>
<Message Text="Inside GetContentFiles" Importance="high"/>
</Target>
</Project>
I will try and explain this, but it may be tough to follow. Let me know if you need me to expand on it. This file has two targets PrintFiles and GetContentFiles. The entry point into this file is the PrintFiles target, in the sense that this is the target that you are going to call. So you call the PrintFiles target which it then uses the MSBuild task to call the GetContentFiles target on itself, also it passes a value for the ProjectToGetFiles property. Because of that the Import elemnent will be executed. So what you are really doing is taking the project defined in the ProjectToGetFiles property and extending it to include the target GetContentFiles (and whatever other content is inside the GetContentFiles.proj file). So we are effectively extending that file. I'm calling this technique "MSBuild Inheritance" because. So inside the GetContentFiles target we can access all properties and items that are declared inthe ProjectToGetFiles property. So I take advantage of that by simply putting the content of the Content item into the outputs for the target, which can be accessed by the original file using the TargetOutputs from the MSBuild task.
You mentioned in your post that you wanted to correct the path values to be the right ones. The problem here is that in the .csproj file all items are declared relative to the original project file. So if you "extend" the project file in this way from a file in a different directory you must correct the file path values manually. I've done this inside the PrintFiles target, check it out.
If you execute the command msbuild GetContentFile.proj /fl /t:PrintFiles the result would be:
Build started 7/3/2009 12:56:35 AM.
Project "C:\Data\Development\My Code\Community\MSBuild\FileWrites\GetContentFile.proj" on node 0 (PrintFiles target(s)).
PrintFiles
Project "C:\Data\Development\My Code\Community\MSBuild\FileWrites\GetContentFile.proj" (1) is building "C:\Data\Development\My Co
de\Community\MSBuild\FileWrites\GetContentFile.proj" (1:2) on node 0 (GetContentFiles target(s)).
Content : Configs\Config1.xml;Configs\Config2.xml
Inside GetContentFiles
Done Building Project "C:\Data\Development\My Code\Community\MSBuild\FileWrites\GetContentFile.proj" (GetContentFiles target(s)).
PrintFiles:
ProjContent: Configs\Config1.xml;Configs\Config2.xml
Done Building Project "C:\Data\Development\My Code\Community\MSBuild\FileWrites\GetContentFile.proj" (PrintFiles target(s)).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.03
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In case this helps someone else - use TargetPath instead of RelativeDir:
<MSBuild Projects="#(ProjectsToBuild)" Targets="ContentFilesProjectOutputGroup">
<Output ItemName="ContentFiles" TaskParameter="TargetOutputs"/>
</MSBuild>
<Message Text="#(ContentFiles->'%(TargetPath)')"/>
This will give you the relative path for each item.