Runtime: S.R.InteropServices.JavaScript is part of the shared framework but doesn't have a ref assembly

[ViktorHofer]

System.Runtime.InteropServices.JavaScript is currently declared as part of the shared framework but doesn't have a reference assembly. As the project isn't OOB either, there is currently no way for a customer to reference the library besides directly referencing the implementation one from the shared framework directory.

Is the omission of a reference assembly intentional?

cc @kjpou1 @marek-safar @ericstj

[msftbot[bot]]

Tagging subscribers to this area: @safern, @viktorhofer
Notify danmosemsft if you want to be subscribed.

[jkotas]

This is internal library, for internal consumption only for now.

See https://github.com/dotnet/runtime/pull/35573#discussion_r421408401

[safern]

So then we should close the issue as by design?

[ericstj]

Do we want to change the name to System.Private to indicate it is internal only? We've done so elsewhere (CoreLib, URI, XML).

[marek-safar]

Do we want to change the name to System.Private to indicate it is internal only?

Is it worth it? We'll probably make the library public in the future (e.g. .NET7).

[stephentoub]

Is it worth it? We'll probably make the library public in the future (e.g. .NET7).

I would think so. That's two releases away, including an LTS.

[ericstj]

Do we think its worth the risk to change the name at this point in the release? What could break if we change this name? cc @steveisok @akoeplinger

[lewing]

Nothing external should break at this point, the name is already different than the 3.2 counterpart. The name is referenced in a couple of places by the js internally, and at least one test helper.

[steveisok]

I think this is pretty low risk and we should be able to change it.

[akoeplinger]

I think I already did add the reference assembly as part of https://github.com/dotnet/runtime/commit/c6520585b6f48d80228241320198b2efdb8e0fe5.

[ViktorHofer]

Thanks Alex. You missed removing the P2P in the test project (as it wasn't part of the targeting pack before): https://github.com/dotnet/runtime/blob/c91269cb959a78309d0fa3040ae6028cce97f86e/src/libraries/System.Runtime.InteropServices.JavaScript/tests/System.Runtime.InteropServices.JavaScript.Tests.csproj#L21-L22

[ViktorHofer]

Submitted https://github.com/dotnet/runtime/pull/40337 to clean this up. Meanwhile, this issue can be closed. Thanks all.

[steveisok]

@ViktorHofer I still think we need to change the name since it's internal.

[akoeplinger]

I wasn't aware of this issue and that this is an internal library for 5.0 so I think we'll need to remove the reference assembly again.

[safern]

I wasn't aware of this issue and that this is an internal library for 5.0 so I think we'll need to remove the reference assembly again.

We don't need to remove the ref assembly, we can make the ref to not be shipped if we want to:

https://github.com/dotnet/runtime/blob/master/src/libraries/NetCoreAppLibrary.props#L149

[ViktorHofer]

@safern Why would we keep the ref if we aren't shipping it as part of the targeting pack?

[safern]

I don't know, because we plan on making it public further down the road and to simplify the change; I guess "if we want to" wasn't clear enough to express that 😄.

I guess I was just trying to express that we have libraries where the ref is OOB and the implementation Inbox. In this case the ref is not even OOB, so if we don't need the ref for anything, removing it sounds reasonable.

[ViktorHofer]

@steveisok @akoeplinger can you please make a decision on what we should do here for 5.0? In master right now we expose a ref assembly which means the assembly isn't private atm. Should we remove the ref assembly and rename library or keep the ref and hence expose the lib?

[steveisok]

I thought I said changing it would be low risk and something we should be able to do.

To be clear, if it's internal in 5.0, we should treat it as such and rename / remove the ref.