What's best practice when it comes to handling transitive types/namespaces needing inclusion?

[mjr4077au]

This is my first time using the project. When I try to do something like <CsWinRTIncludes>FocusSessionManager</CsWinRTIncludes>, I get endlessly recurring compilation issue as I need to keep adding more types. If I bite the bullet and just add Windows.Foundation, then the scope only widens further by necessitating Windows.Storage, etc, which I likely do not need. This isn't an issue in CsWin32 for instance; it just automatically adds dependent types.

Is there some hidden auto-resolution mode I'm unaware of? What are people doing in their own projects? Is this something CsWinRT will resolve in 3.0?

[manodasanW]

@mjr4077au, are you intentionally trying to use our embedded support? If not, I would recommend updating your project's target framework to one that includes the Windows OS version like net10.0-windows10.0.26100.0 which is what most folks do and that would bring in the Windows SDK projection that we have generated for the Windows namespace. The .NET SDK has a reference to that package and it brings it in automatically when that TFM is used based on OS version. That way you don't need to worry about projecting it yourself. This is a difference in behavior from how CsWin32 works where there isn't anything precompiled.

[mjr4077au]

My use case is a PowerShell module and I was deliberately trying to avoid the SDK DLL file as it's some 25MB, approximately 50x larger than my module in of itself. I tried to do something simple like <CsWinRTIncludes>Windows.UI.Shell.FocusSessionManager</CsWinRTIncludes>, but then I'll receive errors like "The type or namespace name 'TypedEventHandler<,>' does not exist in the namespace 'Windows.Foundation'", etc. By the time I resolve that by adding Windows.Foundation.TypedEventHandler and everything else that appears on the list following each compilation, I get to the point where I can't even continue as CsWinRT isn't projecting stuff like the Windows.UI.Color struct.

It's probably a lack of understanding on my part, but what's the purpose of CsWinRT if I still require the SDK DLL since it can't project/generate all documented CsWinRT types. It also seems to be missing a number of interfaces as well. The neverending transistive types, I could handle, but I don't want to have to make my own polyfills to fill in the gaps from CsWinRT. If I'm stuck on having to use the SDK DLL, if possible, I'll have to make a dummy executable project to consume my DLL, trim that, then retrieve the trimmed SDK DLL out of it.