Using MSBuild and MSBuild Community Tasks I am trying to do something very simple:
Get version information from an assembly.
Update a .nuspec file with that version information.
My MSBuild target looks like this:
<Target Name="Package">
<GetAssemblyIdentity AssemblyFiles="%(PackageDir.FullPath)\MyAssembly.dll">
<Output TaskParameter="Assemblies" ItemName="AssemblyIdentity" />
</GetAssemblyIdentity>
<XmlUpdate
Prefix="nu"
Namespace="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd"
XmlFileName="%(PackageDir.FullPath)\MyAssembly.nuspec"
XPath="/nu:package/nu:metadata/nu:version"
Value="%(AssemblyIdentity.Version)" />
</Target>
The problem I'm having is that the NuGetPack task runs TWICE: The first time, the Assembly version is missing but the paths are correct, the second time the Assembly version is correct but the paths are missing!
Here is the output:
Updating Xml Document "D:\MyProject\package\MyAssembly.nuspec".
1 node(s) selected for update.
XmlUpdate Wrote: "".
Updating Xml Document "\MyAssembly.nuspec".
D:\MyProject\MyProject.build(64,9): error : Could not find file
'D:\MyAssembly.nuspec'.
Done Building Project "D:\MyProject\MyProject.build" (Package target(s)
) -- FAILED.
I also tried using the NuGetPack task, but got similar results. Help is greatly appreciated!
I seem to have solved it, though I'm still not sure why the code in my original question does not work.
Instead of specifying paths via concatenation (e.g. AssemblyFiles="%(PackageDir.FullPath)\MyAssembly.dll") I put each path into its own item:
<ItemGroup>
...
<PackageVersionAssembly Include=".\build-artifacts\package\MyAssembly.dll"/>
<NuSpecFile Include=".\build-artifacts\package\MyAssembly.nuspec"/>
...
</ItemGroup>
I made the same change in the task and made the same change to references to the .nuspec file.
The new Package target looks like this:
<Target Name="Package">
<GetAssemblyIdentity AssemblyFiles="#(PackageVersionAssembly)">
<Output TaskParameter="Assemblies" ItemName="AssemblyIdentity" />
</GetAssemblyIdentity>
<XmlUpdate
Prefix="nu"
Namespace="http://schemas.microsoft.com/packaging/2011/08/nuspec.xsd"
XmlFileName="#(NuSpecFile)"
XPath="/nu:package/nu:metadata/nu:version"
Value="%(AssemblyIdentity.Version)" />
</Target>
I hope this helps others!
Related
MSBuild quite powerful and important tool, but sometimes configuration of it is the same hard as making a spaceship or flying to Mars. Answers on next questions can help makes it a little bit more usefull and developer friendly:
- How the MSBuild create a Package(zip)?
- Does it use some temporary folders or direct from builds output ?
- Why can the output folder content differ from a package content
- What events can be used to add some custom logic?
The answers to this question could help me with the next long story short:
I'm working with a .Net Core solution, that has the dependency on some other solutions DLLs files( that are not referenced directly, but required to be in the solution folder). On post-build event CL there is the option added as an entry point "\TaskEP" that is a starting point of the next pipeline :
<PropertyGroup>
<PipelineCopyAllFilesToOneFolderForMsdeployDependsOn>
TaskEP;
Task2;
Task3;
$(PipelineCopyAllFilesToOneFolderForMsdeployDependsOn);
</PipelineCopyAllFilesToOneFolderForMsdeployDependsOn>
<RunPostBuildEvent>Always</RunPostBuildEvent>
Tasks are mostly done for add extra DLLs to package and in general looks like :
<Target Name="TaskEP" Condition="$(SomeConditions) == 'True'">
<Message Importance="high" Text="TaskEP: Copying some files..." />
<ItemGroup>
<ItemsName Include="$(MSBuildProjectDirectory)\..\..somepath..\Extra.dll;....dll" />
<FilesForPackagingFromProject Include="%(ItemsName.Identity)">
<DestinationRelativePath>bin\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</FilesForPackagingFromProject>
</ItemGroup>
</Target>
Basically, for me, this instruction to MSBuild to add "Extra.dll" to output package.
Pubxml is quite usual :
<PropertyGroup>
<WebPublishMethod>Package</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<_PackagePathShortened Condition="'$(_PackagePathShortened)' == ''">SuperWebSite</_PackagePathShortened>
<ExcludeApp_Data>False</ExcludeApp_Data>
<PackageLocation>..\..\..\..\BIN\WEB\Release\Publish\Super.WebApplication.zip</PackageLocation>
<PackageAsSingleFile>true</PackageAsSingleFile>
<TargetFramework>netcoreapp2.1</TargetFramework> ....
And one instruction that replaces the long long path in the package to Short and defined one:
<Target Name="AddReplaceRuleForAppPath" BeforeTargets="BeforePublish">
<Message Text="Adding replace rules for application path '$(PublishIntermediateOutputPath)' replace with '$(_PackagePathShortened)'" Importance="high" />
<EscapeTextForRegularExpressions Text="$(PublishIntermediateOutputPath)">
<Output PropertyName="_PackagePathRegex" TaskParameter="Result" />
</EscapeTextForRegularExpressions>
<!-- Add a replace rule for VSMSDeploy resp. MSdeploy to update the path -->
<ItemGroup>
<MsDeployReplaceRules Include="replaceFullPath">
<Match>$(_PackagePathRegex)</Match>
<Replace>$(_PackagePathShortened)</Replace>
</MsDeployReplaceRules>
</ItemGroup>
I also duplicated the same "Copy" tasks here in .pubxml file , play with different events "AfterBuild", "BeforePublish" but seems that all of the just ignoring. I can see the "Extra" DLLs files in the build output directory and all Info Messages on publishing, but not in the final "Super.WebApplication.zip" file !
The solution I found to copy extra files in .Net Core is taken from this documentation
<ItemGroup>
<DotnetPublishFiles Include="$(MSBuildProjectDirectory)\..\..somepath..\Extra.dll;....dll" >
<DestinationRelativePath>bin\x86\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath>
</DotnetPublishFiles>
</ItemGroup>
On my .wixproj file, I have a before build action to get the assembly version and append it to the output file name. However, how my code builds in my local machine is different than the one on the the TFS Server. So I am trying the following:
<Target Name="BeforeBuild">
<GetAssemblyIdentity AssemblyFiles="$(TargetDir)\myassembly.dll" Condition="$(env.COMPUTERNAME)=='THETFSSERVER'">
<Output TaskParameter="Assemblies" ItemName="AssemblyVersions" />
</GetAssemblyIdentity>
<GetAssemblyIdentity AssemblyFiles="$(SolutionDir)\Source\Project\bin\myassemblydll" Condition="$(env.COMPUTERNAME)!='THETFSSERVER'">
<Output TaskParameter="Assemblies" ItemName="AssemblyVersions" />
</GetAssemblyIdentity>
<CreateProperty Value="$(OutputName)_%(AssemblyVersions.Version)">
<Output TaskParameter="Value" PropertyName="TargetName"/>
</CreateProperty>
</Target>
I've tried &(env.COMPUTERNAME), [&COMPUTERNAME], and several other options that I saw online, and some other that made sense, but I can't manage to find what exactly to use to look at the computer name.... any ideas how to achieve that?
There is. It is $(COMPUTERNAME). There is a very easy way to find out what all the properties are when you first load a build script in MSBuild. All you have to do is generate a log using the diagnostic verbosity. Then look at the top of the log file and it will list out all initial properties and items.
For example:
msbuild.exe /l:FileLogger,Microsoft.Build.Engine;verbosity=diagnostic;logfile=diag.log MyProject.proj
Link from where the answer was taken
Alsol, the tfs is building under msbuild, and you probably building form visual studio. So, the condition can use $(BuildingInsideVisualStudio) property and not the computer name.
Does anyone know how to modify a csproj file in a way to generate code files during build without actually referencing the files?
A process like :
create file,
dynamically reference temporary file during build
compiled assembly has additional members, depending on the files created during build
The purpose of this is to create a way of generating code files using roslyn instead of using t4 templates, which are very awkward to use once you're trying to do something depending on attributes.
Hence i am planning on providing a way to use a special csharp file (for full syntax support) to generate files programatically based on the contents of that special file.
I've spent a couple of weeks looking into resources on the internet (with the topic msbuild), but until now it seems i didn't use the right keywords.
This one has been the most insightful one to me yet:
https://www.simple-talk.com/dotnet/.net-tools/extending-msbuild/
My guess is, that the correct build target for my purpose should be "BeforeCompile" in order to somehow populate the build process with custom code files.
Does anyone have experience with my issue, or is aware of any particular resources which deal with the task?
Solution i got it working with:
<UsingTask TaskName="DynamicCodeGenerator.DynamicFileGeneratorTask" AssemblyFile="..\DynamicCodeGenerator\bin\Debug\DynamicCodeGenerator.dll" />
<Target Name="DynamicCodeGeneratorTarget" BeforeTargets="BeforeBuild;BeforeRebuild">
<DynamicFileGeneratorTask>
<Output ItemName="Generated" TaskParameter="GeneratedFilePaths" />
</DynamicFileGeneratorTask>
<ItemGroup>
<Compile Include="#(Generated)" />
<FileWrites Include="#(Generated)" />
<!-- For clean to work properly -->
</ItemGroup>
</Target>
Unfortunately i did not get it to work with a propertygroup override as suggested
Update: This link is interesting too: https://github.com/firstfloorsoftware/xcc/blob/master/FirstFloor.Xcc/Targets/Xcc.targets
Generating the code file can be achieved by msbuild task or msbuild inline task. It is up to you to generate the proper code. One thing that you must care of is creating output item parameter in order to append it to the #(Compile) item. You can use $(IntDir) location to locate your newly generated file, and add them to the #(FileWrites) item group in order for Clean target work properly.
When you finish writing your task, you must use it in your project like this:
<UsingTask TaskName="TaskTypeFullName" AssemblyFile="YourAssembly.dll"/>
<PropertyGroup>
<!-- Here you need to experiment with [Build/Compile/SomeOther]DependsOn property -->
<BuildDependsOn>
MyCodeGenerator;
$(BuildDependsOn)
</BuildDependsOn>
</PropertyGroup>
<Target Name="MyCodeGenerator">
<YourTaskName>
<Output ItemName="Generated" TaskParameter="GeneratedFiles" />
</YourTaskName>
<ItemGroup>
<Compile Include="#(Generated)" />
<FileWrites Include="#(Generated)" /> <!-- For clean to work properly -->
</ItemGroup>
</Target>
I wanted to use a bash script to generate code for a project using dotnet core on Linux. Here is what worked for me. And thanks #stukselbax, I built this off of your answer.
<Target Name="GenerateProtocolBuffers" BeforeTargets="BeforeBuild;BeforeRebuild">
<Exec Command="./generatecode.sh" Outputs="proto/*.cs">
<Output ItemName="Generated" TaskParameter="Outputs" />
</Exec>
<ItemGroup>
<Compile Include="#(Generated)" />
<FileWrites Include="#(Generated)" />
</ItemGroup>
</Target>
Note that the script I'm using to generate the code is called generatecode.sh. Replace this with your own.
I am using MSBuild.Community.Tasks to help with two things, namely adjusting the version and zipping up a file. I am not married to this, so an alternate approach is welcome provided it produces what I'm looking for. The goal is to increment the build number before the build, then ZIP up a new DLL (with a couple of other files) after the build. The ZIP file should be named according to the build.
I am almost there, however, my version number in my DLL is always one step behind my version.txt file (auto-gen'd from the Version task). Here is what I have in the BeforeBuild target:
<Target Name="BeforeBuild" BeforeTargets="PrepareForBuild">
<Message Text=" --=== Before Build ===--"></Message>
<ItemGroup>
<PreviousFiles Include="$(MSBuildProjectDirectory)\BuildPackage\$(AssemblyName).*.zip">
<InProject>false</InProject>
</PreviousFiles>
</ItemGroup>
<Delete Files="#(PreviousFiles)"></Delete>
<Delete Files="$(MSBuildProjectDirectory)\BuildPackage\$(AssemblyName).dll"></Delete>
<Version VersionFile="version.txt" RevisionType="Increment">
<Output TaskParameter="Major" PropertyName="Major" />
<Output TaskParameter="Minor" PropertyName="Minor" />
<Output TaskParameter="Build" PropertyName="Build" />
<Output TaskParameter="Revision" PropertyName="Revision" />
</Version>
</Target>
This deletes any files from the previous build, then increments the version.txt file correctly.
Next, in my AfterBuild target I have put this together:
<Target Name="AfterBuild" AfterTargets="Build">
<Message Text=" --=== After Build ==--"></Message>
<AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyVersion.cs" AssemblyVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" />
<ItemGroup>
<ProjectOutputFiles Include="bin\$(AssemblyName).dll">
<InProject>false</InProject>
</ProjectOutputFiles>
<ZipFiles Include="$(MSBuildProjectDirectory)\BuildPackage\*.*" Exclude="$(MSBuildProjectDirectory)\BuildPackage\*.zip">
<InProject>false</InProject>
</ZipFiles>
</ItemGroup>
<Copy SourceFiles="#(ProjectOutputFiles)" DestinationFolder="$(MSBuildProjectDirectory)\StorePackage" />
<Zip Files="#(ZipFiles)" WorkingDirectory="$(MSBuildProjectDirectory)\BuildPackage" ZipFileName="$(MSBuildProjectDirectory)\BuildPackage\$(AssemblyName).$(Major)-$(Minor)-$(Build)-$(Revision).zip" ZipLevel="9" />
</Target>
Basically, I'm updating AssemblyInfo.cs and specifying some file groups. I then copy the project output over and finally ZIP up the required files.
This all works great, except my DLL version is always 1 revision number behind my actual revision number - i.e., what is stored in version.txt and what the name of the .ZIP file is saved out as.
Am I missing something obvious here? It's like the version is captured before the build process even starts or something.
Thanks in advance.
GOSH, yes, I am missing something obvious. As soon as I re-read the question, right before posting, it became clear what I had done incorrectly. I even spelled it out.
The fix was to move the AssemblyInfo task up to the BeforeBuild target. This is the task that outputs the .cs file containing the attributes required to inject the correct versioning information into the DLL. Leaving the update of this file until after the build has completed meant that my DLL was going to be losing the race in perpetuity.
I'm going to go ahead and post this anyways, in case someone else runs into something similar.
Cheers.
Edit For what it's worth, the final version of these targets required moving the ZIP operation out into a separate target (I called it ZipProjectOutput) because of a race condition that I couldn't resolve: the DLL was never showing up in the ZIP file, and I think that the timing of the OS releasing a lock on the file or something might have been to blame.
I used the AfterTargets="AfterBuild" to have the ZipProjectOutput target execute when the other was complete. I'm not entirely happy about this as I'm not certain I'm just "winning" the race here, rather than solving the problem, but this is working for me now rather slickly. #WFM
I'm currently moving my project to Visual Studio 2012 and start using nuget.
So I'll use the "NUnit Runners" nuget package instead of a nunit library.
The problem being that nuget creates folders with the package version. For example, NUnit Runners is inside the folder:
src\packages\NUnit.Runners.2.6.1\
Until now, Nunit was inside my lib\NUnit folder.
So, inside my MSBuild file, I was executing the tests by specifying the path:
<PropertyGroup>
<NUnitFolder>$(MSBuildProjectDirectory)\lib\NUnit</NUnitFolder>
</PropertyGroup>
<NUnit Assemblies="..." ToolPath="$(NUnitFolder)" />
But I don't want to have to specify a version number inside my msbuild task, that I would have to update everytime NUnit.Runners is updated.
I tried to play around with CreateProperty, but it doesn't seem to accept wildcards.
I also tried ItemGroup, but it works for a list of files, not a folder.
In the end, instead of trying to create a property with a wildcard, in my case I retrieved the version of NUnit.Runners from the packages.config file.
I now have a Target like this:
<Target Name="GetNUnitFolder">
<!-- Retrieves the version of NUnit.Runners from the solution's packages.config file -->
<XmlRead Namespace=""
XPath="packages/package[#id='NUnit.Runners']/#version"
XmlFileName="$(MSBuildProjectDirectory)\src\.nuget\packages.config">
<Output TaskParameter="Value" PropertyName="NUnitVersion" />
</XmlRead>
<CreateProperty Value="$(MSBuildProjectDirectory)\src\packages\NUnit.Runners.$(NUnitVersion)\tools">
<Output TaskParameter="Value" PropertyName="NUnitFolder" />
</CreateProperty>
</Target>
Note: to be able to use XmlRead, you need the MSBuildCommunityTasks.
And once I have the version, I rebuild my NUnitFolder property.