Whenever a UWP app contains managed code we need to be sure to inject the .NET Core Framework assemblies. This is obviously the case when the app itself is written in C# or VB. However, we also need to handle the case where the app is written in JavaScript but references a WinRT component written in managed code.
Previously, this check was updated (for C++ apps) to look for the full location of the Windows.winmd file by using WindowsSDK_UnionMetadataPath. But this property is not always defined where we expect (e.g. in JavaScript UWP apps), and the condition can be modified to consider the “TargetPath” where the union is located.
Customers debugging JavaScript UWP apps with a dependency on a Managed WinRT component are observing the Desktop CLR loaded, instead of CoreCLR. This is because expected Framework Injection is not happening due to a failing check.
Low, the change does not remove any of the existing checks
Is this a regression from a previous update?
No, I don't believe this has ever worked in VS2017
Root cause analysis:
PR 60393 extended framework injection to cover C++, but that approach did not work for JavaScript, and that was not considered at the time of the original fix.
Whenever a UWP app contains managed code we need to be sure to inject the .NET Core Framework assemblies. This is obviously the case when the app itself is written in C# or VB. However, we also need to handle the case where the app is written in JavaScript but references a WinRT component written in managed code.
Previously, this check was updated (for C++ apps) to look for the full location of the Windows.winmd file by using
WindowsSDK_UnionMetadataPath. But this property is not always defined where we expect (e.g. in JavaScript UWP apps), and the condition can be modified to consider the “TargetPath” where the union is located.Corresponding VS PR: 87422
Customer scenario
Customers debugging JavaScript UWP apps with a dependency on a Managed WinRT component are observing the Desktop CLR loaded, instead of CoreCLR. This is because expected Framework Injection is not happening due to a failing check.
Bugs this fixes:
445509
Workarounds, if any
N/A
Risk
Low, the change does not remove any of the existing checks
Is this a regression from a previous update?
No, I don't believe this has ever worked in VS2017
Root cause analysis:
PR 60393 extended framework injection to cover C++, but that approach did not work for JavaScript, and that was not considered at the time of the original fix.
How was the bug found?
Partner reported