I’m aware that this is almost exclusive a TeamCity thing, but support seems to be MUCH better here and i’m really struggling. And i guess it’s somewhat related as Octopus will be deploying my NuGet packages…
My problem is, that i simply cannot get my project packaged into a NuGet package, and i don’t know what i’m doing wrong.
The project is based on .NET Core 2.0 and as such i’ve installed the “.NET Core Support”-plugin as well as CORE on the agent server (Windows Server 2016).
I have 2 build steps:
Restore (using dotnet restore to fetch dependencies)
What happens, though, is that i fetches dependencies from nuget, it builds and everything succeeds, but i see no nuget packages. Not in the TeamCity NuGet feed or in the projects artifacts tab.
Obviously it’s an operator error and i’m doing something wrong/not configuring something. I just have to idea what.
What confuses me the most is the whole output/artifacts directory and when, how and what they should be set to.
Anyone who can help enlighten me and get me going with my project and actaully get to use Octopus for deploying?
I’m doing the same thing and we haven’t solved it yet but I think we are reasonably close.
We are not doing DotNet Pack however. Instead we are doing DotNet Publish and then we create a zip based on the output from the Publish step. That much is working.
We will then push the zip to Octopus and create the release from the zip.
Thanks for reaching out! Totally a TeamCity question but I can give you a hand anyways :). I even had my first ASP.NET Core 2 project setup in TeamCity this week so I learned a thing or 2 about it.
Few starting comments:
Right away I can tell you that dotnet pack packs your application, but it doesn’t push it to a repository. So I wouldn’t recommend you to use it in your process.
Since its your first time with Octopus, I recommend you to push your package to the Octopus built-in directory, and then tell your deployment process to grab the package from there instead of doing it from TeamCity.
The way I structured my TeamCity steps to build my .NET Core 2 project was like this:
A powershell step that runs dotnet restore to restore my nuget packages, and then dotnet publish to send the compiled binaries to a fixed directory which in my case was %teamcity.agent.home.dir%\publish. You could also do this with 2 steps, one for restore and another one for publish. In my case I rather have less steps in TC and use Powershell instead. The important thing is that publish sends the files to a fixed directory which will be used in the next step. (see screenshot 1)
An OctopusDeploy: Push Packages step which comes with the Octopus TeamCity Plugin. This step not only pushes your packages, but it also creates them. In this step I’m packaging everything that the publish command sent to this %teamcity.agent.home.dir%\publish folder into a single package that then gets pushed to Octopus. (see screenshot 2)
Thank you for the great answer, Dalmiro. Working with zip-files instead of NuGet-packages worked perfectly and my project goes from commit, though testing and on to my test server without problems.
I’m curious as to what i’m “loosing” when using zip instead of NuGet. What am i giving up on?
Nuget packages are basically Zips with metadata. So you are giving up all the features related to the package metadata. The only one that’s actually useful is the ability to inject release notes right in the package which Octopus can display in the release page.
The other thing is that Octopus can only work with .zip files as long as you push them to the built-in repository. If you decide to move to a 3rd party repository (Proget, Myget, the TC built-in repo, etc), you’ll need to use the Nuget format for the time being. We might eventually support .zip packages from 3rd party feeds, but not in the short future.
