Code fixes that impact additional files of custom item types no longer work

[jasonmalinowski]

Repro Steps

1. Open Roslyn.sln, and add a public API somewhere in the CodeAnalysis.csproj project that triggers the PublicAPI checker.
2. Ctrl+.. Observe the suggestion from the code fix.
3. Apply it.

Expected: it works
Actual: it does nothing

Debugging on the Roslyn side of things, we are telling the RDT to save the item, but it bails because there is no hierarchy there:

    if (((grfSave & RDTSAVEOPT_SaveAllButThis) == 0) && docCookie)
    {
        // cant save a doc anything w/o a hierarchy
        if (NULL == info.spHier)
            return NOERROR;

Roslyn, when it opened the invisible editor, passes null for RegisterInvisibleEditor, which is documented that in this case it'll use whatever project "claims" the file. But if you look into the solution explorer, you'll see that PublicAPI.*.txt files aren't listed, and whatever data source drives that decision is also saying the project doesn't own the file for the purposes of the invisible editor. If you edit the project to change the item type to AdditionalFiles instead of PublicAPI, they now appear and code actions apply just fine.

The old project system was (to a fault) aggressive in counting unknown item group types as something to be "included" in the project; it seems the new project system is changing that behavior. The additional files with the PublicAPI item type do work otherwise in the IDE, as we do tell the compiler to consume them and they're coming through with the design time build.

There is an interesting question of whether Roslyn passing null for the IVsProject property is "bad" (we might have one we can figure out), but it seems this is a regression in behavior at a few potential levels which might have other impacts -- any other callers are broken and the IsDocumentInAProject API is observing different behavior.

[davkean]

@jasonmalinowski Interesting. From a standpoint of both legacy and CPS project systems, items that come through design-time builds are not considered part of the project/tree.

What's relevant here though, is that the legacy project system will treat any (visible) item in the project file as part of the tree - whereas, CPS doesn't. Only those item types that have been registered to show up the tree, show up in the tree, hence the behavior you are seeing.

@lifengl @jviau What are you thoughts on this? This is going to be compat thing with the legacy project system, very similar to the AvailableItemName - where we'll want to add item types without a ItemType registeration.

[jasonmalinowski]

@davkean Is there any workaround for now I can check in to say those should be counted as registered?

[davkean]

The workaround would be to mark them as AdditionalFiles or None or Content, or (harder) you could add your own registration, similar to:
https://github.com/dotnet/project-system/blob/master/src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/Rules/CSharp.ProjectItemsSchema.xaml#L12 and then register it like so: https://github.com/dotnet/project-system/blob/master/src/Targets/Microsoft.CSharp.DesignTime.targets#L26.

[davkean]

Note it turns out that ShowMissingItemTypes capability already controls whether these show up in the tree.

[davkean]

I looked into ShowMissingItemTypes capability which will prevent the ever growing additional of items that we need to keep adding. This will implement legacy project system-like behavior where unknown items types in the project will show up and have the same properties as item type.

However, it's not yet ready for us to consume:

It won’t show items directly in the project when there is an item for that item type that comes from props/targets. I can see this resulting in confusing behavior; all your items show up in project, then you add a single common one in Directory.Build.props and then they disappear from projects.

It will currently shows PackageReference/ProjectReference/Reference also in the project. We can’t do an ItemDefinitionGroup with Visible false for these as we respect it for some of them in the Dependencies tree, such as Reference.

Reached out to CPS to see what we can do about this.

We'll turn this on for 15.8.