2aae6be7a3
It all started with UWP. The [docs](https://docs.microsoft.com/en-us/cpp/cppcx/crt-functions-not-supported-in-universal-windows-platform-apps?view=msvc-170) say: "`Environment variables are not available to UWP apps.`". And it truly won't work, I tried: linker error, the function is simply not present. So, for a year or so, we were `ifdef`ing everything enivoronment-related: console logger, environment credential, managed identity credential. And then just recently we wanted to enable our CI for UWP, including tests and samples. And it required to do more ifdefs (in vcpkg, we don't build samples or tests, so that problem did not exist). It just became more messy. Especially in samples - you can see how we would disable warning with `#pragma warning(disable : 4996)` or defining `_CRT_SECURE_NO_WARNINGS` already, but now came UWP, so we would have to add comment that `getenv()` is not available and make the sample compilation to either fail with clear message, or throw an exception. Plus we would have to detect that we are being compiled on UWP, which also adds visual clutter for reader. You can see how such an irrelevant (for a sample) thing as `getenv` was consuming more and more lines of sample code and reader's attention. But then! I read docs on more APIs for UWP. And I noticed that on .NET you can read environment variables. So I went and checked Win32 API docs for [GetEnvironmentVariable()](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getenvironmentvariable) - it says: "`Minimum supported client: ... UWP apps`". **GetEnvironmentVariable() works on UWP!** And so does `SetEnvironmentVariable()` (our tests use it, which means we can make all of them work and execute for UWP). That's good news, but now it would probably be more code: it usually takes more lines to invoke WinAPI, it is no more an one-liner to call `getenv()/setenv()`. So, I encapsulated that into `Azure::Core::_internal::Environment::GetVariable()` and `SetVariable()`. You can see how much less ifdefs is in our code now. Not to mention it works on UWP! Per team request, that API is SDK-internal. Samples use their own mini-helper project, `get-env-helper` that makes is so that `getenv()` works naturally on Linux and macOS, compiles without warnings and works on Win32, and compiles and works on UWP (using `GetEnvironmentStringsA()`) If it was for me, I would just make `Azure::Core::Environment::GetVariable()` public and simplify even further, I think it would be beneficial for sample readers (you can see that extra `get-env-helper` stuff adds just a little more visual clutter, compared to nothing). But I can see reasons against that, why team did not want to do it. |
||
|---|---|---|
| .. | ||
| .devcontainer | ||
| src | ||
| CMakeLists.txt | ||
| LICENSE | ||
| README.md | ||
Integrating the Azure SDK for C++ into your application using vcpkg
This application shows how to integrate the Azure SDK for C++ in your application. It uses vcpkg to adquire and build the Azure SDK for C++ client libraries. Your CMake project needs to link the libraries from vcpkg by setting the toolchain file to vcpkg (shown below).
Pre-requisites
There are two options to set up the development environment:
Manual installation
Install the Azure SDK for C++ dependencies.
- CMake project (min version 3.13).
- C++ version 14 or greater.
Container
The sample provides a .devcontainer folder which can be used by VS Code to build and run a docker container with the required C++ build tools and with vcpkg installed.
This method requires VS Code + Remote Container to be installed in the system. Also make sure to have Docker installed and running. This method works for any operating system where Docker and VS Code is supported like Windows, Linux and macOS. The development environment will be Debian 10.
- Open vcpkg folder in VS Code.
- VS Code will detect the
devcontainerconfiguration and ask you if you would like to re-open the folder in a container. Click Yes. - If VS Code did not ask, you can press F1 and type
Reopen in containeroption.
Once VS Code builds and run the container, open the terminal and continue to build step.
Note: The container is set up to automatically link vcpkg to CMake projects by setting env variables that the CMake sample project will use to set the toolchain.
Build
Linux terminal
#
# Building the application.
# Instructions from application root directory.
#
# Create build directory just the first time.
mkdir build
cd build
# Generate and build
# This code assumes that the SDK dependencies were installed with vcpkg
# When using docker provided container, the TOOLCHAIN option is not required (cmake ..).
cmake -DCMAKE_TOOLCHAIN_FILE=path/to/vcpkg/scripts/buildsystems/vcpkg.cmake ..
cmake -build .
Windows VS
If you are using Visual Studio, the toolchain to link vcpkg is set with CMakeSettings.json. Upate this file and set the vcpkg toolchain file for vcpkg (VCPKG_ROOT\scripts\buildsystems\vcpkg.cmake). After setting the toolchain, VS can generate and build the sample. Use VS to open the sample folder only.
Run application
Review source code header for environment variables that must be set up before running the app.
#
# Running the Application
# Instructions from inside the build directory.
#
# Run binary (.exe on Windows)
./application