Repository navigation
fix: resolve core library types in IL post-processing under .NET reference assemblies - #4188
BrianUnity wants to merge 1 commit into
Conversation
…rence assemblies PostProcessorReflectionImporter mapped System.Private.CoreLib types only to a referenced mscorlib or netstandard. Assemblies compiled against .NET reference assemblies (net10) reference neither, so imported types such as Guid stayed scoped to System.Private.CoreLib and Resolve() returned null. When the module references neither, scope the type to the referenced assembly that defines or forwards it.
|
Check the configuration's TOML syntax, permitted settings, and size limit. See the error below. Error message: Configuration content:# This is the configuration for the u-pr bot
# https://github.cds.internal.unity3d.com/unity/u-pr
# For configuration of this file:
# https://developer.portal.internal.unity.com/catalog/default/component/u-pr/docs/configuration/automatic_runs/
[github_app]
handle_pr_actions = ['opened', 'ready_for_review'] # PR events that auto-run pr_commands
pr_commands = ["/harness-review"] # what runs on those events
reviewer_commands = ["/harness-review"] # what runs when @u-pr is added as reviewer
|
There was a problem hiding this comment.
💡 Harness Review
The change adds per-type core-library scope resolution while preserving the existing corlib mapping. I examined the lookup, assembly resolver, CodeGen import order, and changelog and found no actionable issues.
Reviewed commit 0f62376
🤖 Helpful? 👍/👎
|
Is this related (solves) https://jira.unity3d.com/browse/UUM-155996? |
Codecov ReportAll modified and coverable lines are covered by tests ✅ @@ Coverage Diff @@
## develop-3.x.x #4188 +/- ##
==============================================
Coverage 78.26% 78.26%
==============================================
Files 153 153
Lines 26359 26359
==============================================
Hits 20631 20631
Misses 5728 5728
Flags with carried forward coverage won't be shown. Click here to find out more.
|
Purpose of this PR
We're attempting to get packages compiling under MS Build and targeting .NET 10. When NGO's assemblies are compiled against .NET reference assemblies (for example when targeting .NET 10), the CodeGen post-processor cannot resolve core library types it imports through
typeof().PostProcessorReflectionImportermapsSystem.Private.CoreLibtypes to the module'smscorlibornetstandardreference. A module compiled against the .NET reference pack has neither: the pack splits the core library acrossSystem.Runtime,System.Collectionsand other assemblies. The imported type stays scoped toSystem.Private.CoreLib, andResolve()returns null.The fix: when the module references neither
mscorlibnornetstandard, scope aSystem.Private.CoreLibtype to the referenced assembly that defines or forwards it, with a per-type cache. Mapping everything toSystem.Runtimeis not enough, becauseList<T>, for example, lives inSystem.Collections. Modules that referencemscorlibornetstandardtake the old path, so existing builds are unchanged.Entities and Multiplayer Tools have the same importer and get the same fix.
Jira ticket
None.
Changelog
com.unity.netcode.gameobjects
GuidandList<T>, in assemblies compiled against .NET reference assemblies, for example when targeting .NET 10.Documentation
Testing & QA (How your changes can be verified during release Playtest)
Tested with a Unity editor that compiles packages for .NET 10, on a project with NGO's EditMode tests, Entities and Multiplayer Tools (all three with this fix):
BasicBuildTest, which is unrelated).Builds that target netstandard take the unchanged code path.
Functional Testing
Manual testing :
Manual testing doneAutomated tests:
Covered by existing automated testsCovered by new automated testsDoes the change require QA team to:
Review automated tests?Execute manual tests?Provide feedback about the PR?If any boxes above are checked the QA team will be automatically added as a PR reviewer.
Up-port
Not needed: this PR targets develop-3.x.x.
Backports
Not planned. .NET 10 targeting only applies to the newest editors, which use NGO 3.x. The importer on develop-2.0.0 differs only in its namespace, so the same change can go there if NGO 2.x needs it.