-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Build the shim assemblies as part of libs.sfx #89005
Conversation
The shims build was intentionally kept out of the libs.sfx subset as some shims reference out-of-band assemblies that also need to be built. Since that change was made, the shim assemblies now don't reference all out-of-band assemblies by default anymore and instead use fine grained dependencies. Because of that, the number of out-of-band projects referenced and built as part of the shims build is much smaller (~10 projects). This fixes issues with ouf-of-band source generators not being able to target the live targeting pack. These source generators need the shims (more precisely the netstandard.dll shims) as some of the referenced Microsoft.CodeAnalysis packages don't provide a .NETCoreApp assembly.
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsUnblocks #88973 The shims build was intentionally kept out of the libs.sfx subset as some shims reference out-of-band assemblies that also need to be built. Since that change was made, the shim assemblies now don't reference all out-of-band assemblies by default anymore and instead use fine grained dependencies. Because of that, the number of out-of-band projects referenced and built as part of the shims build is much smaller (~10 projects). This fixes issues with ouf-of-band source generators not being able to target the live targeting pack. These source generators need the shims (more precisely the netstandard.dll shims) as some of the referenced Microsoft.CodeAnalysis packages don't provide a .NETCoreApp assembly.
|
cc @MichalStrehovsky as we chatted about this in the past. You can now build |
8458a88
to
cf755a3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love to see us adding this infra. Have a few suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is good and my feedback is not blocking. Remaining feedback is naming and testing suggestions.
Here are the diffs for the impacted shim assemblies. I found a few issues that I fixed with the latest commit:
APICompat doesn't seem to protect these type forwards as the left side is missing the destination assemblies. We could protect this path by adding PackageReferences to apicompat.proj for the ~19 missing out-of-band assemblies on the left hand side (baseline).
|
|
||
<!-- Restore and reference assemblies required for resolving type forwards on the baseline (left) side. --> | ||
<ApiCompatLeftTypeForwardDestinationPackage Include="@(ApiCompatTypeForwardDestinationPackage)" /> | ||
<ApiCompatLeftTypeForwardDestinationPackage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you got this all fixed up now, but one thing you might consider is using a project to do an actual restore of the old Microsoft.Windows.Compatibility
package and all assets for a particular target framework. That might avoid juggling all the PackageDownload items.
@ViktorHofer the coreclr / mono runtime tests builds appear to be broken with this change. Those legs weren't run in this PR.
|
Taking a look |
Give me 30min and otherwise let's revert my change. Here's my attempt to fix it: #89115 |
* Fix broken runtime tests build Follow-up on #89005 * Update build-test-job.yml * Update sfx-ref.proj
This is awesome! Thank you! Submitted #89153 to save money on CI. |
The shims build was intentionally kept out of the libs.sfx subset as some shims reference out-of-band assemblies that also need to be built.
Since that change was made, the shim assemblies now don't reference all out-of-band assemblies by default anymore and instead use fine grained dependencies. Because of that, the number of out-of-band projects referenced and built as part of the shims build is much smaller (~10 projects).
This fixes issues with ouf-of-band source generators not being able to target the live targeting pack. These source generators need the shims (more precisely the netstandard.dll shims) as some of the referenced Microsoft.CodeAnalysis packages don't provide a .NETCoreApp assembly.