Hi ya,
Until now I had been using Octopack Nuget package to package my projects and post them to the server library.
I needed to move to the VSTS Octopus Package step for a couple of the projects - simply because I wanted to control when the packaging took place i.e. I wanted to control project build order so that some “plugin” dlls were built and ready for packaging when the package step got called.
I expected the package step to just call the Octopack logic and work in exactly the same way. But it clearly doesn’t.
The Octopack output is much cleaner.
Do you have any advice on how to achieve the same output with the VSTS package step? (e.g. Octopack considers csproj and items marked as content and will consider any extra files specified in a project nuspec etc.)
Thanks for reaching out! You are right, Octopack and Octo.exe pack (which is was the VSTS step uses in the background) do not work the same way.
Octopack was initially conceived for vs solutions with csproj files, but the problem was that it didn’t really work for other kinds of projects. That was the main reason behind the creation of Octo.exe pack, which is a “dumber” packer that simple puts the entire content of a folder into a zip/nuget package.
RE your comment about the cleaner output, it is true that Octo.exe pack doesn’t show you each file that’s being added to the package like Octopack does. I’m gonna mention that Idea to the team and see if they think we should implement it.
As for an advice about the usage of the Octopus Package step, my only advice is to keep in mind that the packer is really simple and It’ll just pack whatever is in the folder you point it to. So you need to make sure that your build output puts all the files needed in the folder that’s about to be packed.
In case anyone is following this thread.
I added a copy step with a couple of exclusions and that’s good enough for my purposes right now: *.
!*.cs
!**.pdb