Vcpkg for UWP target not found.

[geoiglesias]

Initially I built a x64-windows console App using c++winrt and used .\vcpkg.exe install azure-storage-cpp:x64-windows to build azure-storage-cpp and it worked well.

I am now building a x64-windows UWP App using c++winrt and would like to use the azure-storage-cpp in that project. However .\vcpkg.exe install azure-storage-cpp:x64-uwp returned the following:

Installing package atlmfc[core]:x64-uwp... done Installing package brotli[core]:x64-uwp... done Installing package zlib[core]:x64-uwp... done Installing package cpprestsdk[brotli,compression,core,default-features]:x64-uwp... done

CMake Error at scripts/cmake/vcpkg_fail_port_install.cmake:93 (message): Target 'UWP' not supported by azure-storage-cpp! Package: azure-storage-cpp:x64-uwp Vcpkg version: 2020.06.15-nohash

UwpBuildIssue.txt

Oh no! Is there a work around for using azure-storage-cpp on a UWP c++Winrt x64 app?

Platform Microsoft Visual Studio Enterprise 2019 Version 16.7.5 v1.42 platform version 10.0.17763.0

[Jinming-Hu]

@geoiglesias this SDK doesn't support UWP yet.

[Jinming-Hu]

@geoiglesias Is there any possibility that you build it from source to a library (.dll or .lib)?

[geoiglesias]

Hi Jinming-Hu ... thanks for getting back to me. I built the libraries using vcpkg for windows_x64 targets and integrated them into my uwp c++winrt app. I opened an issue with that approach here: Using Azure Storage in C++winrt UWP blank App MicrosoftDocs/azure-docs#65045 It was closed as it was the wrong place for the issue.

In short the vcpkg built DLLs seem to work but any call directly or indirectly into an async function causes an abort from of the underlying mutex unlock when the async task completes.

However, I can rebuild the DLLs if needed given instructions. More than happy to. It was also mentioned in the above issue that a new release is forthcoming.

George

[geoiglesias]

Hi Any follow up on this issue or a new release of the API?

[Jinming-Hu]

In short the vcpkg built DLLs seem to work but any call directly or indirectly into an async function causes an abort from of the underlying mutex unlock when the async task completes.

Do other sync functions work?

I'm not familiar with UWP, but is it common to use dlls compiled for windows x64 in a UWP project? Don't we need some kind of cross-compiling here?

[geoiglesias]

On VS2019 v142 I created a c++winrt blank uwp App an placed test code to access my Azure storage when the user clicks the dummy button on the blank application main page. The following code is called....

        try
        {
            // Retrieve storage account from connection string.
            azure::storage::cloud_storage_account storage_account = azure::storage::cloud_storage_account::parse(storage_connection_string_remote);

            // Create the blob client.
            azure::storage::cloud_blob_client blob_client = storage_account.create_cloud_blob_client();

            // Retrieve a reference to a container.
            azure::storage::cloud_blob_container container = blob_client.get_container_reference(L"BlankAppTest");

            // Create the container if it doesn't already exist.
            container.create_if_not_exists();
        }
        catch (...)
        {
            std::wcout << U("Error: ") << std::endl;
        }

This issue is an exception is thrown in the locking mutex for the 'container.create_if_not_exists()' underlying wait() call.

Running this same code in a C++winrt uwp console app does not throw the exception.

is blob access via the wastorage.dll not allowed for some reason in uwp apps?

[Jinming-Hu]

@geoiglesias Your code looks fine. I want to know what kind of exception it is, have you tried to run it within a debugger checking the details of that exception? or try to print the information like

try {
    ...
}
catch (storage_exception& e) {
    std::cout << "storage exception: " << e.what() << std::endl;
} catch (std::exception& e) {
    std::cout << "std::exception: " << e.what() << std::endl;
} catch (...) {
    std::cout << "some other exception" << std::endl;
}

[geoiglesias]

Hi Jinming-Hu, Thanks for your support. I added the code you suggested. The code fails with an abort from an attempt to destroy a mutex after azure::storage::cloud_file_share::create_if_not_exists() completes. No exceptions are caught.

I created a self-contained solution in github here to show the failure I am seeing: https://github.com/geoiglesias/AzureTestApp.git

I am using On VS2019 v142 with the Universal Windows Platform (UWP) workload installed. The NuGet C++/WinRT is a standard C++ language projection v2.0.201113.7. The solution contains two simple projects and shared code to test the Azure CPP REST API

SharedAzureFiles – The shared code called from both projects to ensure the actual code is the same for both applications. The actual API calls are called from with in a background thread using winrt::Windows::System::Threading::ThreadPool::RunAsync See static void AzureApiTestFunctions::TestAzureRestApi() in AzureApiTestFunctions.cpp

AzureTestApp – UWP Application. I created a C++winrt blank UWP App and placed test code to access my Azure storage when the user clicks the button on the blank application main page. The code fails with an abort from an attempt to destroy a mutex after azure::storage::cloud_file_share::create_if_not_exists() completes.

AzureTestConsole – Console Application. I created a C++winrt console App and placed test code to access my Azure storage when the application is run. The Azure CPP REST API works fine here.

[Jinming-Hu]

Hi @geoiglesias, I'm no expert on UWP. But the situation is, at the moment, this sdk doesn't officially support UWP. I'm inclined to thinking that this is some problem of UWP not being able to consume native C++ DLL.

[geoiglesias]

Hmmm... that's too bad. The C# version of the library works fine but we are using C++. Is there a plan to support UWP apps with the C++ version in the future? UWP apps is the direction that MS seems to want all development to go. Thanks for your support again.

[Jinming-Hu]

Hi @geoiglesias , I don't think we're going to support UWP. Actually we're now actively working on the Track2 Storage SDK. This Track1 SDK is going to be deprecated soon.

What is your usage scenario? Does migrating to Track 2 SDK sound like an option to you? If you open an issue on Track2 requesting support for UWP support, it'll be very likely to be accepted.

[geoiglesias]

Hi Jinming-Hu, Thanks again for your support. I built the Track2 Storage SDK as you suggested and integrated the sample code from here: azure-sdk-for-cpp/blob/master/sdk/storage/azure-storage-files-shares/sample/file_share_getting_started.cpp into my C++WinRt UWP test application.

Good news. The Track2 Storage SDK works in a UWP app! Thanks.

The Track2 Storage SDK seems to still be in beta. Is there a time line for general release?

[geoiglesias]

Hi Jinming-Hu, Thanks again for your support. I am going to close this issue. and post any follow on question I have to the Track 2 repo. I updated my simple test repo, https://github.com/geoiglesias/AzureTestApp.git, to include the a UWP app using the current Track 2 SDK.

[Jinming-Hu]

Hi @geoiglesias we're planning a Track 2 stable release no later than Q1.

[mloskot]

Platform Microsoft Visual Studio Enterprise 2019

Annoy the maintainers via https://github.com/Azure/azure-storage-cpp/issues/274 to get the VS 2019 support :)