Visual Studio 2017 – Why can’t I see the local and auto variables during UWP app debugging?

I’d like to share my short episode regarding UWP app debugging which happened today. Recent days I’ve developed a WinRT dynamic library which is based on cppwinrt. Most of time, I tested it with an unittest project and everything went fine. However, when I used the WinRT dll from actual .exe UWP application then very strange problem showed up.

As you see the below screenshots, the Visual Studio 2017 debugger shows nothing about local variables, auto and even watch window variables during the UWP app debugging.

Moreover, if I tried to type specific variables into Watch window or immediate window, the debugger shows ‘Internal error in the C# compiler‘ error message!

Later I noticed that the strange problem starts just right after the following output messages come up from Output window.

‘Example.exe’ (CoreCLR: CoreCLR_UWP_Domain): Loaded ‘Anonymously Hosted DynamicMethods Assembly’.

‘Example.exe’ (Win32): Loaded ‘C:\src\Example\build\Win32\Debug\AppX\Example.winmd’. Module was built without symbols.

‘Example.exe’ (CoreCLR: CoreCLR_UWP_Domain): Loaded ‘C:\src\Example\build\Win32\Debug\AppX\Example.winmd’. Module was built without symbols.

How just loading .winmd file could affect the weird debugger problem? Then I realized I used the same name(‘Example’) for the application and the WinRT module both. Which means I created the WinRT dll component as ‘Example.DLL’ and along with ‘Example.winmd’ as its descriptive winmd file name, of course. But I also named the target UWP application as ‘Example’.

So while debugging, the debugger tried to load the winmd file for it’s target WinRT component which was being debugged and suddenly the namespace seemed clashed within between the app and debugee DLL.

So, I changed the name of the WinRT component as ‘Example.Library.dll’ and problem solved!

Thanks,

Heejune

Beginning the coroutine with Visual Studio 2015 Update 3 Part 2

As we discussed through Part I, co_wait keyword requires sort of “resumable thing”. So what if we want to use co_await with time delta?

For example, you can see the code which the co_await takes std::chrono::duration in order to suspend for the specified time from here: https://github.com/Microsoft/cppwinrt/blob/master/10.0.14393.0/Samples/JustCoroutines/Main.cpp#L31

The answer is the fact that vc++ compiler allows co_await to be overloaded. So, we can overload the co_await keyword and returns the “resumable thing” within the overloading implementation.

See the code here. https://github.com/Microsoft/cppwinrt/blob/master/10.0.14393.0/winrt/base.h#L8897

If you follow the resume_after(), then you’ll clearly see it actually returns the instance of resumable thing struct which contain implementations of await_ready, await_suspend, and await_resume.

https://github.com/Microsoft/cppwinrt/blob/master/10.0.14393.0/winrt/base.h#L8643

Let’s test with another test sample here. https://github.com/heejune/wrl-cppwinrt-sample/blob/async-support/SampleLib.Shared/DemoCore.cpp#L81

In this sample, I called the winrt’s co_await as the above sample illustrated.

And if I step into the co_await… we hit the overloaded co_await.

part_ii_1

Step in again, then finally it creates resume_after struct instance and calls the await_suspend.

part_ii_2

part_ii_3

It spawns timer thread with specified time, and finally resume_after::callback static callback is being called.

part_ii_3-4png

The callback will finally call resume().

part_ii_4

And the resume() transfers its context into where the co_await being called.

part_ii_5

And lastly, the coroutine function hits the co_return keyword after looping 5 times,

part_ii_6

And reached the end.

Next time, I’d like to talk about another co_await adapter ‘await_adapter’ which makes winrt IAsync.. types possible to be awaitable. Thanks.

Heejune

Building WinRT component with WRL(non C++/CX) and cppwinrt

The cppwinrt project focused to consume Microsoft provided OS winrt components and it doesn’t support building a winrt component(yet) although they mentioned it will be supported later.

Even though it’s not technically supported yet, we still can create a winrt component with WRL(pure C++ and non C++/CX) and still can get some benefits from using cppwinrt within WRL component.

For example, I created a WinRT sample component with WRL and exports IAsyncAction async methods from it. Inside the method, I utilized the cppwinrt provided coroutine method which easily can produce IAsync operations. See the following:

https://github.com/heejune/wrl-cppwinrt-sample/blob/async-support/SampleLib.Shared/DemoCore.cpp

There’s a DemoCore::GetCppwinrtDataasync method defined as this:

It just (detached and) returns the object which also returned from GetAsyncOp private method. GetAsyncOp is a coroutine function which also creates an instance of winrt::Windows::Foundation::IAsyncOperation. And that’s the winrt implementation of IAsyncOperation.

You can download the source project and test it from https://github.com/heejune/wrl-cppwinrt-sample/tree/async-support

Thanks,

Heejune

[C++/Cx] How can I get the AsyncOperationWithProgress progress?

Windows Runtime provides the HttpClient class along with async APIs. For example, you can send a GET request through the GetAsync(Uri) method.

GetAsync() method is an awaitable API so that it returns IAsyncOperationWithProgress<HttpResponseMessage, HttpProgress>^. You will get the HttpResponseMessage by specifying the IAsyncOperationWithProgress to Concurrency::create_task(). However, how can I get the progress?

There’s no direct answer from MSDN but gives a hint here:

You just supply the delegate for the object’s Progress property

Here’s the snippet: