Deploying a .NET Core Web API

Integration
1

Hi,

Back in the days of Octopack, I knew what I was doing.

In the new world of .NET Core, I do not.

I have read this page and it only left me confused https://octopus.com/docs/deployment-examples/deploying-asp.net-core-web-applications It states that “OctoPack is not compatible with ASP.NET Core applications”

I’m really not sure what I need to do to get Team City to build my WebAPI and create an Octopus deployment package.

Is that still possible, or do you need to create packages manually now?

There does not seem to be much in the way of tutorials. Is there a blog post or video anywhere which sets out how to go about this?

We have v3.14.15926 of Octopus installed.

Any guidance would be appreciated.

Cheers

3

Hi David,

Thanks for getting in touch. This is quite timely, we also recently published a blog post about building .NET Core apps in .NET Core, in case you haven’t seen it yet.

In there we covered off a bit about why OctoPack isn’t practical in the .NET Core world. The bulk of the post focuses on using .NET Core build agents (e.g. Linux agents), but the pattern for building is the same whatever the agent platform is. We have been planning a follow up post with a more detailed walk-through, and based on your request I’ve bump its priority up.

Here’s a preview though :slight_smile: The crux of the walk-through will be illustrating the TeamCity steps that correspond to the 3 commands shown in that post

dotnet publish MyAwesomeWebApp -o myMarshallingFolder
dotnet octo pack --id=MyAwesomeWebApp --version=1.0.0.0 --outFolder=myArtifactsFolder --basePath=myMarshallingFolder
dotnet octo push --package=myArtifactsFolder\MyAwesomeWebApp.1.0.0.0.nupkg --server=https://my.octopus.url --apiKey API-XXXXXXXXXXXXXXXX

The flow here is to publish the app to a folder, package the content of that folder then push the package to Octopus.

TeamCity has a step built in to handle the publish, if you go through the wizard and let it guess based on the repo contents it’ll probably include this straight up, it certainly did when I tested it. All you really need to do is decide on a folder name to publish to.

In the most recent update to our TeamCity extension we included a new Octopus step to do the pack (the update will work against any version of Octopus the previous version did, including 3.14, it’s now just exposing a function of octo.exe that it didn’t previously). Previously you just had to use the file globbing support in the Push step to package and push in 1 step. In the pack step, give it the folder you published to as the Source directory and give it another folder to Output to. I tend to use something like “artifacts” or “packaged”.

From there, you have 2 options. If you’re using TeamCity as an external feed then check the box to Publish packages as build artifacts. If you’re using the Octopus feed, add a push step (which is the third command from above).

I set Package paths to artifacts/%PackageId%.%build.number%.nupkg, where PackageId is a variable in TeamCity the pack and push steps both use. You can cheat here and use a wilcard instead of the exact filename, but I’ve had issues if the build folder doesn’t get cleaned out and it’ll try to publish the older versions it can see in the folder too.

Hope that helps and keep an eye out for the upcoming post, there’ll be illustrations that might make some it this clearer. If you have any other questions in the meantime please let me know.

Regards
Shannon

4

Thanks Shannon,

I have an initial question.
And I should also just point out that our build and target machines are all windows and the Web API runs on top of the full .NET Framework (the new EF Core stuff did not meet our requirements).

With the command :
dotnet tool install Octopus.DotNet.Cli --tool-path /path/to/install
the blog post recommends placing that in a folder “local to the user”.

Does that mean a folder like?:
C:\Users\[name-of-build-user]\AppData\Roaming

I guess that makes sense, as there are less likely to be any permissions issues there.

5

Hi David,

Sorry if that bit was a little confusing. The main idea is that if you do the global install it’s available to everything on the agent, and sometimes that can cause cross contamination. So “local to the user” was probably the wrong term to use, “local to the build” would have been better. You should be able to use a path relative to the root of the code repo and that should work. Then each build is isolated and 2 projects sharing an agent can’t tangle each other up.

Hope that helps clarify and I’ll look at doing an update to the blog post to change that bit.

If you’re using full framework that shouldn’t impact you. The TeamCity steps for OctopusDeploy: Pack and OctopusDeploy: Push take care of calling octo.exe or dotnet octo for you under the hood, so if you’re using the steps you shouldn’t need to be too concerned with that lower level bit or the dotnet tool install.

Regards
Shannon

6

Hi Shannon,

Sorry to be stuck on this point, but I still need to clarify “local to the build”. Does this mean I am adding a the Octopus.DotNet.Cli to my GIT repository? That’s the only way I can think of to have it local for that project.

But that does not seem correct, as your post talks about installing it on the build machine itself.

The Team City .NET CLI build step does not seem to have any way that I can see where you can specify directories or paths to 3rd party executables.

7

Hi David,

No problems, this isn’t a simple topic. By local to the build what I meant was that you’d run a script step in the build process along the lines of

dotnet tool install Octopus.DotNet.Cli --tool-path octoTools

this would pull down the Octo CLI extension for you and install it into a folder called octoTools, that would be a subfolder of where your code repo is on the build agent. So you don’t have to have it in Git, the install will pull it down from NuGet.org.

You’d then have a parameter, env.PATH, defined in the project to append to the default PATH environment variable. Setting it to a value of %env.PATH%;%teamcity.build.checkoutDir%/octoTools should do the trick.

If you are running on agents that only have .NET Core this will enable the Octopus Pack and Push steps to work. The .NET CLI build step itself doesn’t actually need the Octo CLI tool, so you shouldn’t need to change anything for it.

8

Hi Shannon.

Still stuck on this scripting step. The supported dotnet (CLI) commands in TC does not include “tool”.
So, I tried creating:

  1. a Powershell step; then when that didn’t work,
  2. a Command Line step.

But both errored out, complaining that they don’t know what “dotnet” is.

Not sure where to go from here.

9

Hi David,

Sorry for the delay, if you’re using the Octopus extension for TeamCity and you’re using our steps the Octo setup is bundled in there and you shouldn’t have to worry about it.

If you’re using custom steps and need to run the tool install manually you should just need a Command Line step that executes the install command from my last message. Based on the error you’re getting it sounds like the agent doesn’t have .NET Core itself installed. Does that sound likely? E.g. have you been able to run a .NET CLI (dotnet) build step on the agent?

You can do the build and publish to a folder before installing the Octopus CLI extenion, it just needs to be done before anything like dotnet octo pack or dotnet octo push gets executed.

10

Hi Shannon,

We are using the Octopus Team City plugin, but an old version of it.
So I will install the latest version at the earliest opportunity.

Those error messages are deceptive because dotnet Core is absolutely installed.
When I run dotnet – info :

PS C:\Users\ME> dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    adab45bf0c

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300\

Host (useful for support):
  Version: 2.1.0
  Commit:  caa7b7e2ba

.NET Core SDKs installed:
  2.1.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Will progress this after I update the Octopus plugin.
Cheers

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.