Blank App (WinRT/C++) Can't add nuget package Microsoft.Toolkit.Uwp.UI.Controls

[sudheer4596]

Describe the bug

When adding the nuget library Microsoft.Toolkit.Uwp.UI.Controls, the following error is displayed and the install fails:

Severity	Code	Description	Project	File	Line	Suppression State
Error		Could not install package 'Microsoft.Toolkit.Uwp.UI.Controls 6.1.1'. You are trying to install this package into a project that targets 'native,Version=v0.0', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Steps to Reproduce

In Visual Studio 2019 create a Blank App (C++/WinRT) project
Attempt to add the Microsoft.Toolkit.Uwp.Uwp.UI.Controls NuGet package. Add the latest 6.1.0 package.
Note Error message,

Expected behavior

The package should be added to the project without error.

Screenshots

Environment

NuGet Package(s): 
Microsoft.Toolkit.Uwp.UI.Controls

Package Version(s): 
6.1.1

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ x] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Fall Creators Update (16299)
- [ x] April 2018 Update (17134)
- [ ] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (xxxxx)

Device form factor:
- [ x] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio 
- [ ] 2017 (version: )
- [ x] 2019 (version: 16.8.3) 
- [ ] 2019 Preview (version: )

Additional context

Looks like this is related to the issue https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3419

[ghost]

Hello sudheer4596, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[Kyaa-dost]

Thanks, @sudheer4596 for highlighting this issue and I am able to repro this as well with Ver: April 2018 Update (17134). I tried to investigate but not certain what is causing this issue. Let's see if any community member can investigate this further.

[michael-hawker]

Hi @sudheer4596 the Toolkit is based on C# but is not a Windows Runtime Component, so it's not directly consumable in C++ applications.

It's theoretically possible to create a C# based project in your solutions, consume that from your C++ app, and then consume the Toolkit via that, but I'm not sure how well the tooling supports that scenario. Last I checked a couple of years ago, the Toolkit dlls needed to be copied to the output directory manually. It's not something we've checked recently, nor do we have a guide on it. If you do experiment and write down steps, we'd be happy to add it to our wiki for others to be able to follow in the future.

Though we've found most C++ developers don't want to pull in the .NET runtime as well, so we haven't had too many requests for this. We aren't a Windows Runtime Component as it has certain implications on how we can developer our controls which makes them harder to create and manage.

We are exploring if it's worth making a few of our lower-level libraries Windows Runtime Components, but we haven't made a decision on that yet.

I'll leave this open for now so others can 👍 vote on it and we can gauge interest if this is a direction we should explore in the future, especially as there may be more C++ developers onboarding to WinUI 3 in the future. Thanks!

[michael-hawker]

We should probably have a sample project setup which shows how to do the indirection required to insert C# components in C++, like those from the Toolkit.

@marcpems @HerrickSpencer think this would be useful?

[michael-hawker]

Since this is our main issue, copying this comment here:

Not all components have to be universal or "Windows Runtime Components" which work with both languages [C++/C#]. Developing Windows Runtime Components has more overhead and limitations on the developers, so we didn't go down that path in the Windows Community Toolkit. Therefore our controls are mainly targeted towards C# development only.

However, (at least on UWP) it is possible still to consume our components within a "C# Island". Basically you can wrap components within a UserControl which you could then place within your app as a whole section of your UI (good for things like DataGrids). This still pulls in the .NET runtime though so adds footprint to your app, which is why in the past we haven't prioritized showing how to integrate them (as we've heard that many C++ developers don't want that either).

These two docs show how this scenario works for UWP:

• Use a C# component from C++/WinRT
• Building C++/WinRT apps that consume C# components

I've been working on putting a sample together for this.

However, I'm not sure how any of this applies to WinUI 3 yet. That's the next step in my journey for a future sample.

[ChrisGuzak]

Please provide native C++ support. interop is painful and comes with perf impact.

[michael-hawker]

@ChrisGuzak we're a managed C# based project; the best we could do is be a Windows Runtime Component, which still would load the .NET runtime. As I called out elsewhere there's restrictions with being a WRC and it's not something feasible for us to do.

We're also not going to re-write things in C++, that's what the platform's WinUI library is for. If there's something that's in the Toolkit that you think many developers need, please open a request on the WinUI library and we're happy to work with them to transfer things from the Toolkit to the platform as we've done in the past for scenarios with broad appeal.

If there's some other solution beyond those two possibilities to achieve better interop, please let us know.

[ChrisGuzak]

@michael-hawker got it. I see the project page does not mention C#, C++, managed or native. consider updating it to set expectations for people that might want to use it from C++.

[michael-hawker]

Thanks @ChrisGuzak in the about box we call out .NET:

But we don't really mention this in the readme, so if you scroll past it then it'd be good to re-iterate.

We've typically tried to call it out as .NET as it's not specific to C#, many things can be used in VB as well. It's more a function of the impact on WinRT and that we're not Windows Runtime Components easily interoperable with C++/native code.

[michael-hawker]

Assigning to myself as I still have the example to publish, I should probably push the basics I have now, though there's more I want to do with it.

In the meantime, @RosarioPulella @Sergio0694 any thoughts on phrasing for our Readme?

[michael-hawker]

I've published the sample which shows how to do this here: https://github.com/CommunityToolkit/Sample-Windows-CppWinRT

I'll close this issue now. Thanks!