Skip to content

Conversation

@manodasanW
Copy link
Member

  • With this change, projection projects need CsWinRTGenerateReferenceProjection set to true. When this is set, a reference assembly and a forwarder assembly is generated (replaces the output DLL that gets built).
  • Components would distribute both these binaries and with project references they would just flow through.
  • On the final app project which consumes all the reference projection assemblies, cswinrt is triggered to generate a merged projection of all of them. The forwarders are also included in the output folder which means any references to the projection DLL are forwarded to the merged projection DLL.
  • In the reference projections, we exclude the entire ABI namespace. This was achieved via changes to codewriters based on detecting a reference projection is being generated. The changes here could have been more scoped if we just built only a reference assembly with ProduceOnlyReferenceAssembly which is possible but that relied on an assumption that if we generated sources which referenced ABI namespaces that aren't there that they will continue to build like they do today and also have more msbuild target changes to enable (seen here). So, to keep it straight forward, we do the equivalent in codewriters instead.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds support for reference projections in CsWinRT, enabling a new build configuration where projection projects can generate reference assemblies and forwarder assemblies, with a merged projection created at the final application level.

Key Changes:

  • Adds new CsWinRTGenerateReferenceProjection property and CSWINRT_REFERENCE_PROJECTION conditional compilation symbol
  • Introduces code generation modifications to exclude ABI namespace types when generating reference projections
  • Implements new generator tools (cswinrtprojectiongen and cswinrtimplgen) with supporting infrastructure

Reviewed changes

Copilot reviewed 45 out of 45 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
src/cswinrt/settings.h Adds reference_projection boolean flag to settings
src/cswinrt/main.cpp Implements command-line argument parsing and conditional ABI namespace generation
src/cswinrt/code_writers.h Modifies code writers to conditionally generate throw null stubs and exclude ABI-related attributes
src/cswinrt/strings/ComInteropHelpers.cs Wraps interop helper implementations with preprocessor directives
src/cswinrt/strings/additions/* Conditionally excludes marshaller attributes for reference projections
src/WinRT.Projection.Generator/* New projection generator tool for creating merged projections
src/RunCsWinRTGeneratorTask/* New MSBuild tasks for running generator tools
nuget/Microsoft.Windows.CsWinRT.targets Configures build properties and targets for reference projection support
src/cswinrt.slnx Updates solution configuration
src/Directory.Packages.props Updates Roslyn package versions

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

manodasanW and others added 2 commits December 6, 2025 19:02
…Generate.cs

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Comment on lines 6 to 7
[WindowsRuntimeMetadata("Microsoft.UI")]
[WindowsRuntimeClassName("Windows.Foundation.IReference<Microsoft.UI.Xaml.Media.Animation.KeyTime>")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these attributes should also be hidden from reference assemblies, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we use these in cswinrtgen right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but I feel like we should still find a way to hide them. In theory both the metadata and the runtime class name can be derived at compile time anyway. We could check if a type is a projected type just by checking if the defining assembly is a projection assembly, and the runtime class name we can just compute in 'cswinrtgen' easily, we already have most of the logic for it anyway. That would allow us to just keep these attributes in the merged projection and hide them from here.

/// </summary>
public AssemblyReference WinRTProjection => field ??= new AssemblyReference(
name: "WinRT.Projection"u8,
version: new Version(0, 0, 0, 0),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking this should rather match the .dll version with WinRT.Interop.dll? You can copy the logic we use for that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we can, but I don't pass the project dll to the projection generator today and it is generated differently from WinRT.Interop due to it uses the CSharpCompilation to do so. We can technically pass a parameter for the version and then add a version attribute which is passed to the CSharpCompilation if we want, but does it add any benefit?

manodasanW and others added 8 commits January 15, 2026 16:57
… by making this only build reference assemblies and then removing the constructors that reference it.
…ing implementation assemblies other than for projection DLLs
Introduces IsWindowsRuntimeReferenceAssembly property to check for the WindowsRuntimeReferenceAssemblyAttribute. Adds related metadata names to WellKnownMetadataNames for attribute detection.
Sergio0694 and others added 2 commits January 17, 2026 14:58
Refined logic for filtering and processing assemblies in Interop and Impl generators, clarified XML documentation, and added comments to explain handling of Windows Runtime projections and implementation assemblies. Improved method signatures and parameter documentation for better maintainability and clarity.
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 63 out of 63 changed files in this pull request and generated 15 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

manodasanW and others added 4 commits January 17, 2026 19:14
Corrected minor typos in comments to consistently refer to 'assembly paths' and 'output assembly path' for improved clarity.
@azure-pipelines
Copy link

There was an error handling pipeline event f7a99059-766f-4842-a682-03c3361647ac.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants