Ability to simply add a reference to a project/winmd #1072
Replies: 1 comment 4 replies
-
|
@JaiganeshKumaran - we recently added support for embedding WinRT types into your app or library with C#/WinRT. You can try out the feature and compile the interop code with your app. Here are samples for this scenario as well: https://github.com/microsoft/CsWinRT/tree/master/src/Samples/TestEmbedded It would be great to get feedback on this and if it helps with your scenario. |
Beta Was this translation helpful? Give feedback.
-
|
@angelazhangmsft My goal is basically just to call a C++ library in an object-oriented way from a C# GUI app. P/Invoke looks too low level, so I thought a C++/WinRT could be the way to go. Attempt 1 - Follow the documentationPreparation
Attempt
<PropertyGroup>
<CsWinRTEmbedded>true</CsWinRTEmbedded>
<CsWinRTWindowsMetadata>sdk</CsWinRTWindowsMetadata>
<CsWinRTGenerateProjection>true</CsWinRTGenerateProjection>
<CsWinRTIncludes>
winuicomponent.cpp;
</CsWinRTIncludes>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\winuicomponent.cpp\winuicomponent.cpp.vcxproj" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Windows.CsWinRT" Version="2.0.7" />
</ItemGroup>
Looking at the first of these reveals this generated code in namespace Microsoft.UI.Xaml
{
using System.Runtime.Serialization;
// ...Is this generated code wrong? I would think the
At this point I have a vague guess that maybe I have "too much WinUI" in my project? I remember my initial confusion about choosing between these three, all of which have descriptions that each mention C++, Windows Runtime and UWP. SuggestionThe descriptions of project templates should be much more informative, so that the differences are clear to the developer.
<CsWinRTExcludes>
Windows.Foundation.Diagnostics;
Windows.Foundation.PropertyType;
</CsWinRTExcludes>Suggestion:The documentation should provide comprehensive steps to get to a working minimal example instead of providing some steps but leaving out others. Adding this solves the latest error, now I have only 5, but after Rebuild Solution it's 7, adding two of these:
I give up at this point and try to lego together something from the official samples. Attempt 2 - Adapt the examples to my own usecase
SuggestionThe example project should be self contained and immediately runnable on its own in order for us to be able to use it as a template. It should not depend on a hardcoded path of a locally built version of the whole CsWinRT project.
SuggestionMaybe use git submodules to immediately clone required related repos? Ideally the VS solution should be self contained. It really makes Microsoft itself look bad that its own development tools are not sufficient for its own projects and require custom shellscripts as glue.
SuggestionVS should suggest installing all of the missing SDK-s at the same time, and the autofix installation should actually work.
Attempt 3 - Try to use this in a WPF projectAs long as I do not reference the WinRT component anywhere in my C# code, I can get the C# projection file of my library generated into "Summary"My experience at this point is that the developer experience of cross-language Windows apps is abysmal. Just looking at the VS project template selector, the relationship between Universal Windows Platform, UWP, Windows Runtime, WinRT, WinUI, various versions of .NET, the differences between .NET Framework, .NET, .NET Core, .NET Standard and who knows how many others makes their compatibility matrix completely incomprehensible for the average developer. I tried to provide concrete suggestions where I could, but ultimately it should boil down to "create a project, write some code, create another project, reference the first one and start calling it from code". The fact that both C++ and C# have been first class languages on Windows since the inception of C# and there is still no straightforward, up to date, supported way, with a smooth developer experience, to create object-oriented bindings between them is mind blowing. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback on the embedded samples, I agree we do need to make them more standalone and not require you to run build.cmd and install multiple SDKs and so on. For your original issue, can you confirm whether the project you are trying to use embedded support in is a With respect to the actual errors, some of the errors are going to be due to using the Windows version specific TFM together with embedded support as it is going to see the same types being embedded already in the Windows SDK projection that is distributed with the TFM. And it is not going to know which one to call such as those errors saying ambiguous calls. Some of the other errors, specifically the ones you highlighted first, look to be because we hadn't tested embedded support with WinUI projections and looks like that discovered that the compiler is getting confused between |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! I have managed to get it working in my WinUI app project. SuggestionI think it was the documentation that misled me down the wrong rabbithole. Here https://github.com/microsoft/CsWinRT/blob/master/docs/usage.md
Nowhere does it say that you can simply include CsWinRT in your application project as a way to directly reference a WinRT component and start using it right there. It seems I'm not the only one that have read the docs and concluded that wasn't possible:
I think the docs should emphasize the simplest usecases and then go into the complex ones. WPFWhen trying to use CsWinRT in WPF, I am still experiencing the bug where the generated projection file disappears as soon as I reference it in code. To illustrate it better: This compiles: This is my csproj: <Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net6.0-windows</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<UseWPF>true</UseWPF>
</PropertyGroup>
<PropertyGroup>
<CsWinRTWindowsMetadata>sdk</CsWinRTWindowsMetadata>
<CsWinRTGenerateProjection>true</CsWinRTGenerateProjection>
<CsWinRTIncludes>
winrtcomponent_cpp;
Windows.Foundation;
</CsWinRTIncludes>
<CsWinRTExcludes>
Windows.Foundation.Diagnostics;
Windows.Foundation.PropertyType;
</CsWinRTExcludes>
<PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Windows.CsWinRT" Version="2.0.7" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\winrtcomponent.cpp\winrtcomponent.cpp.vcxproj" />
</ItemGroup>
</Project>
(Experimenting with these does not fix the file-disappearing issue.) |
Beta Was this translation helpful? Give feedback.
-
|
@manodasanW Do you have a suggestion on what should I do to be able to use this in WPF? |
Beta Was this translation helpful? Give feedback.
-
Today adding a project/winmd reference even if C#/WinRT is installed doesn't work. The documentation tells to create an interop assembly using C#/WinRT, package into a .nupkg and reference that instead but it seems complicated and I just want to reference a project/winmd directly. C#/WinRT should automatically generate the required interop code in the consuming project just like C++/WinRT and shouldn't require extra from the component development.
Beta Was this translation helpful? Give feedback.
All reactions