ASP.NET Core + .NET Core + TeamCity + Octopus

Legacy Uncategorised
1

As with everything Core, support by third-party tools is spotty at this point. I wanted to check with you to see if you have a good solution for packaging an ASP.NET Core w/ .NET Core application. I have reviewed the following urls:

Packaging Applications - which says to use dotnet pack but links to an article that uses dotnet publish. ‘dotnet pack’ may also not be relevant to ASP.NET Core because it doesn’t pack the MVC Views.

Deploying ASP.NET Core Web Applications - Which uses command line to do do the packaging.

The later seems closest to what I need to do but wedging that into TeamCity is not straightforward. I have installed the TeamCity .NET Core plugins to get access to ‘dotnet publish’ but I can’t find a good way to octo pack the resulting folder of files. With full .NET framework apps there is a nice Octopus plugin that gives a checkbox to do this.

Do you have any suggestions on how to octo pack that folder of files short of deploying and maintaining a copy of octo.exe on every build agent and accessing it via PATH?

Thank you,
Kevin

2

Hi Kevin,

Thanks for getting in touch. We don’t currently have any pre-built solutions, however something I did with one of our apps was dotnet publish to a folder, and then dotnet pack that folder with a new project.json that is just set to bundle up the whole folder.

In my example I have a file called pack.json which gets copyed to the publish folder on publish and renamed to project.json. So in the original project.json we have:

  "publishOptions": {
    "mappings": {
      "project.json": "pack.json"   //<---- this line copies pack.json in our source folder to our publish folder and renames it to project.json
    }
  }

That pack.json file is a fully valid project.json file that is used to build the actual nuget package and has options set to just include (almost) everything:

    "packOptions": {
        "projectUrl": "https://github.com/OctopusDeploy/Calamari/",
        "licenseUrl": "https://github.com/OctopusDeploy/Calamari/blob/master/LICENSE",
        "files": {
            "include": "**/*.*",
            "exclude": [ "project.json", "FSharp/*.xml", "ScriptCS/*.ps1" ]
        }
    }

Since it is only used to bundle your app up and not to build it, it only needs to include information used in the pack step.

So your process looks something like:

dotnet publish path\to\application\project.json -f netcoreapp1.0 --output path\to\published\app
dotnet pack path\to\published\app\project.json -f netcoreapp1.0

I might be missing some flags to the dotnet commands there, but hopefully you get the idea.

You can see this in action in our open source Calamari library here. There is a little extra complexity there because we’re building that app for .NET Core and .NET 4. I haven’t tried this in TeamCity as we’ve started using Cake build scripts to handle this sort of thing, but have used their .NET Core plugin and think it should work as a two step process.

I hope that helps, let me know how you go.

Mark

3

Is there a suggested method now for the csproj based asp.net apps and VS 2017?

4

Hi Brian,

Our official guidance is still https://octopus.com/docs/guides/deploying-asp.net-core-web-applications. Essentially dotnet publish and then package up the output folder, I don’t believe this changes with the move back to csproj. The longer guidance below was a way to get a valid nupkg without using Octo.exe or an external tool, which makes things more complicated.

If you are on TeamCity and the Octopus built in feed I would be tempted to use TeamCity’s dotnet publish build step, and then use their artifacts feature to create a versioned zip and push that to Octopus, as we support zip packages. So the artifact path in TeamCity (https://confluence.jetbrains.com/display/TCD10/Configuring+General+Settings) would be something like publish_folder => my_app.%build.number%.zip

I hope that helps.
Mark