File linked to .NET core project gets removed from the project when the BuildAction is set to AdditionalFiles from None.

[aakash-johari]

Scenario:

1. Create a .NET core project and have a file linked to the project which has BuildAction=None.

  <ItemGroup>
    <None Include="..\abc\xyz.txt">
      <Link>xyz.txt</Link>
    </None>
  </ItemGroup>

Adding a link from Visual Studio 2017 doesn't seem to be possible. It makes a copy of the file in the project folder. So I edited the .csproj file. In our scenario we don't want to make duplicates of the file.

2. From Visual Studio, change the BuildAction to AdditionalFiles. The file disappears from the project.

ConsoleApp1.csproj

[davkean]

@mavasani We added an additional files rule right? Did we also add it to the list of items that show up in the tree (itemSchemas)?

@aakash-johari When it disappears, do you mean the solution tree? Or do you mean that it's physically removed from the project file. Can you check the project file and see if it's present?

[mavasani]

@davkean Yes, I verified additional files showed up in solution explorer after changing the build action. Let me attempt to repro @aakash-johari scenario on latest build.

[mavasani]

@davkean - you meant this file right: https://github.com/dotnet/roslyn-project-system/blob/master/src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/Rules/CSharp.ProjectItemsSchema.xaml#L13

[davkean]

Yeah, what is the that <ContentType> thing you don't have one for AdditionalFiles, and where are the other content types? Perhaps we're inheriting them from MSBuild common targets./

[mavasani]

Other content types and item types are here: https://github.com/dotnet/roslyn-project-system/blob/master/src/Microsoft.VisualStudio.ProjectSystem.Managed/ProjectSystem/Rules/ProjectItemsSchema.xaml#L61.

[davkean]

It looks like <ContentType/> refers to the ItemType - perhaps that is needed?

[mavasani]

Ok, so I investigated further and this seems unrelated to AdditionalFiles, but is instead specific to linked files.

1. This issue does not repro if xyz.txt is just a regular file in the project tree with build action None.
2. This issue repros even if step 2 is changed so the new build action is something else (content, embedded resource, etc.)

[mavasani]

So, I am seeing something weird happening here:

1. After the above repro steps, if I open the csproj on the disk, it still has the old ItemGroup with build action None.
2. If I invoke "Edit .csproj", then the item group doesn't show up in the csproj opened from the temp location.

Even clicking save all doesn't change the contents of csproj on the disk, it still has the old item group.

[aakash-johari]

@davkean Yes the file is removed from the project file and hence no longer visible in the solution tree as well. I have updated the bug description with the .csproj file I used. I opened that project file in visual studio and changed the build action of the abc.xyz to AdditionalFiles. The file abc.xyz disappeared from the solution tree and even the entry from the .csproj file was removed.

And if you think that the given .csproj file has the link entry wrong, it has been generated after following code executes in our extension -
dteProject.ProjectItems.AddFromFile(filePath);

And the file disappears after we change the type to AdditionalFiles, manually or by following code in our extension -
item.Properties.Item("ItemType").Value = “AdditionalFiles”;

[davkean]

@mavasani What's happening with this? Is this our bug or CPS?

[mavasani]

I debugged this further and it looks like a CPS issue. We have correct old and new types inside ProjectItemProviderBase.OnItemIdentityChangedAsync and also invoke SourceItemsProvider_ItemsRemoved for the old item and SourceItemsProvider_ItemsAdded for the new item, but somehow only remove seems to be working and we never add back the new project item.

[mavasani]

I have ported this issue to CPS bug 371345: Changing the BuildAction within VS for a linked file which lies outside the project cone causes the item to disappear from the project file.

[mavasani]

Also tagging @lifengl and @jviau as an FYI

[jviau]

I found the cause in CPS and am working on a fix. However, I found a bigger issue with msbuild: dotnet/msbuild#1598

Items outside the project cone are being matched to globs inside the project cone when using GetItemProvenance. This means in this case, you cannot change the build action from Content back to Compile. We will match to the **/*.cs glob, consider it included, and fail.

@cdmihai suggested a workaround for now by changing the glob to $(MSBuildProjectDirectory)/**/*.cs.

[aakash-johari]

@mavasani @jviau Is this intentional to make a copy of the linked file? Making a copy doesn't seem right. It fails the basic idea of links where using a link to a file one could update the original file.

[davkean]

@aakash-johari What's the repro for making a copy of the linked file?

[aakash-johari]

@davkean

1. Create a .NET core project.
2. Right click the project, choose "Add" and "Existing Item..."
3. Select a file that is not under the project folder.
4. You'll see a copy of the file in the folder where your .csproj file is present. i.e. your project folder.

[davkean]

That's not linking a item, that's adding a item. To link, you need to click the arrow next to the Add button and choose "add as link".

ie While surprising behavior - that's how it's worked for ~15 years.

[aakash-johari]

Oh. My bad then. :( I didn't know about "Add as link". Thanks!