Del via

Development environment

  • Artikkel

Important

This is the Azure Sphere (Legacy) documentation. Azure Sphere (Legacy) is retiring on 27 September 2027, and users must migrate to Azure Sphere (Integrated) by this time. Use the Version selector located above the TOC to view the Azure Sphere (Integrated) documentation.

You can develop applications for Azure Sphere on Windows 11, Windows 10 Anniversary Update (or later), or on a Linux machine running Ubuntu 24.04 (pre-release), Ubuntu 22.04 LTS, or Ubuntu 20.04 LTS. If you use Windows 11, use the 22.02 (or later) version of the Azure Sphere SDK.

  • For Windows, install the Windows SDK. You can use Visual Studio, Visual Studio Code, or the command line to build, deploy, and debug applications on Windows.
  • For Linux, install the Linux SDK. You can use Visual Studio Code or the command line to build, deploy, and debug applications on Linux.

The Azure Sphere SDK includes the following major components:

  • Sysroots, which contain the libraries, header files, and tools that are used to compile and link an application that targets a particular API set.
  • Hardware definitions, which describe the hardware capabilities available on various hardware devices and can be used to specify these in app-manifest.json files.
  • CMakeFiles, which define the Azure Sphere extensions to CMake.
  • The Azure Sphere Command-Line Interface (CLI).

The Tutorials walk you through building and deploying your first application. We also provide a samples repo on GitHub that includes sample applications that demonstrate how to program Azure Sphere hardware and use the APIs.

Azure Sphere Application Runtime

The Azure Sphere Application Runtime provides two sets of libraries for high-level application development: the base APIs and the applibs APIs. The base APIs are based on libraries that don't exclusively target Azure Sphere devices, whereas the applibs APIs specifically target Azure Sphere devices. High-level applications built with the Azure Sphere SDK compile and link against these interfaces. These APIs can't be used in real-time capable applications.

The header files for the base APIs are installed in the Sysroots\API set\usr\include folders of the Azure Sphere SDK installation directory. The header files for the applibs APIs are installed in the Sysroots\API set\usr\include\applibs folder of the Azure Sphere SDK installation directory.

Tip

The POSIX C standard headers are located in two folders: Sysroots\API set\usr\include for general API headers and Sysroots\API set\usr\include\sys for low-level, system-dependent API headers. We recommend that you use the general APIs.

Tools

The Azure Sphere SDK includes the Azure Sphere CLI for managing devices, developing and deploying applications, and working with cloud services.

CMake, along with the lightweight Ninja build utility, provides build coordination for Azure Sphere applications. If you use Visual Studio, CMake and Ninja are installed automatically for you. If you use Visual Studio Code or Azure Sphere CLI, you must install them yourself on Windows or Linux.

Both Visual Studio and Visual Studio Code have Azure Sphere extensions that simplify Azure Sphere application development. With these extensions, you can easily build, debug, test, and deploy your Azure Sphere applications directly from the IDE. Both extensions have full support for Azure Sphere's CMake tooling.

Containers

Azure Sphere provides a container that packages the SDK in a stand-alone Linux environment. By using a container with a pre-defined build environment, you can avoid the steps of installing (or uninstalling and then reinstalling) the correct SDK build environment. You can modify the build environment to suit your own needs and replicate that environment to all your host machines at the same time with uniform results. See Use containers to build Azure Sphere apps for details. You can also use a container as part of a continuous integration scenario where a build pipeline such as GitHub Actions or Azure Pipelines automatically rebuilds your application whenever a change is made to the underlying code. See Add continuous integration to your container builds for details.

What is a container?

Containers are portable packages that come with their own lightweight environments that run on a host machine's kernel. Containers are lightweight because they use shared layers. These layers can be shared slices of an operating system or shared applications. Layers avoids the overhead of a virtual machine, which contains an entire operating system and all associated applications. Sharing allows containers to be small and boot quickly.

You can download containers from a container registry such as the Microsoft Artifact Registry (MAR).

What containers bring to Azure Sphere

The container for the Microsoft Azure Sphere SDK build environment provides you with a pre-made development environment. The container provides the following:

  • The version of Ubuntu Linux for the current Azure Sphere release
  • The current version of the Azure Sphere SDK for Linux
  • Additional tools needed by the SDK such as CMake and Ninja

Azure Sphere uses Docker containers that are configured with Dockerfile text files. You can author Dockerfiles that use a base container image to create a custom container for building Azure Sphere applications. Running the customized container downloads the latest base image if it is not on your host machine, builds the new customized container if needed, builds the specified application, and exits. You can then copy the output of the application build to a host machine that has the Azure Sphere SDK installed and sideload the application to a device. The custom build container is not typically used interactively, but it can be, for example, to diagnose build problems.