Allow to build a projection out of a component

[sylveon]

This option comes in handy when you are writing IDL files in your projects not to produce a component but to consume some API without needing to carry the WinMD around (e.g. only consuming some parts of the API, not wanting to check in binaries to source control, third-party provides an IDL, etc). Without this change, you would face issues with trying to call static functions or constructors, because it was expecting an implementation to be present from a .g.cpp file while there is none (since you are not actually implementing the API).

[kennykerr]

@jlaanstra

[kennykerr]

Sorry for the delay. There's a potential issue with #1019 so until that's been sorted out we just need to hold off on any further msbuild changes. I'm still waiting for an internal team with an issue with #1019 to confirm.

[jlaanstra]

I will look into this but it might be a bit until I have time.

[sylveon]

No problem, this isn't anything urgent

[ChrisGuzak]

Is "this option" CppWinRTCompAsProjection? If so mention it and how to configure your project with this.

[sylveon]

Yeah, will add docs. Should I expose it in the VS properties dialog?

[jlaanstra]

The change as authored doesn't make sense. You're inside the GenerateComponentProjection target and you add a flag to make it not generate a component. Doesn't seem right. As far suggesting an alternative I'm not sure I fully understand what you're trying to achieve.

[jlaanstra]

It seems like what you want is to generate WinMD from idl and then generate a reference projection for the WinMD just created?

[sylveon]

Yes, exactly. I want to add IDL to a project representing some third-party API, and then having headers generated so that I can consume it (assume it's activatable, for example via reg-free WinRT).

In my specific use case, I want to use some APIs from the UDK that is shipped in Windows 11 (C:\Windows\SystemApps\MicrosoftWindows.UndockedDevKit_cw5n1h2txyewy\windowsudk.winmd), but would rather not commit the binary to avoid infringing anything. Plus it's not great practice to begin with and I don't want to require Windows 11 to be installed to build the app.

So instead I got IDL from winmdidl and copy-pasted the parts I need into an IDL file that I added to my project. While I can consume the non-static members, static members and constructors don't work (I get a linker error) because cppwinrt assumes those are implemented in my own project (so I have to activate it manually and then cast it to the WinRT type).

This PR was admittedly a quick workaround to get static members and constructors to work, maybe there's a better way to do this I'm not aware of?

[ChrisGuzak]

@sylveon there are no documented Windows APIs in that metadata file, but do let us know what you’d like added in a future release or over on github.com/Microsoft/windowsappsdk … winappsdk is a reasonable place to put a real documented thing that knows how to invoke the UDK component.

[sylveon]

This is a very very very specific use case, but I use WindowsUdk.UI.Shell.ShellViewCoordinator to be able to know when the search panel is invoked (my entire app is based around modifying the appearance of the taskbar using the undocumented SetWindowCompositionAttribute API depending on certain conditions, one of these being the search panel is visible on screen). In Windows 10 I used Windows.Internal.Shell.Experience.SearchAppExperienceManager, which is arguably even worse since I didn't even have a reference WinMD file, it was reverse engineered. That API doesn't work anymore in 11, so I investigated for an alternative and found the UDK, it has so many goodies for my use case :P

I originally didn't want to mention my exact use case because I expected a reply like that. It doesn't make the original need any less valid however: not wanting to check-in third-party winmd files, third-party provided IDL, etc.

[kennykerr]

Ignoring the specific use case, the idea of needing to generate a projection from some IDL seems sound.

[ChrisGuzak]

I see that if I create a C++ WinRT universal component project and then delete everything except the .idl files it builds the .winmd file from the .idl. I set the project namespace to the root of what I wanted in the .winmd and that collected all of the types. but I see when I try to reference this from a C++ WinRT console project I get an error A reference to XXX cannot be added because the two projects target different platforms.. Maybe there is a way to override this check.

Update: I change the project type to static lib and was able to create the reference. but then mdmerge hits problems in the dependent project. looking more but I may give up for the weekend.

[sylveon]

I think adding the <DesktopCompatible>true</DesktopCompatible> property will make VS allow you to add a reference.

[jlaanstra]

Ignoring the specific use case, the idea of needing to generate a projection from some IDL seems sound.

I agree. It might be a bit before I have time to add support. I'm thinking to support metadata on an idl file that we can use to split idl files in two groups. Group 1 will work as today, while Group 2 will generate a reference projection. That way the changes are mostly additive and will have the least amount of impact on existing projects.

[kennykerr]

Great, then why don't we create an issue and close this PR for now? What do you think @sylveon?

[sylveon]

Sounds good to me!

[sylveon]

Opened #1048