These were my first steps into automated build and I was impressed, that I don’t have to host the code on VSTS, just to be able to get the automated build up and running. Following the instructions, I could setup my very first automated build, which of cause failed multiple times. *grrr*
I struggled with 2 thing. First of all, I was using ILMerge to include 3rd party assemblies. And second the assembly version and file version did not match the build number. Both are criteria’s, that need to be fulfilled for a trusted XrmToolBox plugin.
So far so good. How did I solved it?
ILMerge or ILRepack
I was a big fan of ILMerge, even if there are some drawbacks if you use it. But in my current situation to use it for automated builds, my build failed, when I was trying to call it with the exec MS build task.
I did some research and found ILRepack. This is a open source replacement for ILMerge which isn’t maintained since several year. The good thing is, that the exec build task was working fine here. Most probably with the same syntax it will work with ILMerge too.
I simply had to add the following NuGet Package:
This is, how I extended my project-file, to get the outcome merge repacked.
<Target Name="ILRepack" AfterTargets="Build" Condition="'$(Configuration)' == 'Release'"> <MakeDir Directories="$(OutputPath)Merged" /> <ItemGroup> <MergeAssemblies Include="$(OutputPath)\Microsoft.ApplicationInsights.dll" /> <MergeAssemblies Include="$(OutputPath)\Newtonsoft.Json.dll" /> </ItemGroup> <ItemGroup> <ILRepackPackage Include="$(NuGetPackageRoot)\ilrepack\*\tools\ilrepack.exe" /> </ItemGroup> <Error Condition="!Exists(@(ILRepackPackage->'%(FullPath)'))" Text="You are trying to use the ILRepack package, but it is not installed or at the correct location" /> <Exec Command="@(ILRepackPackage->'%(fullpath)') /out:$(OutputPath)Merged\$(AssemblyName).dll /target:library $(OutputPath)$(AssemblyName).dll @(MergeAssemblies->'%(FullPath)', ' ')" /> </Target>
As you can see, I slightly modified the sample to and also added a line to create the “Merged” folder. On release build the assemblies will now be repacked.
This solved my first issue. However I would still not pass the criteria’s for releasing the Plugin into the store. Remember the build number?
In the blog from Jonas is pretty well written, how to use the build number inside the NuGet package. However it took me a while to handle the assembly version and the file version.
First of all I had to find the right task in the marketplace. I finally ended up with the Assembly Info task, which does a great job. I simply installed it and could use it in my build definition. It supports a lot of additional parameters.
I added it in between of the NuGet restore and the Build solution **\*.sln.
In the 3 fields for all version numbers I only need to put
and it worked.
It is also possible to overwrite all other assembly attributes. You can even add the attributes, if they are not yet in your assembly, if you tick the “Insert Attributes”.
Finally I only had to finetune the Build number format in the Options. The format suggested by Jonas was inserting leading zeros on the file number format, that I didn’t wanted to have. So why I change the definition to:
The result looks the same as from Jonas, but no leading zeros anymore.
This is the *.nuspec of the release drop.
and this the reflected *.dll using Jetbrains dotPeek.