Assembly Version Captured Before "BeforeBuild" Target - msbuild

Question

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.

Answer 1

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