Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split dotnet/runtime-only downlevel LibraryImport support into its own source generator #106436

Merged
merged 14 commits into from
Aug 21, 2024

Conversation

jkoritzinsky
Copy link
Member

Instead of shipping unusable downlevel support in LibraryImportGenerator and having to maintain how it works in combination with the non-downlevel support that we actually expect users to use, split the generator into two separate generators:

  • LibraryImportGenerator: Our shipping current-TFM support
  • DownlevelLibraryImportGenerator: dotnet/runtime-only .NET Standard + .NET Framework support.

The Downlevel support only needs to support standard and NETFX as all .NETCoreApp TFMs we target for downlevel support all ship LibraryImportGenerator already (and they build using the version that shipped with the TFM).

This PR also shares the managed->unmanaged stub generation between LibraryImportGenerator and ComInterfaceGenerator to reuse more code cleanly.

The MSBuild changes in Directory.Build.targets help fix a problem where the TFM-included generators would be removed in the generator unit test projects, which also reference the projects directly as regular (non-analyzer) references. This would fail sporadically when working locally before this change, but the changes in generators.targets caused the intermittent failure to become consistent.

Copy link
Contributor

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Copy link
Member

@jtschuster jtschuster left a comment

Choose a reason for hiding this comment

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

Don't see any issues aside from the JS generator test failures.

@jkoritzinsky
Copy link
Member Author

/ba-g failure is a network timeout that looks generally flaky

'$(DisableImplicitFrameworkReferences)' == 'true' and
(
'@(Reference->AnyHaveMetadataValue('Identity', 'System.Runtime.InteropServices'))' == 'true' or
'@(ProjectReference->AnyHaveMetadataValue('Identity', '$(CoreLibProject)'))' == 'true'
'@(Reference->AnyHaveMetadataValue('Identity', 'System.Private.CoreLib'))' == 'true'
Copy link
Member

Choose a reason for hiding this comment

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

This change looks wrong. System.Private.CoreLib is never a reference as it isn't part of the targeting pack.

Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

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

This change requires updating all the solution files as this is adding a new dependency. Can you please do that? The command is .\dotnet.cmd build src\libraries\slngen.proj.

Please also check if the System.Private.CoreLib slns need to be updated.

Condition="'$(EnableLibraryImportGenerator)' == '' and
(
'$(IsSourceProject)' == 'true' or
'$(IsTestProject)' == 'true' or
'$(IsTestSupportProject)' == 'true'
) and
'$(MSBuildProjectExtension)' == '.csproj' and
!$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', '$(NetCoreAppMinimum)'))" />
Copy link
Member

@ViktorHofer ViktorHofer Aug 22, 2024

Choose a reason for hiding this comment

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

This should just be $(TargetFrameworkIdentifier)' != '.NETCoreApp' as we shouldn't support targeting an out-of-support .NETCoreApp TFM.

@@ -1,51 +1,56 @@
<Project>

<PropertyGroup>
<!-- Enable LibraryImportGenerator for CoreLib. -->
Copy link
Member

Choose a reason for hiding this comment

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

I understand that this already existed before this change but it feels weird to special case CoreLib in here. Can we move this property into the shared CoreLib project instead?

@jkoritzinsky
Copy link
Member Author

@ViktorHofer I've addressed your feedback in #106827

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Runtime.InteropServices source-generator Indicates an issue with a source generator feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants