search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.16k stars 4.71k forks source link

System.Private.CoreLib should expose consistent surface area across all OSes #7553

Closed ericstj closed 3 weeks ago

ericstj commented 7 years ago

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.

danmoseley commented 7 years ago

Would this include other runtimes- CoreRT etc?

jkotas commented 7 years ago

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 commented 7 years ago

CC @weshaggard

weshaggard commented 7 years ago

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 commented 7 years ago

just use one of the builds as the representative

This can work for CoreCLR only, but I think it would be hard to make it work for both CoreCLR+CoreRT.

weshaggard commented 7 years ago

This can work for CoreCLR only, but I think it would be hard to make it work for both CoreCLR+CoreRT.

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 commented 7 years ago

Do you actually think we will be able to make these all agree?

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).

it will require merging most of S.Private.Interop into S.P.CoreLib on CoreRT as well

Or introduce S.Private.Interop in CoreCLR.

we will need to address the difference in public key tokens

Nothing looks at the public key tokens in .NET Core. They can mismatch (and do mismatch in practice) just fine.

danmoseley commented 7 years ago

Can we move this to Future?

jkotas commented 7 years ago

I think so

ericstj commented 4 years ago

Related: https://github.com/dotnet/runtime/issues/33128

ericstj commented 4 years ago

Related: https://github.com/dotnet/runtime/issues/2138

dotnet-policy-service[bot] commented 1 month ago

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[bot] commented 3 weeks ago

This issue will now be closed since it had been marked no-recent-activity but 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.