Repository navigation
System.Private.CoreLib should expose consistent surface area across all OSes #7553
Description
Today it does not which leads us in CoreFx to know whatever your ifdefs may be to be sure we build all the facades for them. In 1.0 this caused us to ship a facade with dangling forwards for System.Runtime.InteropServices.WindowsRuntime on linux.
Ideally I'd like to see a reference assembly that is the agreed-upon contract for CoreLib.
Activity
danmoseley commentedon Mar 3, 2017
Would this include other runtimes- CoreRT etc?
jkotas commentedon Mar 3, 2017
Yes, it is what we should be shooting for as the ideal situation. Figuring the plan for Windows/Unix CoreCLR diff would be the first step.
gkhanna79 commentedon Mar 4, 2017
CC @weshaggard
weshaggard commentedon Mar 6, 2017
While we can create a reference assembly if we feel it is useful we could also just use one of the builds as the representative and put APICompat checks in place to make sure the other builds remain compatible and consistent.
Ignoring the reference assembly for a moment do we think we can even have consistent surface area? For the WinRT types for example is it going to cause any issues if we just include them in the Unix builds?
jkotas commentedon Mar 7, 2017
This can work for CoreCLR only, but I think it would be hard to make it work for both CoreCLR+CoreRT.
weshaggard commentedon Mar 7, 2017
Do you actually think we will be able to make these all agree? While I think that is a good goal it will require merging most of S.Private.Interop into S.P.CoreLib on CoreRT as well. Also if we plan to do that we will need to address the difference in public key tokens. I intentionally made the key different (CoreCLR has SL key and CoreRT has MSFT key).
jkotas commentedon Mar 7, 2017
It would be a chunk of work. I think it is doable. We are slowly getting them to agree as part of other work. They are certainly closer than what we had 1 or 2 years ago.
If we do not think it is worth spending time on it, we can just let them disagree accross runtimes and OSes and setup the engineering system around it (e.g. have separate internal CoreCLR targeting pack for Windows and Unix).
Or introduce S.Private.Interop in CoreCLR.
Nothing looks at the public key tokens in .NET Core. They can mismatch (and do mismatch in practice) just fine.
danmoseley commentedon Mar 16, 2017
Can we move this to Future?
jkotas commentedon Mar 16, 2017
I think so
ericstj commentedon Mar 14, 2020
Related: #33128
1 remaining item
ericstj commentedon Mar 14, 2020
Related: #2138
dotnet-policy-service commentedon Sep 13, 2024
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.
This process is part of our issue cleanup automation.
dotnet-policy-service commentedon Sep 28, 2024
This issue will now be closed since it had been marked
no-recent-activitybut received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.