* Removing the two param RFE ctor, there should be no callers
* Remove the two param RFE ctor from the source file.
* Fix-up unit test and add a changelog entry.
* Remove test that uses the removed ctor.
* Delegate to RFE string ctor and move impl from header to src.
* Removing the two param RFE ctor, there should be no callers
* Remove the two param RFE ctor from the source file.
* Fix-up unit test and add a changelog entry.
* Remove test that uses the removed ctor.
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.
* Use code coverage annotations in places that never can be covered
* Comments
* Increment goal
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
* ignore result of function
* changelog
* Add g++5 to CI legs
* use inline config for g++ 5
* update flag
* set default values for variables
* fix format
* Make WinHTTP transport adapter to NOT use SSL/TLS for unsecured HTTP connections
* Update changelog for identity as well
* LocaleInvariantCaseInsensitiveEqual + micro-optimization to avoid creating&allocating std::string each time
* Update sdk/identity/azure-identity/CHANGELOG.md
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
* Progress stream reader
* format
* Update sdk/core/azure-core/src/io/body_stream.cpp
Co-authored-by: JinmingHu <jinmhu@microsoft.com>
* PR comments
* remove
* one more comment
* replaced if null with azure_assert
* moved from pointer to reference
* first pass
* src builds
* new line
* huzaaaaa
* readme
* strating point
* get progress, need to deserialize now
* serializer
* some more
* tests
* more tests
* some refactor
* start
* comment and formatting
* working again
* couple of updates
* clang
* remove pedantic ;
* include
* pr comments
* clang format
* trigger
* trigger 2
* PR comments
* name value swap
Co-authored-by: JinmingHu <jinmhu@microsoft.com>
* Move the SHA256, 384, and 512 Hash implementations to be internal.
* Update changelog and add back missing file.
* Rename SHA256 and others to Sha256Hash and update header name.
* Fix up path in CMakeList by removing quotes.
* Rename the sha.cpp source file to match header.
* Move Sha256Hash and other Hash algorithm types from KeyVault to
Azure::Core.
* Reorder src file in cmakelist to be alpha order just to reset CI
* Revert "Reorder src file in cmakelist to be alpha order just to reset CI"
This reverts commit 6729cf311af76bb8388738cc519ea40092bc362c.
* Use TCP fast open and false start to reduce RTT from 3 to 1, when using WinHttp on latest Windows OS.
* Address PR feedback - Remove logging the error.
* first UT
* formatting
* unused error
* putenv
* some refactoring
* formatting
* casting
* again
* Update sdk/core/azure-core/test/ut/environmentLogLevelListener_test.cpp
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
* some refactoring
* more tests
* format
* no env test
* put back missing empty line
* Update sdk/core/azure-core/test/ut/environmentLogLevelListener_test.cpp
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
* PR comments
* fix signed/unsigned mismatch that causes ci build to fail
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
