* Deprecated Azure::Core::ApplicationContext because its use is confusing and inconsistent with the original design.
---------
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
Co-authored-by: Anton Kolesnyk <41349689+antkmsft@users.noreply.github.com>
Co-authored-by: Ahson Khan <ahkha@microsoft.com>
* Make it clear that the BUILD_TESTING option is for testing purposes for contributors of the SDK and not supported for production use.
* Update FolderList.cmake to make a similar note.
* Fix spelling errors.
* Update CONTRIBUTING.md
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
* Update GPL link
---------
Co-authored-by: Rick Winter <rick.winter@microsoft.com>
* lll
* sss
* oipio
* vcvc
* enable test proxy start at test suite start for KV and storage , example created for attestation, we cannot find the base definitions for the test suites,
* Contrib
* clangs
* clangs
* test logs
* pipeline
* more clangs
* pipeline
* clang
* try try again
* try try again
* try again
* try again
* again
* update paths , moved to macro , call macro in target code
* core
* capitalization
* Update relative links to sections in the contributing guide doc to fix link verification
* Make some source code change modifications to trigger GenerateRelease CI steps
* Don't use relative paths in links, instead use the full path from master to be consistent with other places
* Get static/dynamic CRT link options in sync
* Update docs
* PR feedback
* en-us
* Another 'en-us' in a link
* MSVC_USE_STATIC_CRT
* Update README.md
Co-authored-by: Anton Kolesnyk <antkmsft@users.noreply.github.com>
It is generally useful for PR authors to go through their own PR first to make sure that commonly occurring feedback and issues have already been addressed. This checklist should help remind contributors what to look out for and is a living doc that we can modify and add to.
I ask these questions to myself before submitting a PR, when looking through my changes in the "pre-PR-submit-view".
Where possible leverage linter tools and CI gates to help address some of these. For example, for spell-check, here are some solutions to make things easier within the developer inner-loop:
- VS Code extension: [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker)
- VS Code extension: [Markdown linter](https://github.com/DavidAnson/vscode-markdownlint)
- Browser extension: [Site Spell](https://www.site-spell.com/)
Adding CMake module to enable/disable transport adapters
TRANSPORT ADAPTER BUILD
Default: If no option is explicitly added, curl will be used for POSIX and WIN HTTP for WIndows
Windows: Both CURL and WIN_HTTP can be build to be used.
POSIX: Only CURL is acceptable. If WIN_HTTP is set, generate step will fail for user
Defines `BUILD_WIN_HTTP_TRANSPORT_ADAPTER` and `BUILD_CURL_HTTP_TRANSPORT_ADAPTER` for source code
Fixes#350
Added build arguments to pass to cmake for running tests. If these
options are not passed during cmake build and someone tries to run test,
it will throw error "No tests were found!!!"
Cmake fails to find packages(curl, etc) if VCPKG_DEFAULT_TRIPLET is not set to x64-windows-static. If not set, cmake sets VCPKG_TARGET_TRIPLET to x64-windows instead of x64-windows-static. Since curl was installed using x64-windows-static in vcpkg, cmake fails to find the package. Adding set VCPKG_DEFAULT_TRIPLET to x64-windows-static explicitly in build instructions so that it is helpful to avoid cmake error(could not find CURL)
Larry Osterman
George Arama
Ahson Khan
Ronnie Geraghty
Peng Li
Victor Vazquez
Anton Kolesnyk
Wes Haggard
Sima Zhu
ku-sourav
Ahson Khan
Rick Winter