EditorFeatures.Text IVTs for MonoDevelop

[sandyarmstrong]

Since #30868, ContentTypeNames
has moved to this assembly. Type forwarding doesn't seem to work for
IVT.

[sandyarmstrong]

@Therzok

[sharwell]

@sandyarmstrong Can you confirm that prior to #30868, you were already referencing ContentTypeNames at its original location via IVTs?

[Therzok]

Yup: http://source.monodevelop.com/#MonoDevelop.CSharpBinding/MonoDevelop.Ide.Completion.Presentation/RoslynCompletionPresenter.cs,30

Clicking ContentTypeNames redirects to a (broken) roslyn page, but it's coming from roslyn EditorFeatures!

[sandyarmstrong]

@sharwell As Marius says, yes, it's already being used. Not hard to work around, but it would be great to get this change in 2.11 so we can avoid any other unexpected surprises.

[sharwell]

Approving on the basis that this is a grandfathered IVT (new IVTs aren't being allowed at this time). The original IVTs (which remain in place) are here:

roslyn/src/EditorFeatures/Core/Microsoft.CodeAnalysis.EditorFeatures.csproj

Lines 64 to 72 in 7f63622

	<InternalsVisibleTo Include="MonoDevelop.Ide" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.Refactoring" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.CSharpBinding" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.VBNetBinding" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.Ide.Tests" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.Refactoring.Tests" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.CSharpBinding.Tests" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="MonoDevelop.VBNetBinding.Tests" Key="$(MonoDevelopKey)" />
	<InternalsVisibleTo Include="Roslyn.InteractiveWindow.UnitTests" Key="$(MonoDevelopKey)" />

[jasonmalinowski]

Do we not have a public constant anywhere you can use for this?

[sandyarmstrong]

@jasonmalinowski no, I don't see any other constant for "Roslyn Languages".

There are like 20 IVTs for this assembly for VSwin so I don't see why there are concerns about doing the same for VSmac?

[jasonmalinowski]

@sandyarmstrong We're taking a new battle against IVTs; I'm had thought we had exposed these somewhere and wanted to make sure we did that before opening up more IVT.

Given that those constants won't change, should we just have you hard code them? 😄

[jasonmalinowski]

Approving since I agree with @sharwell this isn't really making things worse, and that assembly is rarely (if ever) changed at this point.

[jaredpar]

Retriggering on latest.

[sandyarmstrong]

@jaredpar Any idea about roslyn-integration-CI test failures?

[sandyarmstrong]

@jaredpar looks like I'm not the only PR with roslyn-integration-CI failures (#31993, which merged recently, had the same errors).

[jaredpar]

@sandyarmstrong the roslyn-integration-CI leg is not required at this time (largely due to relability issues). If that one fails it's typically okay. The @dotnet/roslyn-ide team can push back in cases where they think the failure is real.

[sandyarmstrong]

@sharwell thanks! Is it possible to get this into 2.11? If so, do I need to submit another PR to another branch (I'm guessing dev16.0.x)?