More needed

Would like to see specific examples of each major method as used - for example the StorageFolder method GetFilesAsync(). That one had been working for me and stopped building in 10.0.17666.0.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: a087153a-b34a-b9fc-0ba6-e96d14764455
Version Independent ID: 4db9d519-6a9d-a8f9-bd58-f67b32cd8548
Content: Concurrency and asynchronous operations with C++/WinRT - UWP app developer
Content Source: windows-apps-src/cpp-and-winrt-apis/concurrency.md
Product: uwp
GitHub Login: @stevewhims
Microsoft Alias: stwhi

Hi, @jevansAN. 17666 is an SDK Preview version, in between two released versions (the released versions being 17134 and 17763, respectively), and I don't have that exact version installed right now. I'd recommend that you move to released SDK version 17763, if you can. Here's a code example, and I can confirm that it builds and runs. I don't know what your build issue is, but if you're getting linker errors, then here's some info that might help: https://docs.microsoft.com/windows/uwp/cpp-and-winrt-apis/faq#why-is-the-linker-giving-me-a-lnk2019-unresolved-external-symbol-error.
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.Storage.Search.h>
IAsyncAction ExampleCoroutineAsync()
{
// Get the user's Pictures library.
// Enable the Pictures Library capability in the app manifest file.
Windows::Storage::StorageFolder picturesLibrary{ Windows::Storage::KnownFolders::PicturesLibrary() };
// Get the first 20 sorted images in the library, sorted by date.
Windows::Foundation::Collections::IVectorView<Windows::Storage::StorageFile> filesInFolder{
    co_await picturesLibrary.GetFilesAsync(Windows::Storage::Search::CommonFileQuery::OrderByDate, 0, 20) };

// Iterate over the results, and print the list of files to the Visual Studio output window.
for (Windows::Storage::StorageFile const& fileInFolder : filesInFolder)
{
    std::wstring output{ fileInFolder.Name() + L' ' };
    ::OutputDebugString(output.c_str());
}

}

Jeff, I'm sorry about the frustration. I don't recommend that you install an earlier SDK if that's what you mean. I recommend that you move to released SDK version 17763, if you can (which is the latest publicly released version). Btw, the latest released SDK version is always at
https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk. We'll be able to support you on a released SDK version better than we can with an SDK Preview version. ~Steve

Thanks, Steve, but I'm a little nervous about trying to downversion the SDK. This is a C++/Winrt project in the latest preview VS, the latest winrt included in the SDK and upon which the BlankApp for C++/Winrt created by VS probably depends. I spent the last few days rebuilding the project on top of that BlankApp.
I have just recovered the project from backup and since I made no progress today there is nothing lost yet but time. My current plan is to continue on with other parts of this large project in the hope that an SDK update will fix the problem with GetFilesAsync.
Jeff
On Oct 26, 2018, at 4:32 PM, Steven White wrote:
Jeff, I'm sorry about the frustration. I don't recommend that you install an earlier SDK if that's what you mean. I recommend that you move to released SDK version 17763, if you can (which is the latest publicly released version). Btw, the latest released SDK version is always at
https://developer.microsoft.com/en-US/windows/downloads/windows-10-sdk. We'll be able to support you on a released SDK version better than we can with an SDK Preview version. ~Steve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi, Jeff, when you say "downversion the SDK", do you mean move to an earlier version? You're on 17666. And it's my recommendation to move to a later version: 17763. I'm using the latest generally available (not Preview) version of VS (which is version 15.8.8) and the latest generally available version of the SDK (which is 17763), and not seeing issues with using the GetFilesAsync. I'm not on your exact versions of bits, so I appreciate that I can't repro your issues, and it might be asking a lot to switch horses to the latest generally available bits at this stage (rather than previews). We know that there are changes that need to be made to projects when moving a 17134 project to use the SDK version 17763, so you may run into similar issues there.

Ha, I misread. I was assuming that the latest generally available SDK would have a version number lower than that of the latest preview. But as far as VS is concerned I'm on 15.9.0, which at least is later.
The Win OS on this computer is version 1809, build 18262, but the targeted SDK is 17666. I haven't received any update notices for the SDK, I guess I can try downloading another SDK package.
I'm a little worried, though, that the template project created by VS 15.9.0 might not be compatible with VS 15.8.8. Afraid to change that.
Jeff
On Oct 26, 2018, at 4:49 PM, Steven White wrote:
Hi, Jeff, when you say "downversion the SDK", do you mean move to an earlier version? You're on 17666. And it's my recommendation to move to a later version: 17763. I'm using the latest generally available (not Preview) version of VS (which is version 15.8.8) and the latest generally available version of the SDK (which is 17763), and not seeing issues with using the GetFilesAsync. I'm not on your exact versions of bits, so I appreciate that I can't repro your issues, and it might be asking a lot to switch horses to the latest generally available bits at this stage (rather than previews). We know that there are changes that need to be made to projects when moving a 17134 project to use the SDK version 17763, so you may run into similar issues there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Steven,
I've updated VS and installed SDK 17763, but with the target set to 17763 I now see 1112 errors that are beyond my ability to respond, such as
"E0145 variable "RpcFreeAuthorizationContext may not be initialized" in file rpcasync.h.
The other new errors are in Canvas.h, combaseapi.h, hstring.h, etc.
Yet it built and ran just fine with the target 17666 - except for GetFilesAsync.

While I'm here perhaps I could ask: what is the correct setting for "minimum" SDK? If the target is 17763, presumably meaning the code may include features only found in 17763, wouldn't the minimum also have to be 17763? I've tried both that and 17666 for the minimum.

Thanks, Jeff

On Oct 26, 2018, at 5:27 PM, Steven White wrote:
the latest generally available SDK would have a version number lower than that of the latest preview
You're right there. But 17666 isn't the latest preview (17763 was a later preview, then it became the release candidate, then it became the release on 10/2). And we haven't released a preview since then. :) I hope the latest SDK (and VS 15.9) give you a path to a clean build.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi, Jeff, the E**** errors (for example, the E0145 that you’re seeing) are coming from the IntelliSense compiler. I’ve seen a lot of cases where those show up in the Error List (in Visual Studio) and they're false positives, so they’re actually not preventing the project/solution from building. For the genuine build errors, together with more information about them, I tend to look just in the Output window (in Visual Studio). Some folks have had success clearing those IntelliSense errors by deleting their *.SDF file. But to really clean a project (which I do after re-targeting), I tend to delete all folders named .vs, release, debug, ARM, x86, x64, Generated Files, and my *.user file.
There’s info here about moving between versions of the SDK that might help: How to retarget your C++/WinRT project to a later version of the Windows SDK
If you can get a minimal repro for the GetFilesAsync issue in a new 17763 project, and/or confirm that the code I pasted above does work (and see how or whether that differs from your usage), then I’d be keen to know more about that.
Regarding the Minimum Version (which actually means min platform version), there’s info about what that means here: Choose which version to use for your app. But, yes, thanks to adaptive coding (checking for the presence of an api contract before calling APIs in it), you can set min version lower than target. Essentially, if writing adaptive code (around APIs only in later versions of Win10) is worth the benefit of supporting earlier versions, then you can do that from a single binary.

Thanks very much, Steven - very helpful. I've posted an answer at StackOverflow explaining how I managed to get GetFilesAsync working- basically I skipped trying to use CommonQuery and simply called the GetFilesAsync method that uses no argument, plus I stopped trying to use the StorageFolder method to get a named internal folder and instead went with specifying the path and asking for the folder by its path.
That doesn't seem quite as safe but at least it works.
I'll look into skipping those Intellisense errors!
And I'm glad to see an answer about target vs. minimum.
Yours, Jeff
On Oct 28, 2018, at 6:16 PM, Steven White wrote:
Hi, Jeff, the E**** errors (for example, the E0145 that you’re seeing) are coming from the IntelliSense compiler. I’ve seen a lot of cases where those show up in the Error List (in Visual Studio) and they're false positives, so they’re actually not preventing the project/solution from building. For the genuine build errors, together with more information about them, I tend to look just in the Output window (in Visual Studio). Some folks have had success clearing those IntelliSense errors by deleting their *.SDF file. But to really clean a project (which I do after re-targeting), I tend to delete all folders named .vs, release, debug, ARM, x86, x64, Generated Files, and my *.user file.
There’s info here about moving between versions of the SDK that might help: How to retarget your C++/WinRT project to a later version of the Windows SDK
If you can get a minimal repro for the GetFilesAsync issue in a new 17763 project, and/or confirm that the code I pasted above does work (and see how or whether that differs from your usage), then I’d be keen to know more about that.
Regarding the Minimum Version (which actually means min platform version), there’s info about what that means here: Choose which version to use for your app. But, yes, thanks to adaptive coding (checking for the presence of an api contract before calling APIs in it), you can set min version lower than target. Essentially, if writing adaptive code (around APIs only in later versions of Win10) is worth the benefit of supporting earlier versions, then you can do that from a single binary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

Steven, If you don't mind a follow-up: I'm trying a retargeting right now - my solution for GetFilesAsync worked in one method but not in another, so the whole thing seems unstable - and I am attempting the second of the methods mentioned in the linked article about retargeting.
That is, I right-clicked the project node and selected retarget to 17763, Then did a Clean and then Build, which did produce errors that I'll paste below in case they're of interest.
I did go so far as to delete the .vs folder.
But I'm a little worried about proceeding to the next steps you suggest. If I delete the Debug folder, that will delete the Assets folder and also Microsoft.Graphics.Canvas.dll and Microsoft.Graphics.Canvas.winmd - would this then require me to add those capabilities back to the project? One reason I rebuilt this app on the BlankApp template is that I hadn't been able to find a way to get Canvas functioning in my previous project based on one of Kenny Kerr's samples.
It sure seems like a lot of delicate surgery just to change the target OS. I'll do it unless it means assembling the project all over again at every retarget!
Thanks, Jeff

Severity
Code
Description
Project
File
Line
Suppression State
Error
MSB3073
The command "mdmerge.exe -v -metadata_dir "C:\Users\jeffevans\source\Practica Musica\packages\Win2D.uwp.1.23.0\build\native....\lib\uap10.0." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.AI.MachineLearning.MachineLearningContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.AI.MachineLearning.Preview.MachineLearningPreviewContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.Calls.Background.CallsBackgroundContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.Calls.CallsPhoneContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.Calls.CallsVoipContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.CommunicationBlocking.CommunicationBlockingContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.SocialInfo.SocialInfoContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.StartupTaskContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.Custom.CustomDeviceContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.DevicesLowLevelContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.Printers.PrintersContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.SmartCards.SmartCardBackgroundTriggerContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.SmartCards.SmartCardEmulatorContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Foundation.FoundationContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Foundation.UniversalApiContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Gaming.XboxLive.StorageApiContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Graphics.Printing3D.Printing3DContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Networking.Connectivity.WwanContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Networking.Sockets.ControlChannelTriggerContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.Maps.GuidanceContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.Maps.LocalSearchContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.Store.StoreContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.TargetedContent.TargetedContentContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.Profile.ProfileHardwareTokenContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.Profile.ProfileSharedModeContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.Profile.SystemManufacturers.SystemManufacturersContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.SystemManagementContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.UI.ViewManagement.ViewManagementViewScalingContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.UI.Xaml.Core.Direct.XamlDirectContract\<IP_ADDRESS>." -o "C:\Users\jeffevans\source\Practica Musica\ARM\Debug\Practica Musica\Merged" -i "C:\Users\jeffevans\source\Practica Musica\ARM\Debug\Practica Musica\Unmerged" -partial -n:1" exited with code 2.
On Oct 28, 2018, at 6:16 PM, Steven White wrote:
Hi, Jeff, the E**** errors (for example, the E0145 that you’re seeing) are coming from the IntelliSense compiler. I’ve seen a lot of cases where those show up in the Error List (in Visual Studio) and they're false positives, so they’re actually not preventing the project/solution from building. For the genuine build errors, together with more information about them, I tend to look just in the Output window (in Visual Studio). Some folks have had success clearing those IntelliSense errors by deleting their *.SDF file. But to really clean a project (which I do after re-targeting), I tend to delete all folders named .vs, release, debug, ARM, x86, x64, Generated Files, and my *.user file.
There’s info here about moving between versions of the SDK that might help: How to retarget your C++/WinRT project to a later version of the Windows SDK
If you can get a minimal repro for the GetFilesAsync issue in a new 17763 project, and/or confirm that the code I pasted above does work (and see how or whether that differs from your usage), then I’d be keen to know more about that.
Regarding the Minimum Version (which actually means min platform version), there’s info about what that means here: Choose which version to use for your app. But, yes, thanks to adaptive coding (checking for the presence of an api contract before calling APIs in it), you can set min version lower than target. Essentially, if writing adaptive code (around APIs only in later versions of Win10) is worth the benefit of supporting earlier versions, then you can do that from a single binary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

Steven, one more bit of information that might help: I see that the first of the (now) just two link errors when retargeting to 17663 is in the file Microsoft.Windows.CppWinR.targets, line 246. There doesn't appear to be any later version of CppWinRT - this is 1.0.181002.2. But aren't you using CppWinrt in your test targeted to 17763? I'm wondering why you wouldn't see that same error at building.
The Platform is x64.
The other is a duplicate type error : a type in Unmerged\XamlMetaDataProvider.winmd already exists in Unmerged\App.winmd. This happens even if I delete the Unmerged folder and let it build again. As these are generated files I'm not sure how one could go about preventing that duplicated type.
Thanks, Jeff
On Oct 28, 2018, at 6:16 PM, Steven White wrote:
Hi, Jeff, the E**** errors (for example, the E0145 that you’re seeing) are coming from the IntelliSense compiler. I’ve seen a lot of cases where those show up in the Error List (in Visual Studio) and they're false positives, so they’re actually not preventing the project/solution from building. For the genuine build errors, together with more information about them, I tend to look just in the Output window (in Visual Studio). Some folks have had success clearing those IntelliSense errors by deleting their *.SDF file. But to really clean a project (which I do after re-targeting), I tend to delete all folders named .vs, release, debug, ARM, x86, x64, Generated Files, and my *.user file.
There’s info here about moving between versions of the SDK that might help: How to retarget your C++/WinRT project to a later version of the Windows SDK
If you can get a minimal repro for the GetFilesAsync issue in a new 17763 project, and/or confirm that the code I pasted above does work (and see how or whether that differs from your usage), then I’d be keen to know more about that.
Regarding the Minimum Version (which actually means min platform version), there’s info about what that means here: Choose which version to use for your app. But, yes, thanks to adaptive coding (checking for the presence of an api contract before calling APIs in it), you can set min version lower than target. Essentially, if writing adaptive code (around APIs only in later versions of Win10) is worth the benefit of supporting earlier versions, then you can do that from a single binary.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

Hi, Jeff, with any project I've created, I've always been able to safely delete the Debug folder. That folder is always created by Visual Studio during build. And it's VS that copies stuff in there (copies stuff out of project folders), hence they're duplicated files, and temporary, and VS can copy them again when you rebuild. If you have NuGet packages, then VS has always been able to acquire those again for me if I've deleted the binaries from temporary folders. Now, I'm caveating this info with my own experience, because it's not inconceivable to me that a project could be set up (incorrectly) to have actual unique source code (or other) files in the Debug folder on disk, and to reference those from the vcxproj file. In that case, of course, deleting Debug would not be safe, but I'd say that a project like that has already taken a wrong turn that needs to be fixed. It's best practice to be sure what and where the single source is for all the files a project depends on (whether that's a source code file, or a binary, or what-not) so that we can be sure that they're checked-in to source control, and so we can be sure that deleting temp files/folders is a non-destructive and safe housekeeping operation. So, in summary, assuming a project is set up appropriately, then deleting any temp folder like the ones I listed will not require any subsequent setup nor redoing anything you've already done config-wise. It should be a case of delete then rebuild.
Yes, my version of the C++/WinRT VSIX (Visual Studio Extension) is 1.0.181002.2, same as yours. That VSIX gives you VS project and item templates and msbuild support (although we recommend that you install the NuGet package for msbuild support, alongside the VSIX).
I just switched my test project from x86 to x64 and I built and I did see the same MSB3073 that you saw. But after persisting, and just rebuilding again, that went away.
It's feeling like the issues you're encountering might be due to moving from a project targeting a Preview version (to one targeting a later version). We do release Preview versions of products in order to give folks a chance to try things out early. And I would expect that you could certainly re-use the actual classes that you wrote with the Preview versions (possibly even entire source code files, but bear in mind What's New with 17763). But it's not necessarily going to be the most economical route to work through the issues that result from re-using and upgrading every artifact that you created with the Preview versions: and in this case I'm thinking specifically of the vcxproj files, and all of the various intermediate, generated, temporary files that are created when building inside VS. In other words, starting with a clean slate with a new project created with released products, and then harvesting source code from your Preview projects, in some cases ends up being the most cost-efficient route; and this might well be one of those cases.
"the whole thing seems unstable" does resonate with me, and whenever I get that distinct feeling, I generally jettison any artifact that might be suffering from bit-rot (or however you want to think of something that's just hopeless out-of-date and/or corrupted with respect to how the equivalent artifact looks when you generate it afresh with the latest bits). Of course, that doesn't include the source code in your classes, which we should understand well enough to bring them up to date. But things happen/change behind the scenes and under the covers with respect to build systems and configuration artifacts (such as vcxproj files and filters files, and such-like) that are sometimes a function of churn during the preview season, and we'd do better not to sink time into diagnosing them but instead get fresh artifacts and bring our code over. I know that even that can be a lot of work, but I've had success copying and pasting chunks of included files between vcxproj files. It's not foolproof, and there are no guarantees, but I have done that successfully in the past. And even as a worst case, we can create a new project and then add files and/or copy-paste file contents (e.g. for files that are already there such as MainPage.Xxx).
I saw the StackOverflow thread. I know this doesn't help your case but just FYI, with the latest public bits, as long as I #include <winrt/Windows.Storage.Search.h>, then I get all the types in Windows::Storage and Windows::Storage::Search. So all of the code below builds and runs as expected (the two GetFilesAsync calls are equivalent).
Windows::Storage::StorageFolder picturesLibrary{ Windows::Storage::KnownFolders::PicturesLibrary() };
auto filesInFolder1{ co_await picturesLibrary.GetFilesAsync() };
auto filesInFolder2{ co_await picturesLibrary.GetFilesAsync(Windows::Storage::Search::CommonFileQuery::DefaultQuery) };

An interesting factoid, though, is that any Windows.A.B.h file itself includes Windows.A.h (so you don't need to). And that's recursive.
~Steve

Thanks for another very helpful answer, Steven. It will take me some time to digest this properly, after which I'll comment if needed.
Jeff
On Oct 29, 2018, at 4:07 PM, Steven White wrote:
Hi, Jeff, with any project I've created, I've always been able to safely delete the Debug folder. That folder is always created by Visual Studio during build. And it's VS that copies stuff in there (copies stuff out of project folders), hence they're duplicated files, and temporary, and VS can copy them again when you rebuild. If you have NuGet packages, then VS has always been able to acquire those again for me if I've deleted the binaries from temporary folders. Now, I'm caveating this info with my own experience, because it's not inconceivable to me that a project could be set up (incorrectly) to have actual unique source code (or other) files in the Debug folder on disk, and to reference those from the vcxproj file. In that case, of course, deleting Debug would not be safe, but I'd say that a project like that has already taken a wrong turn that needs to be fixed. It's best practice to be sure what and where the single source is for all the files a project depends on (whether that's a source code file, or a binary, or what-not) so that we can be sure that they're checked-in to source control, and so we can be sure that deleting temp files/folders is a non-destructive and safe housekeeping operation. So, in summary, assuming a project is set up appropriately, then deleting any temp folder like the ones I listed will not require any subsequent setup nor redoing anything you've already done config-wise. It should be a case of delete then rebuild.
Yes, my version of the C++/WinRT VSIX (Visual Studio Extension) is 1.0.181002.2, same as yours. That VSIX gives you VS project and item templates and msbuild support (although we recommend that you install the NuGet package for msbuild support, alongside the VSIX).
I just switched my test project from x86 to x64 and I built and I did see the same MSB3073 that you saw. But after persisting, and just rebuilding again, that went away.
It's feeling like the issues you're encountering might be due to moving from a project targeting a Preview version (to one targeting a later version). We do release Preview versions of products in order to give folks a chance to try things out early. And I would expect that you could certainly re-use the actual classes that you wrote with the Preview versions (possibly even entire source code files, but bear in mind What's New with 17763). But it's not necessarily going to be the most economical route to work through the issues that result from re-using and upgrading every artifact that you created with the Preview versions: and in this case I'm thinking specifically of the vcxproj files, and all of the various intermediate, generated, temporary files that are created when building inside VS. In other words, starting with a clean slate with a new project created with released products, and then harvesting source code from your Preview projects, in some cases ends up being the most cost-efficient route; and this might well be one of those cases.
"the whole thing seems unstable" does resonate with me, and whenever I get that distinct feeling, I generally jettison any artifact that might be suffering from bit-rot (or however you want to think of something that's just hopeless out-of-date and/or corrupted with respect to how the equivalent artifact looks when you generate it afresh with the latest bits). Of course, that doesn't include the source code in your classes, which we should understand well enough to bring them up to date. But things happen/change behind the scenes and under the covers with respect to build systems and configuration artifacts (such as vcxproj files and filters files, and such-like) that are sometimes a function of churn during the preview season, and we'd do better not to sink time into diagnosing them but instead get fresh artifacts and bring our code over. I know that even that can be a lot of work, but I've had success copying and pasting chunks of included files between vcxproj files. It's not foolproof, and there are no guarantees, but I have done that successfully in the past. And even as a worst case, we can create a new project and then add files and/or copy-paste file contents (e.g. for files that are already there such as MainPage.Xxx).
I saw the StackOverflow thread. I know this doesn't help your case but just FYI, with the latest public bits, as long as I #include <winrt/Windows.Storage.Search.h>, then I get all the types in Windows::Storage and Windows::Storage::Search. So all of the code below builds and runs as expected (the two GetFilesAsync calls are equivalent).
Windows::Storage::StorageFolder picturesLibrary{ Windows::Storage::KnownFolders::PicturesLibrary() };
auto filesInFolder1{ co_await picturesLibrary.GetFilesAsync() };
auto filesInFolder2{ co_await picturesLibrary.GetFilesAsync(Windows::Storage::Search::CommonFileQuery::DefaultQuery) };
An interesting factoid, though, is that any Windows.A.B.h file itself includes Windows.A.h (so you don't need to). And that's recursive.
~Steve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

Steven,
That's very useful  info about what is safe and desirable to delete  - the only one I can't locate is the .user file you mention. Is that somewhere in the project folder?
You mention installing the Nuget package for msbuild support. There are a number of items in the Nuget management window that refer to msbuild - I've now installed msbuild.nuget.pack on the assumption this is correct.
I've deleted both folders named debug, and .vs, ARM, x64, Generated Files. I set the debug target to x64. Checked that Nuget still showed cppwinrt and win2D and msbuild as installed. Then a Clean of the solution and a rebuild. Did this numerous times, re-deleting those folders and files each time before the clean/build, also trying rebuilds without cleans, and clean/rebuilds without deleting, and the results are consistent. There's an MDM2009 error as well as the MSB3073 that you also saw, except that in my sad case neither disappears after persisting.
About the only thing remaining to investigate is that .user file you mention. Maybe taking that out would do something?

Thanks, Jeff

Severity
Code
Description
Project
File
Line
Suppression State
Error
MDM2009
Duplicate type Practica_Musica.XamlMetaDataProvider found processing metadata file C:\Users\jeffevans\source\Practica Musica\x64\Debug\Practica Musica\Unmerged\XamlMetaDataProvider.winmd, type already exists in file C:\Users\jeffevans\source\Practica Musica\x64\Debug\Practica Musica\Unmerged\App.winmd.
Practica Musica
C:\Users\jeffevans\source\Practica Musica\Practica Musica\MDMERGE
1
Error
MSB3073
The command "mdmerge.exe -v -metadata_dir "C:\Users\jeffevans\source\Practica Musica\packages\Win2D.uwp.1.23.0\build\native....\lib\uap10.0." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.AI.MachineLearning.MachineLearningContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.AI.MachineLearning.Preview.MachineLearningPreviewContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.Calls.Background.CallsBackgroundContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.Calls.CallsPhoneContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.Calls.CallsVoipContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.CommunicationBlocking.CommunicationBlockingContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.SocialInfo.SocialInfoContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.ApplicationModel.StartupTaskContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.Custom.CustomDeviceContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.DevicesLowLevelContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.Printers.PrintersContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.SmartCards.SmartCardBackgroundTriggerContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Devices.SmartCards.SmartCardEmulatorContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Foundation.FoundationContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Foundation.UniversalApiContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Gaming.XboxLive.StorageApiContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Graphics.Printing3D.Printing3DContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Networking.Connectivity.WwanContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Networking.Sockets.ControlChannelTriggerContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.Maps.GuidanceContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.Maps.LocalSearchContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.Store.StoreContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.Services.TargetedContent.TargetedContentContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.Profile.ProfileHardwareTokenContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.Profile.ProfileSharedModeContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.Profile.SystemManufacturers.SystemManufacturersContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.System.SystemManagementContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.UI.ViewManagement.ViewManagementViewScalingContract\<IP_ADDRESS>." -metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.17763.0\Windows.UI.Xaml.Core.Direct.XamlDirectContract\<IP_ADDRESS>." -o "C:\Users\jeffevans\source\Practica Musica\x64\Debug\Practica Musica\Merged" -i "C:\Users\jeffevans\source\Practica Musica\x64\Debug\Practica Musica\Unmerged" -partial -n:1" exited with code 2.
Practica Musica
C:\Users\jeffevans\source\Practica Musica\packages\Microsoft.Windows.CppWinRT.1.0.181002.2\build\native\Microsoft.Windows.CppWinRT.targets
246
Practica Musica
C:\Users\jeffevans\source\Practica Musica\packages\Microsoft.Windows.CppWinRT.1.0.181002.2\build\native\Microsoft.Windows.CppWinRT.targets
246

Well, to be honest, the .vcxproj.user file (which, if it exists, will be next to the .vcxproj file) is probably a case of me being obsessively tidy. It just contains user-specific settings for the project AFAIK, so while it's unlikely that deleting it will do any good, I tend to just delete it as a tidying-up ritual. :) My deleting it is quite likely unnecessary, but on the other hand I haven't had it do any harm. If that's the last thing remaining to try, then my expectations would be really, really low that it'll help.
When I mentioned the NuGet package, I hyperlinked the text. If you follow that hyperlink, the name of the NuGet package is given, to avoid ambiguity, but here's an excerpt from the info to be found at that link:
"With version 1.0.181002.2 (or later) of the VSIX installed, creating a new C++/WinRT project automatically installs the Microsoft.Windows.CppWinRT NuGet package for that project. The Microsoft.Windows.CppWinRT NuGet package provides improved C++/WinRT project build support, making your project portable between a development machine and a build agent (on which only the NuGet package, and not the VSIX, is installed).
For an existing project—after you've installed version 1.0.181002.2 (or later) of the VSIX—we recommend that you open the project in Visual Studio, click Project > Manage NuGet Packages... > Browse, type or paste Microsoft.Windows.CppWinRT in the search box, select the item in search results, and then click Install to install the package for that project."
That's the version of the VSIX you have, so the instructions above apply to your case.
Cheers!
~Steve

Good - well, maybe I wasn't clear. The Nuget package manager does show that I have these packages:
Microsoft.Windows.CppWinRT
MsBuild.NuGet.Pack
Win2D.uwp
So all of that appears to be in place.

Maybe I will have to try starting from scratch again, with a new BlankApp template that is already targeted to 17763. Wanted to avoid that because the project is so large.

Thanks, Jeff

On Oct 30, 2018, at 12:39 PM, Steven White wrote:
Well, to be honest, the .vcxproj.user file (which, if it exists, will be next to the .vcxproj file) is probably a case of me being obsessively tidy. It just contains user-specific settings for the project AFAIK, so while it's unlikely that deleting it will do any good, I tend to just delete it as a tidying-up ritual. :) My deleting it is quite likely unnecessary, but on the other hand I haven't had it do any harm. If that's the last thing remaining to try, then my expectations would be really, really low that it'll help.
When I mentioned the NuGet package, I hyperlinked the text. If you follow that hyperlink, the name of the NuGet package is given, to avoid ambiguity, but here's an excerpt from the info to be found at that link:
"With version 1.0.181002.2 (or later) of the VSIX installed, creating a new C++/WinRT project automatically installs the Microsoft.Windows.CppWinRT NuGet package for that project. The Microsoft.Windows.CppWinRT NuGet package provides improved C++/WinRT project build support, making your project portable between a development machine and a build agent (on which only the NuGet package, and not the VSIX, is installed).
For an existing project—after you've installed version 1.0.181002.2 (or later) of the VSIX—we recommend that you open the project in Visual Studio, click Project > Manage NuGet Packages... > Browse, type or paste Microsoft.Windows.CppWinRT in the search box, select the item in search results, and then click Install to install the package for that project."
That's the version of the VSIX you have, so the instructions above apply to your case.
Cheers!
~Steve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

I see: I didn't look closely enough! :) Yes, agreed, that looks good!

Steven,
I've made good progress from your suggestions and have some information that may be useful to you.

I have successfully rebuilt the app on a new template that was targeted to 17763 at creation, and now it is possible to build and run with co_await GetFolderAsync() and co_await GetFilesAsync(). It wasn't possible to just use the Retarget command, but starting over works.
CommonFileQuery is still not recognized, despite
#include "winrt/Windows.Storage.Search.h" and using its fully qualified name as the argument 			/*folder*/.GetFilesAsync(winrt::Windows::Storage::Search::CommonFileQuery::DefaultQuery);
but I can get along fine without it. I may have made some error somewhere. The method that makes the call is in a class that itself is in one of my namespaces; maybe that has something to do with it.

Here's an interesting detail: GetFolderAsync() crashes if the folder does not exist. I had put some of these resource folders into my project assets and marked them in SolutionExplorer to  be included in the project, but they didn't actually get copied into AppX\Assets until I manually placed them there, so the call was bombing. I had been assuming that GetFolderAsync() would return a nullptr if the folder didn't exist, but apparently I was wrong; just have to make sure there is such a folder before asking for it.

IAsyncAction ResourceManager::LoadActivities()
{
auto appFolder = Windows::ApplicationModel::Package::Current().InstalledLocation();
auto activitiesFolder = co_await appFolder.GetFolderAsync(L"\Assets\Activities");	//--->"Activities" must exist in AppX\Assets
}
Anyway, your suggestions have been essential. Great support.

Jeff

On Oct 29, 2018, at 4:07 PM, Steven White wrote:
Hi, Jeff, with any project I've created, I've always been able to safely delete the Debug folder. That folder is always created by Visual Studio during build. And it's VS that copies stuff in there (copies stuff out of project folders), hence they're duplicated files, and temporary, and VS can copy them again when you rebuild. If you have NuGet packages, then VS has always been able to acquire those again for me if I've deleted the binaries from temporary folders. Now, I'm caveating this info with my own experience, because it's not inconceivable to me that a project could be set up (incorrectly) to have actual unique source code (or other) files in the Debug folder on disk, and to reference those from the vcxproj file. In that case, of course, deleting Debug would not be safe, but I'd say that a project like that has already taken a wrong turn that needs to be fixed. It's best practice to be sure what and where the single source is for all the files a project depends on (whether that's a source code file, or a binary, or what-not) so that we can be sure that they're checked-in to source control, and so we can be sure that deleting temp files/folders is a non-destructive and safe housekeeping operation. So, in summary, assuming a project is set up appropriately, then deleting any temp folder like the ones I listed will not require any subsequent setup nor redoing anything you've already done config-wise. It should be a case of delete then rebuild.
Yes, my version of the C++/WinRT VSIX (Visual Studio Extension) is 1.0.181002.2, same as yours. That VSIX gives you VS project and item templates and msbuild support (although we recommend that you install the NuGet package for msbuild support, alongside the VSIX).
I just switched my test project from x86 to x64 and I built and I did see the same MSB3073 that you saw. But after persisting, and just rebuilding again, that went away.
It's feeling like the issues you're encountering might be due to moving from a project targeting a Preview version (to one targeting a later version). We do release Preview versions of products in order to give folks a chance to try things out early. And I would expect that you could certainly re-use the actual classes that you wrote with the Preview versions (possibly even entire source code files, but bear in mind What's New with 17763). But it's not necessarily going to be the most economical route to work through the issues that result from re-using and upgrading every artifact that you created with the Preview versions: and in this case I'm thinking specifically of the vcxproj files, and all of the various intermediate, generated, temporary files that are created when building inside VS. In other words, starting with a clean slate with a new project created with released products, and then harvesting source code from your Preview projects, in some cases ends up being the most cost-efficient route; and this might well be one of those cases.
"the whole thing seems unstable" does resonate with me, and whenever I get that distinct feeling, I generally jettison any artifact that might be suffering from bit-rot (or however you want to think of something that's just hopeless out-of-date and/or corrupted with respect to how the equivalent artifact looks when you generate it afresh with the latest bits). Of course, that doesn't include the source code in your classes, which we should understand well enough to bring them up to date. But things happen/change behind the scenes and under the covers with respect to build systems and configuration artifacts (such as vcxproj files and filters files, and such-like) that are sometimes a function of churn during the preview season, and we'd do better not to sink time into diagnosing them but instead get fresh artifacts and bring our code over. I know that even that can be a lot of work, but I've had success copying and pasting chunks of included files between vcxproj files. It's not foolproof, and there are no guarantees, but I have done that successfully in the past. And even as a worst case, we can create a new project and then add files and/or copy-paste file contents (e.g. for files that are already there such as MainPage.Xxx).
I saw the StackOverflow thread. I know this doesn't help your case but just FYI, with the latest public bits, as long as I #include <winrt/Windows.Storage.Search.h>, then I get all the types in Windows::Storage and Windows::Storage::Search. So all of the code below builds and runs as expected (the two GetFilesAsync calls are equivalent).
Windows::Storage::StorageFolder picturesLibrary{ Windows::Storage::KnownFolders::PicturesLibrary() };
auto filesInFolder1{ co_await picturesLibrary.GetFilesAsync() };
auto filesInFolder2{ co_await picturesLibrary.GetFilesAsync(Windows::Storage::Search::CommonFileQuery::DefaultQuery) };
An interesting factoid, though, is that any Windows.A.B.h file itself includes Windows.A.h (so you don't need to). And that's recursive.
~Steve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

p.s. Would it be safe to remove that MSBuild package? I can no longer view the locals window when debugging (VS quits the debugging session if I choose the locals window), and that package is the main difference between now and the days when I could look at the locals.  When attempting to refresh VS using the VSInstaller I was warned that MSBuild was still running (having quit VS) - could be a clue.
LoadFilesAsynch() is running fine, but now I see it is not actually loading the files, so I need to do some looking.
Jeff
Steven,
I've made good progress from your suggestions and have some information that may be useful to you.

I have successfully rebuilt the app on a new template that was targeted to 17763 at creation, and now it is possible to build and run with co_await GetFolderAsync() and co_await GetFilesAsync(). It wasn't possible to just use the Retarget command, but starting over works.
CommonFileQuery is still not recognized, despite
#include "winrt/Windows.Storage.Search.h" and using its fully qualified name as the argument 			/*folder*/.GetFilesAsync(winrt::Windows::Storage::Search::CommonFileQuery::DefaultQuery);
but I can get along fine without it. I may have made some error somewhere. The method that makes the call is in a class that itself is in one of my namespaces; maybe that has something to do with it.

Here's an interesting detail: GetFolderAsync() crashes if the folder does not exist. I had put some of these resource folders into my project assets and marked them in SolutionExplorer to  be included in the project, but they didn't actually get copied into AppX\Assets until I manually placed them there, so the call was bombing. I had been assuming that GetFolderAsync() would return a nullptr if the folder didn't exist, but apparently I was wrong; just have to make sure there is such a folder before asking for it.

IAsyncAction ResourceManager::LoadActivities()
{
auto appFolder = Windows::ApplicationModel::Package::Current().InstalledLocation();
auto activitiesFolder = co_await appFolder.GetFolderAsync(L"\Assets\Activities");	//--->"Activities" must exist in AppX\Assets
}
Anyway, your suggestions have been essential. Great support.

Jeff

On Oct 29, 2018, at 4:07 PM, Steven White wrote:
Hi, Jeff, with any project I've created, I've always been able to safely delete the Debug folder. That folder is always created by Visual Studio during build. And it's VS that copies stuff in there (copies stuff out of project folders), hence they're duplicated files, and temporary, and VS can copy them again when you rebuild. If you have NuGet packages, then VS has always been able to acquire those again for me if I've deleted the binaries from temporary folders. Now, I'm caveating this info with my own experience, because it's not inconceivable to me that a project could be set up (incorrectly) to have actual unique source code (or other) files in the Debug folder on disk, and to reference those from the vcxproj file. In that case, of course, deleting Debug would not be safe, but I'd say that a project like that has already taken a wrong turn that needs to be fixed. It's best practice to be sure what and where the single source is for all the files a project depends on (whether that's a source code file, or a binary, or what-not) so that we can be sure that they're checked-in to source control, and so we can be sure that deleting temp files/folders is a non-destructive and safe housekeeping operation. So, in summary, assuming a project is set up appropriately, then deleting any temp folder like the ones I listed will not require any subsequent setup nor redoing anything you've already done config-wise. It should be a case of delete then rebuild.
Yes, my version of the C++/WinRT VSIX (Visual Studio Extension) is 1.0.181002.2, same as yours. That VSIX gives you VS project and item templates and msbuild support (although we recommend that you install the NuGet package for msbuild support, alongside the VSIX).
I just switched my test project from x86 to x64 and I built and I did see the same MSB3073 that you saw. But after persisting, and just rebuilding again, that went away.
It's feeling like the issues you're encountering might be due to moving from a project targeting a Preview version (to one targeting a later version). We do release Preview versions of products in order to give folks a chance to try things out early. And I would expect that you could certainly re-use the actual classes that you wrote with the Preview versions (possibly even entire source code files, but bear in mind What's New with 17763). But it's not necessarily going to be the most economical route to work through the issues that result from re-using and upgrading every artifact that you created with the Preview versions: and in this case I'm thinking specifically of the vcxproj files, and all of the various intermediate, generated, temporary files that are created when building inside VS. In other words, starting with a clean slate with a new project created with released products, and then harvesting source code from your Preview projects, in some cases ends up being the most cost-efficient route; and this might well be one of those cases.
"the whole thing seems unstable" does resonate with me, and whenever I get that distinct feeling, I generally jettison any artifact that might be suffering from bit-rot (or however you want to think of something that's just hopeless out-of-date and/or corrupted with respect to how the equivalent artifact looks when you generate it afresh with the latest bits). Of course, that doesn't include the source code in your classes, which we should understand well enough to bring them up to date. But things happen/change behind the scenes and under the covers with respect to build systems and configuration artifacts (such as vcxproj files and filters files, and such-like) that are sometimes a function of churn during the preview season, and we'd do better not to sink time into diagnosing them but instead get fresh artifacts and bring our code over. I know that even that can be a lot of work, but I've had success copying and pasting chunks of included files between vcxproj files. It's not foolproof, and there are no guarantees, but I have done that successfully in the past. And even as a worst case, we can create a new project and then add files and/or copy-paste file contents (e.g. for files that are already there such as MainPage.Xxx).
I saw the StackOverflow thread. I know this doesn't help your case but just FYI, with the latest public bits, as long as I #include <winrt/Windows.Storage.Search.h>, then I get all the types in Windows::Storage and Windows::Storage::Search. So all of the code below builds and runs as expected (the two GetFilesAsync calls are equivalent).
Windows::Storage::StorageFolder picturesLibrary{ Windows::Storage::KnownFolders::PicturesLibrary() };
auto filesInFolder1{ co_await picturesLibrary.GetFilesAsync() };
auto filesInFolder2{ co_await picturesLibrary.GetFilesAsync(Windows::Storage::Search::CommonFileQuery::DefaultQuery) };
An interesting factoid, though, is that any Windows.A.B.h file itself includes Windows.A.h (so you don't need to). And that's recursive.
~Steve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
If this email is spam, report it to www.OnlyMyEmail.com

Yes, it's my understanding that it's ok to uninstall https://www.nuget.org/packages/Microsoft.Windows.CppWinRT/, since those facilities are still in the VSIX also. I'll pass along your experiences to the folks that develop that package.
Thanks!
Steve

I can confirm that removing the MSBuild pack fixed the debugger - I can now use the local variables window again.
Thanks, Jeff
I meant MSBuild.NuGet.Pack - I'd not dare to remove the CppWinRT !
Jeff
On Nov 1, 2018, at 2:51 PM, Steven White wrote:
Yes, it's my understanding that it's ok to uninstall https://www.nuget.org/packages/Microsoft.Windows.CppWinRT/, since those facilities are still in the VSIX also. I'll pass along your experiences to the folks that develop that package.
Thanks!
Steve
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Nice! :)

But - it was a false hope. Did work great on the first breakpoint! I could see that my calls to GetFilesAsync, etc. had not produced any data, so next up was to find out why. But now VS quits whenever it hits a breakpoint anywhere in the code, and I've made no changes. The whole system just seems unusable, and that is a problem because the project is educational software with a good-sized installed base that is half Mac and half Windows. The Mac version of the new edition is pretty much done and this one is holding things up. CppWinrt seems like a great system and I have many months invested in it now, and a nice-looking animated interface. At the moment it doesn't look possible to do any more work on this unless some updates are coming up in the pipeline (?)
Jeff
On Nov 1, 2018, at 3:39 PM, Steven White wrote:
Nice! :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi, Jeff, for Visual Studio issues, do you know about the Visual Studio User Voice feedback website, or the Developer Community? Those might be able to help.
For issues, or suspected product bugs, there's Microsoft Support; a support engineer will look at the repro and see whether the issue is a product bug or something else.
If the issue turns out to be something that I can address in the docs then I'll do that.
~Steve


Feature request: compress body

Hello,
Elasticsearch allows the request body to be compressed to save bandwidth at the cost of CPU time on the client.
Could we get an option for bulk indexers (and normal clients) to compress the body ?
Thanks!

I wanted this feature, so I implemented it in PR https://github.com/elastic/go-elasticsearch/pull/288.
I'm using this now by adding this line to my go.mod:
replace github.com/elastic/go-elasticsearch/v7 v7.13.1 => github.com/bschofield/go-elasticsearch/v7 v7.13.2-0.20210628141847-eccb27ca97ab

Should be closed by https://github.com/elastic/go-elasticsearch/pull/302, thanks @Anaethelion!


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.4.169",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a5c6a13e9056d87805ba3042c208fbd4164ad22b"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "a5c6a13e9056d87805ba3042c208fbd4164ad22b",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "hamradio: improve the incomplete fix to avoid NPD\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.4.169 by commit a5c6a13e9056d87805ba3042c208fbd4164ad22b. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2021-1002801


Release <IP_ADDRESS> throws IO Exception and app cannot be launched

To reproduce, just install and the run the app.
The app does not start, but when inspecting the Event Viewer, we get the following logs:
Nome da aplicação com falha: GCBM.exe, versão: <IP_ADDRESS>, carimbo de data/hora: 0xfee1cfe3
Nome do módulo com falha: KERNELBASE.dll, versão: 10.0.22000.832, carimbo de data/hora: 0x7efab3dc
Código de exceção: 0xe0434352
Desvio de falha: 0x000000000004474c
ID do processo com falha: 0x5418
Hora de início da aplicação com falha: 0x01d8ba41c81c5a09
Caminho da aplicação com falha: C:\Program Files\gcbm\GCBM.exe
Caminho do módulo com falha: C:\WINDOWS\System32\KERNELBASE.dll
ID do Relatório: 1e97588a-7ae7-499a-83c1-925b39925189
Nome completo do pacote com falha:
ID da aplicação relativa ao pacote com falha:

Application: GCBM.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
at GCBM.frmMain.UpdateProgram()
at GCBM.frmMain..ctor()
at GCBM.Program.Main()
I was able to use the app by installing the app from the prior release (<IP_ADDRESS>)

Had some data loss, and apparently Git changes didn't get pushed with the last update, so, reverted and did some re-writing. Have you installed the latest .NET framework, We did just include .NET 4.8, still working out on how to upgrade the C# language level from.. 7.3 ugh to something more modern. I think it's the auto updater that is maybe causing issues? or it might be something deeper in the core components that relies on old code.
Any way, new build being pushed shortly. Please let me know if this fixes your issue. Also do try installing .NET 4.8

Oh .. duh. Auto Updater.NET DLL didn't get included in the installer bundle. Will fix..


Fix outdated option name in docs

Fixes https://github.com/Gibbu/svooltip/issues/7

Ah yeah, totally forgot about that.
LGTM


Added OpenSSL based callback.

callback to allow additional OpenSSL/boringssl APIs to be called on connection setup.

Hello @medinandres : is this still something that you would like to have merged?

Closing based on feedback from @jiangtaoli2016 and @yihuazhang


Update Approval

Closing this PR as it goes against the flow of the tutorial. Each branch represents a different stage in the tutorial. 4.core is not supposed to have the approvals code yet.


Remove/lmod dependency

This is a first shot at removing the lmod dependency so that I'm able to better develop and test locally for the next round of changes (supporting different recipe types). Note that I added a parameter to the system to be able to capture if lmod is installed, which can be referenced later. For some future update I'd like to better organize modules to be a subtype of environment (or we can call it something else) but this should work for now. I also:

add a run_tests.sh bash script to replace the buildtest_regtests.py file. The reason is because pytest is most understood to be run from the command line, and the user should be able to inspect the file and choose some subset of commands. If you look in the file, we skip over the module tests if lmod isn't installed (and can do this for other future environments). The testing in .travis.ci, since we assume lmod is installed, will of course run all of them. We might want to add a test case here to support trying the same without having lmod, if you think that's necessary.
remove module commands from client: as they are redundant. Buildtest is not a wrapper for the module command, this doesn't make sense.
update test_config_files so tests for modules are in the test_modules function.

@shahzebsiddiqui I don't think that the module configs should exist by default - nor should a collection config (writing an empty file doesn't make a lot of sense). I think we should remove those checks for now, and when a full test is added that reads in a recipe file with a module, this is when we would need to load the Module class and ensure that the file is added, etc.

https://github.com/z4r/python-coveralls/issues/73

hah! So codecov is failing, but travis is at least passing. If codecov is just for test coverage, we will definitely be working on that, albeit likely not in this exact PR.


Pull to refresh

Pull to refresh is never updates or refresh content 1.7 , 1.6 and 2
what the problem ?

Yeah you are right, the PTR gets the first page from the cache if exist.
the PTR will work if you set a low cache time in the config.json file: posts.cache.maxAge
I am planning to fix that in 1.7.1, stay tuned.

thank you,  can you give me exactly which line i can find this?

In you config.json file: https://github.com/shprink/wordpress-hybrid-client/blob/develop/config.json.dist#L155
It is currently set to 1 day (86400000 ms). If you set that to 0 the PTR will get fresh data everytime. If you set to 2 mins then every 2min the PTR will pull new data.

i already set them to
"capacity": 0,
"maxAge": 0
without any new
i also removed :
"orderby": "date",
"orderby": "desc",
to bring last posts when intializing the app before i delete this values was brings very old posts  and ignores any new posts

Actually i have just tested it is working as expected even with the cache set to one day.
You can check the code here https://github.com/shprink/wordpress-hybrid-client/blob/develop/lib/posts/posts.controller.coffee#L34-L40
What it does is to remove the cache, then remove posts and ask for the first page once again. I have tested locally with a new post and it is correctly displayed after PTR.

yes sorry i doubled checked with new posts and the category pages was updating now
but the home or recent posts is not updating does its only refresh on app loading.

There is no PTR on category and tag list because the list is unlikely to be changed often. The cache is set to 2 days: https://github.com/shprink/wordpress-hybrid-client/blob/develop/config.json.dist#L145
The PTR is only on the home page and search page (until 1.7.0) and work as expected. Have not tested on 2.0 yet, this branch is not stable so please do not use it in production.


docs: setup glossary

This bounty is for both setting up the glossary infrastructure and populating it with most openpilot terms.
Requirements:

a master definition file
"glossary page" under the concepts section
nice to have: click or hover on words defined in the glossary to get the definition on any docs.comma.ai page. bounty value doubles if this is done

wiki has a good starting point on definitions: https://github.com/commaai/openpilot/wiki/General-Terms

hi @adeebshihadeh want to take this up. please can you provide more details?

Hey @adeebshihadeh,
I'd like to work on this issue. Could you please assign this issue to me?

@devSuryansh you're free to work on it.

hey, is the bounty for this still open?

hey can i work on this issue?

@adeebshihadeh ?

@adeebshihadeh whenever you have a chance please let me know if this meets your requirements #34155


Print the Fibonacci series for n=20 #45

issues try to rename your file

Hi @akshitagupta15june !
I noticed something:

26 days ago you assigned it to me: https://github.com/akshitagit/JavaScript/issues/45#issuecomment-699489711
I made the PR 18 days ago
You just accepted another PR submitted 2 days after mine: https://github.com/akshitagit/JavaScript/pull/92

And now you close mine because it has the same filename 😅
Anyway thank you for your time on this repo, I hope my comment can help :)

i am very sorry @bidetaggle i am merging your pr too

I have resolved the conflicts

All good mate :)


Can't install on Manjaro/Arch: ERROR: No matching distribution found for miniupnpc==2.1

$ sh install.sh
install.sh: line 7: type: apt-get: not found
pacman is /usr/bin/pacman
Installing on Arch Linux.
warning: python-3.9.5-3 is up to date -- skipping
warning: git-2.32.0-1 is up to date -- skipping
 there is nothing to do
which: no python37 in (/home/user/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin)
which: no python3.7 in (/home/user/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin)
which: no python38 in (/home/user/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin)
which: no python3.8 in (/home/user/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin)
which: no python39 in (/home/user/bin:/home/user/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin)
Python version is 3.9
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: pip in /home/user/.local/lib/python3.9/site-packages (21.1.2)
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: wheel in /home/user/.local/lib/python3.9/site-packages (0.36.2)
Defaulting to user installation because normal site-packages is not writeable
Looking in indexes: https://pypi.org/simple, https://pypi.spare.net/simple/
ERROR: Could not find a version that satisfies the requirement miniupnpc==2.1 (from versions: 1.9, 2.0.1, 2.0.2)
ERROR: No matching distribution found for miniupnpc==2.1

Same on Fedora 34

After maually removing the ==2.1 requirement, this is what I get:
.
.
.
Collecting pycryptodome
  Using cached pycryptodome-3.10.1-cp35-abi3-manylinux2010_x86_64.whl (1.9 MB)
Collecting argon2-cffi
  Using cached argon2_cffi-20.1.0-cp35-abi3-manylinux1_x86_64.whl (97 kB)
Collecting zipp>=0.5
  Using cached zipp-3.4.1-py3-none-any.whl (5.2 kB)
Requirement already satisfied: idna>=2.0 in /usr/lib/python3.9/site-packages (from yarl<2.0,>=1.0->aiohttp==3.7.4->spare-blockchain==0.1.dev1) (3.2)
Requirement already satisfied: cffi>=1.0.0 in /usr/lib/python3.9/site-packages (from argon2-cffi->keyrings.cryptfile==1.3.4->spare-blockchain==0.1.dev1) (1.14.5)
Requirement already satisfied: six in /usr/lib/python3.9/site-packages (from argon2-cffi->keyrings.cryptfile==1.3.4->spare-blockchain==0.1.dev1) (1.16.0)
Requirement already satisfied: pycparser in /usr/lib/python3.9/site-packages (from cffi>=1.0.0->argon2-cffi->keyrings.cryptfile==1.3.4->spare-blockchain==0.1.dev1) (2.20)
Installing collected packages: zipp, jeepney, SecretStorage, multidict, importlib-metadata, blspy, yarl, typing-extensions, pycryptodome, portalocker, keyring, clvm, chardet, async-timeout, argon2-cffi, websockets, sortedcontainers, keyrings.cryptfile, dnspython, concurrent-log-handler, colorlog, clvm-tools, clvm-rs, click, chiavdf, chiapos, chiabip158, bitstring, aiosqlite, aiohttp, spare-blockchain
  Running setup.py develop for spare-blockchain
    ERROR: Command errored out with exit status 1:
     command: /usr/bin/python -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/user/spare-blockchain/setup.py'"'"'; __file__='"'"'/home/user/spare-blockchain/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix=
         cwd: /home/user/spare-blockchain/
    Complete output (28 lines):
    running develop
    WARNING: The user site-packages directory is disabled.
    error: can't create or remove files in install directory

    The following error occurred while trying to add or remove files in the
    installation directory:

        [Errno 13] Permission denied: '/usr/lib/python3.9/site-packages/test-easy-install-218549.write-test'

    The installation directory you specified (via --install-dir, --prefix, or
    the distutils default setting) was:

        /usr/lib/python3.9/site-packages/

    Perhaps your account does not have write access to this directory?  If the
    installation directory is a system-owned directory, you may need to sign in
    as the administrator or "root" account.  If you do not have administrative
    access to this machine, you may wish to choose a different installation
    directory, preferably one that is listed in your PYTHONPATH environment
    variable.

    For information on other options, you may wish to consult the
    documentation at:

      https://setuptools.readthedocs.io/en/latest/easy_install.html

    Please make the appropriate changes for your system and try again.

    ----------------------------------------
ERROR: Command errored out with exit status 1: /usr/bin/python -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/user/spare-blockchain/setup.py'"'"'; __file__='"'"'/home/user/spare-blockchain/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix= Check the logs for full command output.

It seems like it has never been built/tested before releasing. Like, not even once.

Thats the actual code in the install script who would install that ominous thing.
python -m pip install --extra-index-url https://pypi.spare.net/simple/ miniupnpc==2.1

The issue is he did a find replace. Chia to spare. Look at the url in the command. It should be chia.net. Not spare.net.


unable to compile git since commit d76e6780

Describe the bug
I'm unable to compile fancon since git commit d76e6780 (I used cmake … -DNVIDIA_SUPPORT=OFF ..).
commit d76e6780ff87fdb4a76e65934b0592d6b338ef6d
Author: Hayden Briese<EMAIL_ADDRESS>Date:   Thu May 7 02:02:38 2020 +1000

    - Fixed bug where configured NVIDIA devices may be run without NVIDIA control

    Signed-off-by: Hayden Briese<EMAIL_ADDRESS>
Steps to Reproduce
$ make
Scanning dependencies of target fancon
[  5%] Building CXX object CMakeFiles/fancon.dir/src/main.cpp.o
[ 11%] Building CXX object CMakeFiles/fancon.dir/src/Controller.cpp.o
…/upstream.git/src/Controller.cpp:12:3: error: use of undeclared identifier 'NV'
  NV::init();
  ^
1 error generated.
make[2]: *** [CMakeFiles/fancon.dir/build.make:148: CMakeFiles/fancon.dir/src/Controller.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:96: CMakeFiles/fancon.dir/all] Fehler 2
make: *** [Makefile:150: all] Fehler 2

Expected behavior
compilation works
Environment

Version: fancon git (commit d76e6780)
OS: Fedora 31
Kernel: 5.7.7
clang: 9.0.1
g++: 9.3.1

Additional context

Please pull the latest commit (563c9db9a4ac7c97a63203b2927cb3149b8632fc) and try again

works for me now (I assume it was fixed in e0e6994e2b105f3fb617a192f4a6b8ddd3d1604a)


feat: return entities from procedures

some procedures now return entities. For example, creating a security token will return the
corresponding Security Token Entity
BREAKING CHANGE: too many to list

:tada: This PR is included in version 2.0.1-beta.20 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Initial Commit

This pr adds two endpoints: /themelist and /themedetails/:id
/themelist returns only the name, id, description, primary_color, secondary_color, tertiary_color thats been pulled from /data/themes.json
/themedetails/:id checks the id from /data/themes.json and returns the complete data if matched
The themes.json is not usable for now and it needs to be completed from themes

LGTM


For reference how is const howLongTillLunch = require('..') working?

I am assuming
const howLongTillLunch = require('..');
reads package.json
and pulls
dist/how-long-till-lunch.umd.js from browser
Can someone confirm?

from my understanding no. Require should load the cjs version and not the umd one. From what i understand umd is supposed to be served to unpkg or another cdn. And its intended to be used with a

For nodejs require('..') will read package.json and read the file specified by main.


Review: Landing Page

Please review the landing page, linked here
Use these guidelines:

Architecture
Design
JS
React

Nothing is wrong with the code, but should probably stay consistent on with JS framework to use. Currently were using bootstrap for this and semantics ui for the balance sheet page.

L06: Could change to multiple lines for readability

Everything else looks fine and seems to pass the checklists

Landing.jsx
Line 3: Change the default comment from the template.
Line 7: Delete extra space in container className
Lines 15-16: Ending space needed at the end of /a
 About us
Put the href after className so that it's easier to cross reference where it goes.
<a className="btn btn-light ms-3" href="/about"> About us </a>

Nothing is wrong with the code, but should probably stay consistent with the JS framework to use. Currently we are using bootstrap for this and semantics ui for the balance sheet page.

Landing.jsx
Architecture OK
Design OK
JS and ESlint OK
React OK

Cannot find issues with this file.

I feel everything in the code is simple and easy to read

Outcome of the review meeting

Outcome of the review meeting
New Issues
None
Checklists
None
The code is simple enough and not showing any errors

No issues found


Struggling to get basic implementation working...

This package looks like a god-send... but I'm a bit confused as to what I'm doing wrong. Hoping you might be able to point me in the right direction and clarify a couple of issues.
So, the end goal is to get tabular search working across multiple collections. We have a Responses collection, referencing both a contact and survey collection.
At the moment, my view looks like this...
 DenormalizedViews.addView({
        identifier: ident,
        sourceCollection: Responses,
        viewCollection: ResponsesView,
        pick: ['created', 'comment', 'score', 'contact', 'survey'],
        sync: {
            contactCache: (response) => {
                return Contacts.findOne({_id: response.contact});
            },
            surveyCache: (response) => {
                return Surveys.findOne({_id: response.survey});
            }
        },
        postSync: {
            responseContact: (response) => {
                const contact = response.contactCache.email;
                return contact;
            },
            responseSurvey: (response) => {
                const survey = response.surveyCache.name;
                return survey;
            }
        }
    });

I've also set up two refreshByCollections. Think I'm missing something, but just can't get anything beyond an empty cursor. To be frank, I haven't dug around too much in the code, so I'm probably just missing something really basic and hoping for a magic bullet. Two things I wasn't exactly sure about were the role of the identifier and the params on refreshByCollection, for example (doc, docPrevious, userId). Any pointers would be greatly appreciated! Thanks.

Same here, this has lots of potential @thebarty but couldn't get anything in the response. Any pointers please?

Hi guys, I am really busy at the moment. Please have a look at the tests included to see how to get it working. This package has a huge set of tests and you should be able to figure it out by looking at them. 👍

@jonnyjg: just having a really quick view at your code - check that you have created a mongo-collection for this.


'Send as' option

Is your feature request related to a problem? Please describe.
Some lectures do not want to send emails from their address. Creating a generic account is a workaround however can be problematic and confusing. We have encountered this on larger courses that have multiple instructors.
A 'send as' option would be useful to allow lectures to use a generic account. This could be visible in the 'Send email action' screen but would only be visible if a user has the correct permissions.

Hi @mylesblane, this was something discussed in issue #57 (closed) and was not something that Abelardo was keen to include in the core code (due to the obvious risks). We do provide this capability for just 2 very large courses at Auckland. In our local server, the code we wrote allows anyone assigned "staff status" in the DB Admin console --> users page to view an additional "From" email field along with Subject, cc:, & Bcc: fields. In our case, the course administrator can act as the proxy for each member of a large teaching team although the teachers still write all the emails (in advance of the comms date) and the reply address is still their university email. In this specific scenario, the individual instructors don't interact with the OnTask tool but leave that job to the course coordinator/admin. Hopefully, someone in your institution might be able to code this function and re-install it with each OnTask version upgrade. Let me know if you would like a copy of our code as an example and I will send or share that directly to you.

Hi @leichtweis thanks for replying. Could we get a copy of the code?


Update and rename message/index.js to mensaje/index.js

hello I want to collaborate with BocchiBot

sorry, but your changes haven't a positive impact for the repository


FW-2243

Topics Widget

Adds Topics Widget w/Jest tests

Also:

Displays debug message in V2 if url doesn't have a language
Adds debug text to home page when it encounters an unknown widget

Definition of Done

[ ] Reviewer can follow the flow of the code
[ ] Variables, methods are named properly and clearly
[ ] Methods are documented using comments (where not self-explanatory)
[ ] Any suggestions for refactoring have been implemented
[ ] Tests are created and cover at least 85% of the functionality
[ ] Code is unlikely to introduce new regressions
[ ] Acceptance criteria has been met

Thanks for the review @gmcauliffe


Version 5.4.16 don't support nette/*^3.0

Wondering if you could help you making those packages support nette/*^3.0:
        "symplify/coding-standard",
        "symplify/easy-coding-standard",
        "symplify/package-builder",

Reason: When developers have in their composer.lock an installed version of nette/*^3.0, composer will show the following error when installing one of symplify packages as composer don't downgrade packages.
Installation request for nette/utils (locked at v3.0.1).

It seems like those packages already support nette v3, but there was no release since then.
@TomasVotruba any release planned soon? Newest phpstan (0.11.7) requires nette v3.

@nunomaduro Feel free to PR :+1:
@marmichalski Yes, I'm waiting for Symfony 4.3, so we're in sync

Thanks for the info @TomasVotruba, just curious: Why are you waiting for the Symfony 4.3 release?

@marmichalski Yes, I'm waiting for Symfony 4.3 release, so we're in sync.
Is this already in master then? Should be closed if so

@TomasVotruba 5.4.16 was released on March 6th while the "fixes" were introduced on March 10th.
https://github.com/Symplify/PackageBuilder/commit/92b75d5eb8f1d670fcf07ba452b25b767b650e39
https://github.com/Symplify/EasyCodingStandard/commit/c614d34763717a04255b665ddf0a212769b85a28
https://github.com/Symplify/CodingStandard/commit/4cae95cb778370b2bb98db79a9fe56e1e851cdfd
Unless there is something more to be bumped.

@nunomaduro Basically to bump deps and have code tested and synchronized.
More here: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.tomasvotruba.cz/blog/2017/10/30/what-can-you-learn-from-menstruation-and-symfony-releases/&ved=2ahUKEwjY_ZmenqriAhXCepoKHcssC_8QFjAAegQIBhAC&usg=AOvVaw2tTEYunsA4scDRy-RuSFRU

@marmichalski Thanks for confirmation! Closing then

Symplify 6 is out! :tada:
https://github.com/Symplify/Symplify/blob/master/CHANGELOG.md#v600---2019-05-28

Thanks! Hugeeee!


Help: How to get Pivot V2 sort by dimension?

A clear and concise description of what the bug is.
How to reproduce the bug

Go to '...' Create Chart, Pivot V2
Click on '....' Select a date field into Rows. Select a metric. Try to add sort by the same date field descending.
Scroll down to '....'
See error

Expected results
The last date I have with data is 03 Apr. I would expect to see the counts by descending TranDate.
Actual results
The sort by field expects a metric with aggregation function. If I use custom to specify only "TranDate", I get an error on duplicate field names. I changed to "DATE(TranDate)" but output is still not sorted. The SQL generated also looks incorrect with "ORDER BY DATE(TranDate)"
Screenshots

Environment
(please complete the following information):

browser type and version: Chrome 99
superset version: superset version 1.4.2
python version: python --version 3.8.10
node.js version: node -v 12.14.1
any feature flags active: None

Checklist
Make sure to follow these steps before submitting your issue - thank you!

[X] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[X] I have reproduced the issue with at least the latest released version of superset.
[X] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

Closing this as stale since it's been silent for so long, and we're trying to steer toward a more actionable Issues backlog. If people are still encountering this in current versions (currently 3.x) please re-open this issue, open a new Issue with updated context, or raise a PR to address the problem. Thanks!


Blog collections and example - with category

When using the example for Blog collections on this page
https://middlemanapp.com/basics/blogging/
I get the following raised in console and fails on build - is there something in the frontMatter that does not allow the key category: now?
Error produced
Template local `category` tried to overwrite an existing context value. Please rename the key when passing to `locals`

We are trying to avoid collisions between locals passed into proxies and methods that are built-in helpers. This looks like a bug in blog with that new constraint

how to fix this?

@brodock
I have updated to all the latest and it seems to work - make sure category is in each blog file.
# Custom collections
blog.custom_collections = {

    # Category
    category: {
        link:     '/{category}.html',
        template: 'template/category.html'
    }

}

@brodock
I have updated to all the latest and it seems to work - make sure category is in each blog file.
# Custom collections
blog.custom_collections = {

    # Category
    category: {
        link:     '/{category}.html',
        template: 'template/category.html'
    }

}


Updates to LIVD Mapper with 'Visual Read' or 'Instrumented' Results in OBX-16

On 4/6/2022, O&O learned there is an enhancement being planned to the LIVD Mapper (through APHL, NIH and LIVD consortium).
What:
Tests like Binax NOW are designed to be interpreted by a human; hence, they are classified as 'Visual Read'. Tests like BD Veritor require an app to interpret the results - 'Instrumented'.
How:
The proposal is start including a field (column) in the LIVD mapper that allows user to distinguish between "Visually Read" and "Instrumented" devices per LOINC.
Why:
Arguably, the data quality/accuracy of 'Intrumented' tests is higher than tests that are 'Visually Read'. STLTs have continued to request additional identifiers to let them get informed on data quality. While this field might continue to remain optional in reporting standards, the STLTs may appreciate added visibility into test types. (https://hl7-definition.caristix.com/v2/HL7v2.5.1/Fields/OBX.16)
Next Steps:

Check in with LIVD team to understand scope, timeline and impact of change
Next steps will be informed based on above findings, including STLT comms

cc @MauriceReeves-usds @RickHawesUSDS @brick-green-agile6

4/6: Meeting scheduled with LIVD team on 4/6 - will bring this topic as well.

4/8: Per Riki:
"Thanks for the heads up, but I think we already have that in the spreadsheet, as those are already FDA attributes.
In fact we include that in our guidance for OTC reporting – see the updated document here: https://confluence.hl7.org/pages/viewpage.action?pageId=86967947#ProposedHHSELRSubmissionGuidanceusingHL7v2Messages-ReportingatHomeTests"

These attributes have been added to the new version intended for PRIME. See attached as an example.
https://app.zenhub.com/files/304423150/5b49576f-01cd-49bd-901a-3cbcfc8f8c6b/download


Update routes.js

Created session variables to store task list status values

Cancelling, as hadn't pulled all the changes from master, so will raise another PR in a bit


Patient name and ID not displayed when V3 launched with JSON data

When launching the viewer (V3) with a JSON data source which includes 'PatientID' and 'PatientName', these are not displayed anywhere in the viewer, and neither other demographic patient data such as age, gender.

every instance must add patientid,patientname,patientname

@kongzhonglei Thanks for the suggestion, I added the  PatientName and PatientID keys to each instance's metadata but still the patient details are not displayed.
Here is the metadata json for a single CT slice:
{
    "studies": [
        {
            "StudyInstanceUID": "1.2.8<IP_ADDRESS>80043.9.7521.0.20230107141234896752.42566",
            "StudyDescription": "CT-ABDOMEN",
            "StudyDate": "20230107",
            "StudyTime": "151053",
            "PatientName": "Some^Test",
            "PatientId": "999018815",
            "AccessionNumber": "sb23010714123489",
            "PatientAge": "063Y",
            "PatientSex": "F",
            "series": [
                {
                    "SeriesDescription": "Spiral 2.5mm",
                    "SeriesInstanceUID": "1.2.8<IP_ADDRESS>80043.9.7521.0.20230107141234896752.425<IP_ADDRESS>.25.20941011514157924231591510140751329714912<IP_ADDRESS>0.1136<IP_ADDRESS>.346831625.507.1209877797.132",
                    "SeriesNumber": 2,
                    "SeriesDate": "20230107",
                    "SeriesTime": "151053",
                    "Modality": "CT",
                    "SliceThickness": 2.5,
                    "instances": [
                        {
                            "metadata": {
                                "PatientName": "Some^Test",
                                "PatientId": "999018815",
                                "Columns": 512,
                                "Rows": 512,
                                "InstanceNumber": 1,
                                "SOPClassUID": "1.2.840.10<IP_ADDRESS>.1.1.2",
                                "AcquisitionNumber": 1,
                                "PhotometricInterpretation": "MONOCHROME2",
                                "BitsAllocated": 16,
                                "BitsStored": 16,
                                "PixelRepresentation": 1,
                                "SamplesPerPixel": 1,
                                "PixelSpacing": [
                                    0.976562,
                                    0.976562
                                ],
                                "HighBit": 15,
                                "ImageOrientationPatient": [
                                    1.0,
                                    0.0,
                                    0.0,
                                    0.0,
                                    1.0,
                                    0.0
                                ],
                                "ImagePositionPatient": [
                                    -250.0,
                                    -250.0,
                                    -0.5
                                ],
                                "FrameOfReferenceUID": "1.2.840.1136<IP_ADDRESS>.346831625.507.1209877797.129.19530.5",
                                "ImageType": [
                                    "ORIGINAL",
                                    "PRIMARY",
                                    "AXIAL"
                                ],
                                "Modality": "CT",
                                "SOPInstanceUID": "1.2.840.1136<IP_ADDRESS>.346831625.507.12098777<IP_ADDRESS>4769166391.1673106895909",
                                "SeriesInstanceUID": "1.2.8<IP_ADDRESS>80043.9.7521.0.20230107141234896752.425<IP_ADDRESS>.25.20941011514157924231591510140751329714912<IP_ADDRESS>0.1136<IP_ADDRESS>.346831625.507.1209877797.132",
                                "WindowCenter": 40,
                                "WindowWidth": 400,
                                "StudyInstanceUID": "1.2.8<IP_ADDRESS>80043.9.7521.0.20230107141234896752.42566"
                            },
                            "url": "dicomweb:https://localhost:3000/pacs/images/?i=1.2.8<IP_ADDRESS>80043.9.7521.0.20230107141234896752.42566~1.2.840.1136<IP_ADDRESS>.346831625.507.12098777<IP_ADDRESS>4769166391.1673106895909"
                        }
                    ]
                }
            ],
            "NumInstances": 1,
            "Modalities": "CT"
        }
    ]
}

Isn't it more simple and logical to have the viewer get all the required metadata directly from the dicom instance headers ? All we actually need to provide is the URL for the dicom instance, all metadata is contained in the DICOM headers anyway whether we provide it or not. It's not clear to me why all these metadata fields (which repeat thousands of times in case of a large study) have to be computed in advance.

Hello, I am having the same issue. Anyone has the answer?

Can you still see this issue in the latest master?

@jbocce ditto

Both the patient name and MRN are now displayed.

@jbocce
This is still not completely solved:

The MRN field doesn't display the PatientID tag value (see attached image).
As a matter of patient safety the patient name and ID must be clrearly displayed in the overlay of each image. It shouldn't be hidden behind the i icon which requires another click to display.

@shlomgad , the latest dev version does NOT display the problem. You can try it here. Which version are you experiencing the problem with?
With regards to not requiring a click to display the patient name and MRN, that is something we are considering changing.
FYI @sedghi, @dan-rukas and @james-hanks

@shlomgad – I just added a note to a similar issue about displaying patient information at all times.  I'm currently looking at a few design options to show patient information at all times. I'll add a new comment to this post when we share on this soon.

This still doesn't seem to work.
Also the .scripts/convertDicomToJson -> generates the patient's name as an array
   "StudyTime": "165246.000",
            "PatientName": [
                {
                    "Alphabetic": "Jane Doe"
                }
            ],
            "PatientID": "0060",
            "AccessionNumber": "",
            "PatientSex": "F",

if I keep the PatientName as a string, then it shows up in the Dicom Tag browser , but is still not visible in the top right. v3.8
View in OHIF 3.8

Patient name is visible in v3.7

So,

Does the dicomToJson generator needs to revised ?
Should I stick to 3.7, until an update comes that resolves this issue ?


Make saga error handling more robust

If any saga fails for whatever reason (including an exception), the application must stay in working state.
To verify, e.g. within a saga, use code like
   const dummy = undefined
   dummy.failHere()

Such a flow must be properly logged but the rootSaga must continue to live and process next actions.

@sjd78 is this still an issue?

@gregsheremeta GlobalErrorBoundary already implemented, can we close this issue?

@bond95, @gregsheremeta - The error boundary is a good kernel panic trap, and it prevents the app to run with inconsistent state and prevent the app from being unloaded.  However, it isn't quite what the issue here is asking for.  I'm ok with closing this issue with the caveat that the App just fails to an error state, and I'm ok with leaving it open so we can circle back to provide a more self-healing approach.

closing this issue with the caveat that the App just fails to an error state

Indeed.


I wish /docs/user-guide/services/ NodePort was documented more clearly

I wish /docs/user-guide/services/ NodePort was documented more clearly.
( Ok, I had no idea this was going to push me into an issue... I'm not prepared for that. )
I wasn't able to figure out how to set up a NodePort in this documentation. I happened to figure it out from this line:

The service.spec.publicIPs property is deprecated and now called service.spec.deprecatedPublicIPs. This property will be removed entirely when v1beta3 is removed. The vast majority of users of this field were using it to expose services on ports on the node. Those users should specify service.spec.type: "NodePort" instead. Read External Services for more info. ...

on this page: https://github.com/kubernetes/kubernetes/blob/master/docs/api.md
( Note how that page references the path explicitly.  Also, there is no example under the section 'NodePort', and the example that follows has an element 'nodePort' ... very confusing ... )

It's more explicitly on the services pages. http://kubernetes.io/docs/user-guide/services/