Define Dependencies

This topic explains your options for dependency customizations and in which scenarios you are most likely to need them.

Build and runtime dependencies

Dependencies are broken up into two main types: build dependencies and runtime dependencies. Build dependencies are needed while your package builds and runtime dependencies are those packages needed when your Chef Habitat service is running.

You will need to declare the following dependencies for the Contoso University ASP.NET Chef Habitat plan:


This will allow the nuget.exe command line tool and msbuild.exe (included in visual-build-tools-2017) to be available and on the path at build time. These tools include functionality for populating nuget package dependencies and compiling .net source code. We also include the dotnet-45-dev-pack package which includes the .net 4.5 reference assemblies required for compiling a C# project targeting the .net 4.5 runtime. However there is no need for these dependencies at run time.

At runtime we will need the .net 4.5 runtime installed. We will also need to make sure that IIS and the aspnet 4 IIS features are enabled. Additionally, we will be relying on the core/dsc-core package in our runtime hooks which we will cover in more detail later.

If you require additional runtime or buildtime dependencies, you can add them into your plan.ps1 using the $pkg_deps and $pkg_build_deps settings, respectively. For example, if you wanted to implement a custom Invoke-Download callback to pull your application source from a git repository, you would need to add another build time dependency on core/git to your plan.ps1.

There is a third type of dependency, transitive dependencies, that do not need to be explicitly declared in your plan file. They are automatically included in the list of files when your package is built. A transitive dependency for our plan is iis-webserverrole which is a direct dependency of iis-aspnet4. See Package contents for more information.

Use the Chef Habitat Builder UI to search for dependencies

By going to the Chef Habitat website, you can search for packages built by the Chef Habitat team and members of the community, and use them in your own applications and services.

Type in the name of your dependency (such as git). You will get a search result list back with available public packages. Any packages with the origin "core" are foundational packages managed and maintained by the Chef Habitat maintainers.

Clicking on one of the entries will show you all of the versions of that package that have been uploaded to Builder. By convention, version numbers align with the version of the binary, library, or framework that the package has bundled up. For example, the core/visual-build-tools-2017 version 15 package has v15 of the Visual Studio Build Tools binaries and libraries.

The Builder UI also provides channel information about the package, as denoted by the stable and unstable labels. Channels function like continuous delivery stages in a pipeline (development, QA, production, etc.). When packages are initially uploaded to Builder, they are placed in the unstable channel, and by default, only stable packages are downloaded and installed in a given container, virtual machine, etc unless otherwise specified through the hab svc load command. By convention, the latest version number with the latest build date will be the stable version of the package.

Additionally, the available platform of each package version is included. Builder currently only supports Linux and Windows.

After you have decided on a version, click on it to see the manifest for the package.

All specific information on how that package was built will be contained within the manifest and if it is a core package, the plan for that package will be in the core-plans repo in GitHub.

Next: Define Build Logic For Your App