Go to file
Daniel Jurek c534a1e160
Cognitive Matrix Consolidation (#2947)
* Refactor template to use multiple builds on the same machine resetting the machine and runtime varaibles along the way

Move template expression out of default matrix parameters

Remove extra reference to ci/jobs.yml

Remove unnecessary ci.yml, change param declaration in devops-variables-set.yml

Heredoc

Fix set/reset scripts after testing with devops outputs

-ErrorAction Ignore

Smaller matrix

OsVMImage comes from machine, not parameters

Add Ubuntu 20 to matrix

Remove checkout: self, it is implied

Move machine-setup steps outside of loop

CODE_COVERAGE handling

tab

Remove creation of CODE_COVERAGE

Use AptDependencies and add apt update to dependency install step

Remove extra preparation steps

Enable code coverage check scenario

Add MacOS 11

Disable vcpkg cache

Coverage configuration

Pass parameter properly

bool -> boolean

Install coverage tools if it's possible that coverage may run

More logging on code coverage

Show contents of Makefile

One vcpkg to build them all

Verbose

SourcesDirectory

Nesting VcpkgInstall

workingDirectory for vcpkg install

AptDependencies

complete the conditional

Enable all matrix entries

sudo

Remove extra chatter

More scrubbing post-build to help with Windows scenarios

sudo echo

Get-ChildItem

ErrorAction

sudo sh -c

More ErrorAction

output sourceListFile

Disable additional sources.list

Install coverage tools when used for coverage

COndition

Do not build testing for Windows arm64

Correct path for coverage tools

ne -> eq

Add more scenarios to the matrix

Remove libxml2

Add MacOS 10.15 to matrix

Revert "Remove libxml2"

This reverts commit 178af8b89abb21ee84dbcd25b4d54bd90ec1d44c.

Add libxml2 to MacOS 10.15 matrix entry

Display name decorator, refine the matrix

Remove OsVmImage variable

Add commentary to tests about matrix

Rebalance matrix, nest EnvVars, DisplayNameDecorator

Correct parameter access

AptDependencies

Ensure building for WindowsStore in UWP builds, Only build tests for debug builds in altered matrix entires, Linux build type specified as environment variable

Rebalance matrix for better timing

Remove all instances of libxml2 in vcpkg dependencies

Move common devops tasks to eng/common

Set eng/common paths in pipelines

Revert "Remove all instances of libxml2 in vcpkg dependencies"

This reverts commit 35ffbc7aac87f400fdf3351076346750c1c750ed.

https://github.com/Azure/azure-sdk-for-cpp/issues/2946

Permit words like iname in more pipeline .yml files

Remove libxml2 from vcpkg dependencies for Windows

Perf test matrix maxParallel: 10

Validate

apt install first

apt install first

maxParallel: 12

-j 8

-j 10

Use matrix generator

Add expected parameters

Move parameters to appropriate file, fix cloud spec

Specify correct platform matrix location

DependsOn

Platform matrix

Remove DisplayNameDecorator, try more clang information

Rapid iteration matrix

clang --version

install clang-11

Use correct pool

Use full matrix, revert additional logic in jobs/ci.yml

* Review feedback: newline

* Review feedback: Test in release, too

* Remove DisplayNameDecorator (it was useful when we were putting multiple builds into a single job, now it is redundant)

* Remove displayNames

* Matrix review feedback

* Conditions

* Rename ci.yml -> ci.tests.yml
2021-10-22 13:49:10 -07:00
.devcontainer Devcontainer (#2861) 2021-09-10 15:55:33 -07:00
.github Update keyvault codeowners to reduce noise to signal ratio (#2791) 2021-08-25 00:57:04 +00:00
.vscode Cognitive Matrix Consolidation (#2947) 2021-10-22 13:49:10 -07:00
cmake-modules Enable no-rtti (#2963) 2021-10-14 18:12:03 -07:00
doc Remove warning supress (#2677) 2021-07-27 18:09:52 -07:00
eng Cognitive Matrix Consolidation (#2947) 2021-10-22 13:49:10 -07:00
samples fixup sample , add to build (#2808) 2021-09-01 18:04:20 -07:00
sdk Cognitive Matrix Consolidation (#2947) 2021-10-22 13:49:10 -07:00
.clang-format Retry policy (#241) 2020-07-10 00:23:40 -07:00
.gitignore Add Unit Tests for EnvironmentLogLevelListener (#2454) 2021-06-22 21:51:41 +00:00
CMakeLists.txt Enable no-rtti (#2963) 2021-10-14 18:12:03 -07:00
CMakeSettings.json Operations need to provide the RawResponse (#1803) 2021-03-05 20:33:14 -08:00
CODE_OF_CONDUCT.md Initial CODE_OF_CONDUCT.md commit 2020-01-10 15:45:21 -08:00
CONTRIBUTING.md Update links from master to main (#2488) 2021-06-24 22:27:14 -07:00
LICENSE.txt update main root license to be txt (#888) 2020-11-04 17:03:15 +00:00
README.md Fix build error in landing page example (#2602) 2021-07-13 23:03:08 +00:00
SECURITY.md Replaced relative link with absolute links and remove locale (#668) 2020-09-17 22:28:36 -07:00

Azure SDK for C++

Build Status

This repository is for active development of the Azure SDK for C++. For consumers of the SDK we recommend visiting our developer docs.

Getting started

For the best development experience, we recommend developers use CMake projects in Visual Studio to view and build the source code together with its dependencies. You can also use any other text editor of your choice, such as VS Code, along with the command line for building your application with the SDK.

You can find additional information for specific libraries by navigating to the appropriate folder in the /sdk directory. See the README.md file located in the library's project folder, for example, the Azure Storage client library.

For API reference docs, tutorials, samples, quick starts, and other documentation, go to Azure SDK for C++ Developer Docs.

Download & Install the SDK

The easiest way to acquire the C++ SDK is leveraging vcpkg package manager. You will need to install Git before getting started.

First clone and bootstrap vcpkg itself. You can install it anywhere on your machine, but make note of the directory where you clone the vcpkg repo.

> git clone https://github.com/microsoft/vcpkg

On Windows:

> .\vcpkg\bootstrap-vcpkg.bat

On Linux:

> ./vcpkg/bootstrap-vcpkg.sh

To install the libraries for your project, run the following, optionally specifying the triplet. For example, the following will install packages for the x64-windows triplet. On Windows, not specifying a triplet will default to x86-windows:

> .\vcpkg\vcpkg install azure-storage-blobs-cpp:x64-windows

See the list of packages available via vcpkg below. All Azure C++ SDK package names start with azure-. You can also search for the libraries you need with the search command. For example:

> .\vcpkg\vcpkg search azure-

Once the library is installed, follow the instructions from the console output to include the library in your CMake application. For example, to include azure-storage-blobs-cpp, add the following to your CMakeLists.txt file:

find_package(azure-storage-blobs-cpp CONFIG REQUIRED)
target_link_libraries(<your project name> PRIVATE Azure::azure-storage-blobs)

NOTE: All the Azure client libraries take a dependency on azure-core-cpp which provides functionality commonly needed by all Azure clients. When you install any client library via vcpkg, it will bring in all the necessary dependencies as well. You don't need to install those individually to get started.

You can reference this vcpkg Quick Start for more details.

Building your Application

In order to use the SDK installed via vcpkg with CMake, you can use the toolchain file from vcpkg:

> cmake -B [build directory] -S . -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg repo]/scripts/buildsystems/vcpkg.cmake
> cmake --build [build directory]

Using the SDK within your Application

The entry point for most scenarios when using the SDK will be a top-level client type corresponding to the Azure service. For example, sending requests to blob storage can be done via the Azure::Storage::Blobs::BlobClient API. All APIs on the client type send HTTP requests to the cloud service and return back an HTTP Response<T>.

Azure C++ SDK headers needed are located within the <azure> folder, with sub-folders corresponding to each service. Similarly, all types and APIs can be found within the Azure:: namespace. For example, to use functionality from Azure::Core, include the following header at the beginning of your application #include <azure/core.hpp>.

Here's an example application to help you get started:

#include <iostream>

// Include the necessary SDK headers
#include <azure/core.hpp>
#include <azure/storage/blobs.hpp>

// Add appropriate using namespace directives
using namespace Azure::Storage;
using namespace Azure::Storage::Blobs;

// Secrets should be stored & retrieved from secure locations such as Azure::KeyVault. For
// convenience and brevity of samples, the secrets are retrieved from environment variables.
std::string GetEndpointUrl() { return std::getenv("AZURE_STORAGE_ACCOUNT_URL"); }
std::string GetAccountName() { return std::getenv("AZURE_STORAGE_ACCOUNT_NAME"); }
std::string GetAccountKey() { return std::getenv("AZURE_STORAGE_ACCOUNT_KEY"); }

int main()
{
  std::string endpointUrl = GetEndpointUrl();
  std::string accountName = GetAccountName();
  std::string accountKey = GetAccountKey();

  try
  {
    auto sharedKeyCredential = std::make_shared<StorageSharedKeyCredential>(accountName, accountKey);

    auto blockBlobClient = BlockBlobClient(endpointUrl, sharedKeyCredential);

    // Create some data to upload into the blob.
    std::vector<uint8_t> data = {1, 2, 3, 4};
    Azure::Core::IO::MemoryBodyStream stream(data);

    Azure::Response<Models::UploadBlockBlobResult> response = blockBlobClient.Upload(stream);

    Models::UploadBlockBlobResult model = response.Value;
    std::cout << "Last modified date of uploaded blob: " << model.LastModified.ToString()
              << std::endl;
  }
  catch (const Azure::Core::RequestFailedException& e)
  {
    std::cout << "Status Code: " << static_cast<int>(e.StatusCode)
              << ", Reason Phrase: " << e.ReasonPhrase << std::endl;
    std::cout << e.what() << std::endl;
    return 1;
  }
  return 0;
}

Key Core concepts

Understanding the key concepts from the Azure Core library, which is leveraged by all client libraries is helpful in getting started, regardless of which Azure service you want to use.

The main shared concepts of Azure Core include:

  • Accessing HTTP response details for the returned model of any SDK client operation, via Response<T>.
  • Exceptions for reporting errors from service requests in a consistent fashion via the base exception type RequestFailedException.
  • Abstractions for Azure SDK credentials (TokenCredential).
  • Handling streaming data and input/output (I/O) via BodyStream along with its derived types.
  • Polling long-running operations (LROs), via Operation<T>.
  • Collections are returned via PagedResponse<T>.
  • HTTP pipeline and HTTP policies such as retry and logging, which are configurable via service client specific options.
  • Replaceable HTTP transport layer to send requests and receive responses over the network.

Response <T> Model Types

Many client library operations return the templated Azure::Core::Response<T> type from the API calls. This type let's you get the raw HTTP response from the service request call the Azure service APIs make, along with the result of the operation to get more API specific details. This is the templated T operation result which can be extracted from the response, using the Value field.

  // Azure service operations return a Response<T> templated type.
  Azure::Response<Models::BlobProperties> propertiesResponse = blockBlobClient.GetProperties();

  // You can get the T, from the returned Response<T>,
  // which is typically named with a Result suffix in the type name.
  Models::BlobProperties propertiesModel = propertiesResponse.Value;

  // Now you can look at API specific members on the result object that is returned.
  std::cout << "The size of the blob is: " << propertiesModel.BlobSize << std::endl;

Long Running Operations

Some operations take a long time to complete and require polling for their status. Methods starting long-running operations return Operation<T> types.

You can intermittently poll whether the operation has finished by using the Poll() method inside a loop on the returned Operation<T> and track progress of the operation using Value(), while the operation is not done (using IsDone()). Your per-polling custom logic can go in that loop, such as logging progress.Alternatively, if you just want to wait until the operation completes, you can use PollUntilDone().

  std::string sourceUri = "<a uri to the source blob to copy>";

  // Typically, long running operation APIs have names that begin with Start.
  StartBlobCopyOperation operation = blockBlobClient.StartCopyFromUri(sourceUri);

  // Waits for the operation to finish, checking for status every 1 second.
  auto copyResponse = operation.PollUntilDone(std::chrono::milliseconds(1000));
  auto propertiesModel = copyResponse.Value;

  // Now you can look at API specific members on the result object that is returned.
  if (propertiesModel.CopySource.HasValue())
  {
    std::cout << "The source of the copied blob is: " << propertiesModel.CopySource.Value()
              << std::endl;
  }

Interacting with Azure SDK for C++

Static SDK members should not be accessed and SDK functions should not be called before the static initialization phase is finished.

Visual Studio - CMakeSettings.json

When building your application via Visual Studio, you can create and update a CMakeSettings.json file and include the following properties to let Visual Studio know where the packages are installed and which triplet needs to be used:

{
  "configurations": [
    {
        "cmakeToolchain": "<path to vcpkg repo>/vcpkg/scripts/buildsystems/vcpkg.cmake",
        "variables": [
        {
          "name": "VCPKG_TARGET_TRIPLET",
          "value": "x64-windows",
          "type": "STRING"
        }
      ]
    }
  ]
}

Azure Requirements

To call Azure services, you must first have an Azure subscription. Sign up for a free trial or use your MSDN subscriber benefits.

Packages available

Each service might have a number of libraries available. These libraries follow the Azure SDK Design Guidelines for C++ and share a number of core features such as HTTP retries, logging, transport protocols, authentication protocols, etc., so that once you learn how to use these features in one client library, you will know how to use them in other client libraries. You can learn about these shared features at Azure::Core.

The client libraries can be identified by the naming used for their folder, package, and namespace. Each will start with azure, followed by the service category, and then the name of the service. For example azure-storage-blobs.

For a complete list of available packages, please see the latest available packages page.

NOTE: If you need to ensure your code is ready for production we strongly recommend using one of the stable, non-beta libraries.

Vcpkg

The following SDK library releases are available on vcpkg:

  • azure-core-cpp
  • azure-identity-cpp
  • azure-storage-blobs-cpp
  • azure-storage-files-datalake-cpp
  • azure-storage-files-shares-cpp

NOTE: In case of getting linker errors when consuming the SDK on Windows, make sure that vcpkg triplet being consumed matches the CRT link flags being set for your app or library build. See also MSVC_USE_STATIC_CRT build flag.

Need help

Navigating the repository

Main branch

The main branch has the most recent code with new features and bug fixes. It does not represent latest released beta or GA SDK.

Release branches (Release tagging)

For each package we release there will be a unique Git tag created that contains the name and the version of the package to mark the commit of the code that produced the package. This tag will be used for servicing via hotfix branches as well as debugging the code for a particular beta or stable release version. Format of the release tags are <package-name>_<package-version>. For more information please see our branching strategy.

Contributing

For details on contributing to this repository, see the contributing guide.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, view Microsoft's CLA.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repositories using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Many people all over the world have helped make this project better. You'll want to check out:

Reporting security issues and security bugs

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) secure@microsoft.com. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter.

License

Azure SDK for C++ is licensed under the MIT license.

Impressions