We just released a new version of OctoPack with some big changes. So big, in fact, we're calling it OctoPack 3.0!
The first change is that when packaging binaries, we used to take all the files under the $(OutDir). TFS by default sends the outputs for all projects to the same directory, which meant OctoPack couldn't work out which files were for which project. Thanks to a pull request by Max Malook, we've changed this to use @(FileWrites) and @(FileWritesShareable) instead. You can learn more about these properties on MSDN. The end result is that OctoPack should work better for TFS users.
The second major change is that OctoPack no longer needs to be checked into version control. That means there is no more .octopack folder when using NuGet package restore! We're using the same approach that Microsoft.Bcl.Build uses. When you install OctoPack, you'll get the following <Import>:
<Import Project="..\packages\OctoPack.3.0.19\tools\OctoPack.targets" Condition="Exists('..\packages\OctoPack.3.0.19\tools\OctoPack.targets')" />
This way you'll still be able to load the project when the targets are missing when NuGet package restore hasn't yet run.
However, if you invoke OctoPack, and you haven't run NuGet Package Restore yet, then obviously we can't package anything. So we also add a <Target> that will fail the build unless you run NuGet package restore first:
<Target Name="EnsureOctoPackImported" BeforeTargets="BeforeBuild" Condition="'$(OctoPackImported)' == ''">
<Error Condition="!Exists('..\packages\OctoPack.3.0.19\tools\OctoPack.targets') And ('$(RunOctoPack)' != '' And $(RunOctoPack))" Text="You are trying to build with OctoPack, but the NuGet targets file that OctoPack depends on is not available on this computer. This is probably because the OctoPack package has not been committed to source control, or NuGet Package Restore is not enabled. Please enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567." HelpKeyword="BCLBUILD2001" />
<Error Condition="Exists('..\packages\OctoPack.3.0.19\tools\OctoPack.targets') And ('$(RunOctoPack)' != '' And $(RunOctoPack))" Text="OctoPack cannot be run because NuGet packages were restored prior to the build running, and the targets file was unavailable when the build started. Please build the project again to include these packages in the build. You may also need to make sure that your build server does not delete packages prior to each build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317568." HelpKeyword="BCLBUILD2002" />
</Target>
Now, when running OctoPack under Team Build or another CI tool, this presents a bit of a problem especially if the build server is configured to clean all files (including NuGet packages) prior to the build starting. It also affects Team Foundation Service which uses a virtual build agent. But this isn't just a problem for OctoPack; it also affects Microsoft.Bcl.Build users. The best solution is to run NuGet Package Restore prior to building your solution. For TFS users, this post by the NuGet team shows how to run NuGet Package Restore prior to building. TeamCity customers can use the built in NuGet Installer runner.
Finally, a lot of small bugs were fixed and some other features were added:
- 34 - We now read
AssemblyInformationalVersion, falling back toAssemblyVersion, when deciding what version to use for a package (if you don't pass/p:OctoPackPackageVersion=XYZ) - 37 - You can now use custom
<files>in conjunction with the files we automatically detect and add, instead of choosing either - 39 - You can now pass custom properties to NuGet when packaging
Most of these changes came from pull requests from the community, some of which had been waiting quite some time. Thank you to everyone who submitted a PR for OctoPack; we'll be much more active in reviewing them from now on.
