How to add Compile Update item to csproj?

I'm trying to use Microsoft Build SDK to add a Compile Update item to the SDK style csproj file. What I need is to basically generate an XML like the following:

<Compile Update="Class1.Generated.cs">
  <DependentUpon>Class1.cs</DependentUpon>
</Compile>

However, I couldn't find an easy way to do this. If I simply use ProjectItem.SetMetadataValue, I get the following exception:

System.InvalidOperationException: 'Cannot modify an evaluated object originating in an imported file "C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.props".'

And if I try to use APIs like Project.AddItem, I have to go through this:

var item = project.AddItem("Compile", "Class1.Generated.cs", new []
{
    new KeyValuePair<string, string>("DependentUpon", "Class1.cs")
}).Single();
item.Xml.Include = null;
item.Xml.Update = "Class1.Generated.cs";

Because Project.AddItem requires an "unevaluated include".

Am I missing something? Is there a better way to do this?

[rainersigwald]

I think this is a hole in the API. @cdmihai do you recall a better option?

You can also add an element directly with project.CreateItemElement and itemGroup.AppendChild, but that might also require locating or creating an ItemGroup, which the way you described does for you, so overall that's probably easier.

[cdmihai]

This is what our unit tests do to test APIs for adding update elements: https://github.com/microsoft/msbuild/blob/890360db7e804483641ec83a281a2412e48e2c92/src/Build.OM.UnitTests/Construction/ConstructionEditing_Tests.cs#L1161-L1191

It's debatable, of course, how much more convenience APIs we should add on top of that.

There's two object models in MSBuild, one rooted in Project (with contained objects named like ProjectProperty, ProjectImport, ProjectItem) and another one rooted in ProjectElement (with contained objects named like ProjectPropertyElement, ProjectImportElement, ProjectItemElement). You can think of the ProjectRootElement visitable objects as the AST api (sort of like SyntaxNode in Roslyn), and of Project visitable objects as the AST evaluation api (sort of like Symbol in Roslyn). Both sets of hierarchies have mutator methods that end up changing the XML. ProjectRootElement mutating APIs are pretty straightforward, structural. Project mutating APIs try to get fancy and guess what would be a good looking change if the project were a .csproj project file.

Conveniency methods for item operations at the ProjectRootElement apis definately sound nice to have, as they are pretty straightforward. However, convenience methods for item operations at the Project api get super muddy, as each consumer probably has a different opinion on what a "good looking" project file means (here's what VS thinks is a good looking project file w.r.t. globs). So mutation APIs at the Project level need to be generic enough so all opinions on "good looking projects" find them useful as an implementation base, and not particular enough to spark annoyances like "but I wanted the item added in the second update from the end of the project, not the fourth update in the second itemgroup from the beginning of the project"