Add DocumentFormat.OpenXml.Linq project

[ThomasBarnekow]

As discussed in #952 (Provide direct support for Linq to XML), this PR adds the DocumentFormat.OpenXml.Linq project with code generated by the DocumentFormat.OpenXml.CodeGeneration.Linq project. It enables code generation by also enhancing the ElementMetadata class.

I made an effort to implement the DocumentFormat.OpenXml.CodeGeneration.Linq project as a C# Source Generator. However, it turned out to be either impossible or at least too complex (and therefore not worth the effort). A C# Sourcing Generator must target netstandard2.0 and cannot depend on other projects in the same solution unless those are also analyzers. In particular, a dependency on the DocumentFormat.OpenXml project is not possible. However, that is required to generate the namespace-related classes for Linq to XML.

We'll have to discuss the following questions:

• How should we integrate the code generation performed by DocumentFormat.OpenXml.CodeGeneration.Linq into the build process? It is a console project that currently targets net5.0 and can be invoked easily.
• Which frameworks should DocumentFormat.OpenXml.Linq target? In this initial commit, it only targets netstandard2.0. Should we add net461 like other Microsoft NuGet packages targeting netstandard2.0 (which do not support any .NET framework older than 4.6.1)? Or do we have to support all the legacy frameworks that are also targeted by DocumentFormat.OpenXml?

[twsouthwick]

/azp run

[twsouthwick]

Thanks for separating this out! I'm fine not having it a source generator for now (we can play around with that after getting the main structure in.

As for what to target, best to target the same as the samples for now probably

[ThomasBarnekow]

As for what to target, best to target the same as the samples for now probably

What exactly do you mean by "samples"? I would see the following options:

1. netstandard2.0, if we only wanted to support recent .NET frameworks (net472, net48), netstandard2.0 and later, netcoreapp2.1 and later, and net5.0 and later, for example;
2. netstandard2.0;net461, to improve the developer experience for .NET frameworks 4.6.1 to 4.7.1; or
3. whatever '$(ProjectLoadStyle)' == 'All' would target as the ProductTargetFrameworks (which does not include net5.0 although it is an individual target).

[ThomasBarnekow]

@twsouthwick, could you tell me why the build failed? And do you have any further feedback?

[ThomasBarnekow]

@twsouthwick, it seems I had not pulled the most recent commits from upstream when creating the branch from main. Therefore, the reason for the failed check was a failed unit test that was unrelated to this PR.

I pulled from upstream and rebased my PR branch. At least on my local machine, all unit tests now pass. So please run the check again.

[twsouthwick]

/azp run

[ThomasBarnekow]

@twsouthwick, why did this check fail?

[ThomasBarnekow]

Just to be sure, I checked again, running the following on my local machine for both the Debug and Release configurations:

set ProjectLoadStyle=All
dotnet build --configuration [Debug|Release]
dotnet test --configuration [Debug|Release]

For both Debug and Release, it builds without any warnings or errors and all unit tests pass.

Is there any other check performed on the build server beyond what we can check on our machines? Would it be possible to get access to the build server outputs at least? Not knowing why stuff fails is a bit unsatisfying.

[ThomasBarnekow]

@twsouthwick, do you have any feedback on my questions above? Firstly:

What exactly do you mean by "samples"? I would see the following options:

1. netstandard2.0, if we only wanted to support recent .NET frameworks (net472, net48), netstandard2.0 and later, netcoreapp2.1 and later, and net5.0 and later, for example;
2. netstandard2.0;net461, to improve the developer experience for .NET frameworks 4.6.1 to 4.7.1; or
3. whatever '$(ProjectLoadStyle)' == 'All' would target as the ProductTargetFrameworks (which does not include net5.0 although it is an individual target).

Secondly, why did the check fail?

Just to be sure, I checked again, running the following on my local machine for both the Debug and Release configurations:

set ProjectLoadStyle=All
dotnet build --configuration [Debug|Release]
dotnet test --configuration [Debug|Release]

For both Debug and Release, it builds without any warnings or errors and all unit tests pass.

Is there any other check performed on the build server beyond what we can check on our machines? Would it be possible to get access to the build server outputs at least? Not knowing why stuff fails is a bit unsatisfying.

[twsouthwick]

Sorry for the slow responses - between some busy projects and vacations, I've had little time to review here.

This is shaping up fine and once we get the 2.13.1 release out (hopefully today), we can then get these merged in.

Let's not worry about the code generation at this point and leave what you have in. After that, I have some ideas as to how to make the code generators work, but what you're doing now is fine.

[ThomasBarnekow]

Thanks, Taylor. I've added a commit that changes the .csproj file so that we are targeting the $(ProductTargetFrameworks). I've built and tested on my machine with ProjectLoadStyle=All.

[twsouthwick]

/azp run

[ThomasBarnekow]

@twsouthwick, please run the checks to see whether it works. It builds successfully on my machine with set ProjectLoadStyle=All. As I said above, it targets whatever is in $(SamplesFrameworks), i.e., net46, netcoreapp2.1, netcoreapp3.1, and net5.0 at the moment.

I've noted that the unit tests target net452 and all of the above. However, while the product does not target net452, it targets net35 and net40 on top of net46 (plus netstandard1.3 and netstandard2.0). Can you explain why net35´ and net40are required? Why can't the SDK not simply targetnetstandard2.0andnet461like several other Microsoft libraries? Another observation is that it targetsnet5.0by default, which is however not included in the$(ProductTargetFrameworks)whenProjectLoadStyleis set toAll`.

[twsouthwick]

I'll try to answer all the questions:

• A number of people use .NET 3.5 and .NET 4.0 for things like sharepoint integrations. Since these are still supported, I keep the targets around
• A common misconception is that it's unsupported to compile an application targeting .NET 4.0 and run it on .NET 4.8. That's supported and does potentially opt you into various quirks that are required by some systems
• .NET 5.0 target is there so we can start experimenting with things like Span<> but haven't decided to pull the trigger with that TFM yet

[twsouthwick]

/azp run

[twsouthwick]

I pushed a change that should work - it will only compile for .NET 5.0, but on the other sample projects, it will just output a message saying it is unsupported on that target.

Long term we can hopefully streamline this, but the build matrix on the server is done so that we can run tests against the .NET 3.5 builds.

[twsouthwick]

/azp run