System.ComponentModel.Composition is missing a typeforward for Lazy<T,TMetadata>

[ericstj]

@joperezr and I noticed this when having a discussion.

System.ComponentModel.Composition reference assembly is missing a type-forward for System.Lazy<T, TMetadata>.

As a result, when you use a .NET assembly which makes use of this type and reference System.ComponentModel.Composition, you will see a compile error.

Error	CS0012	The type 'Lazy<,>' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ComponentModel.Composition, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

See attached sample.
LazySample.zip

We should fix this by added the typeforward to the ref.

This also raises the question of "what goes in netcoreapp2.1"? We can't remove System.ComponentModel.Composition.dll since that will be a breaking change. It was present in 2.0 in order to typeforward this one type to System.Runtime. Should we include all of MEF? /cc @weshaggard @danmosemsft

[danmoseley]

Ah, I see it was removed from shims\netfxreference.props when we ported it for real (6bac408)

It seems to me we either

1. have a breaking change (user must add package reference) or
2. include all of MEF in netcoreapp or
3. rename our ported assembly to something with a different name.

Does 3 make most sense? This is what we did with most of our ports. It means yet another facade but one we apparenlty already had.

@weshaggard ?

[joperezr]

mm I think that the easiest thing to do is to just add a type forward on the ref so that we type forward System.Lazy`2 down to System.Runtime. We already do that for the implementation, so doing it for the ref would fix this issue since that was the only type we shipped on nc2.0's contract.

[danmoseley]

Ah, I didn't realize we already moved System.Lazy<,> down to System.Runtime. In that case then if that's the only missing type that seems like the easiest solution.

How is that achieved? Add to ref for S.C.Composition, add a netcoreapp configuration for that ref, indicate it's a partial facade for netcoreapp, add a project ref for S.R when netcoreapp?

[joperezr]

no, simply adding something like:

[assembly:System.Runtime.CompilerServices.TypeForwardedTo(typeof(System.Lazy<T, TMetadata>))]

into our System.ComponentModel.Composition.cs file and removing the actual definition for it from there should be good enough.

[danmoseley]

@ericstj if that sounds reasonable then I can do it. I verified this is the only type forward we shipped inthat assembly.

[weshaggard]

have a breaking change (user must add package reference)

When we did this work we new about the potential breaking change and decided to go with your option (1) which is to have users that hit it add the package reference. If we find it to be too large of an issue we can move it into the shared framework at a later point.

We should definitely fix the type-forward in the ref as @joperezr suggests. It seems like we have a hole in our apicompat checks as well because this should be caught in someway. I guess we don't currently have checks on our refs that but only on the src projects.

[danmoseley]

@maryamariyan could you please add the type forward to the ref\S.CM.Composition.cs file as described by @joperezr above?

@weshaggard is that something you could look at, the apicompat check? I wonder if we have missed anything else.

[ericstj]

@ericstj if that sounds reasonable then I can do it. I verified this is the only type forward we shipped inthat assembly.

Yes, that's reasonable and exactly what I meant when I said

We should fix this by added the typeforward to the ref.

It sounds like @weshaggard has already made the call on allowing the breaking change. That's ok, but we should probably rel-note that so that folks who are broken know what to do.

[danmoseley]

@leecow where do we record items for 2.1 rel notes?

[joperezr]

It seems like we have a hole in our apicompat checks as well because this should be caught in someway.

@weshaggard actually by looking at the PR that added the library seems like the apicompat did catch this, but @maryamariyan changed the package index by removing netstandard2.0 from the InboxOn information in order to get this building which we didn't catch at the time of the review.