Build version captured before "BeforeBuild" target

I'm using MSBuild.Community.Tasks to help with two things, viz setting the version and zipping the file. I'm not married to this, so an alternative approach is welcome if it produces what I'm looking for. The goal is to increase the build count before build and then create a new DLL (with a few other files) after build. ZIP file should be named according to the assembly.

I'm almost there, however, my version number in my DLL is always one step away from my version.txt file (autogenerating from the Versions task). Here's what I have in 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 removes any files from the previous build and then enlarges the version.txt file correctly.

Next, in my goal, AfterBuild

I 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 am updating AssemblyInfo.cs

and pointing out some groups of files. Then I copy the project output and finally write the required files.

This all works fine, except that my DLL version is always 1 version number behind my actual revision number - that is, what is stored in the version.txt file and that the .ZIP file name is saved as.

Am I missing something obvious here? It's like the version is being grabbed before the build process or whatever starts.

Thanks in advance.

+3


source to share


1 answer


GOSH, yes, I am missing something obvious. As soon as I re-read the question, right before posting, it became clear what I did wrong. I even explained it.

The AssemblyInfo

fix was to move the task to the BeforeBuild target. This is a task that outputs a .cs file containing the attributes required to enter the correct versioning information into the DLL. Leaving this file updated until the build was complete meant my DLL would play the race indefinitely.

I'm going to go ahead and post this anyway in case anyone comes across something similar.

Greetings.




Edit . In order to achieve this goal, the final version of these goals required moving the ZIP operation to a separate target (I called it ZipProjectOutput) due to a race condition that I could not solve: the DLL never showed up in the ZIP file and I think the OS exit time was file lock or something could be to blame.

I used AfterTargets="AfterBuild"

to have the ZipProjectOutput target execute when the other was completed. I'm not entirely happy with this as I'm not sure if I'm just "winning" the race here rather than solving the problem, but now it works pretty smoothly for me. #WFM

+2


source







All Articles