@jkoritzinsky it would be great to have an initial feedback on the PR. Actual review is not needed, but I am interested in upstreaming these changes and I need confirmation they're worth upstreaming.

Everything here seems like a good idea to me.

There are some issues with CodeCov token. Doesn't matter for this PR, but in general.
I'm preparing individual feature PRs now.

@jkoritzinsky the only issue left is everything coverage-related, reproducible only on AzDO:

• coverlet not finding modules, thus 0 coverage output
• Wrong codecov token

Running build.ps1 and test.ps1 locally works fully (coverage reported correctly). The whole coverage situation in .NET world seems extremely fragile at the moment. No proper report merging, known deficiencies in AzDO publish coverage task, coverlet team still working on v2 tool spec. I'd say it's not worth the trouble.

I'll split this PR tomorrow into:

1. Infra + TFM/RID-agnostic Runtime PR
2. Relations PR
3. The rest

I'd be fine dropping code-coverage checking for a while. It was primarily important when I was doing full rewrites of the C# code generator to make sure I got all the special cases. If it's working locally though, I'd prefer to move the code coverage handling under a switch so that I can still use it locally when changing marshalling. It's fine if we turn it off in CI. I'll go disable the check.

Those 3 PRs sound like a great way to split this. Thanks for your contributions! I really appreciate it!

Once #165 is merged, I'll rebase this and split into multiple PRs.

I've rebased everything I had on the latest master, and committed everything I have on the refactored SharpGen pipeline. This is still WIP:

1. New MicrosoftDocs extension tests don't work, contain excessive code
2. Typo in Sdk.targets
3. New non-MIT code not taken care of
4. There are many improvements that could be done to MicrosoftDocs results (cleaning up formatting, autolinking), some were present in MSDN provider, some are more QoL features to have
5. Clean up this PR (I even pushed binlogs here by accident)

Of course upstreaming this will take a long time (splitting this into chunks — nightmare).

There is a new code here taken from 3rd party projects:

1. ObservableHashSet<T> from Entity Framework Core, Apache 2.0 with plans to move to MIT, but no actual effort for now. Used in DocItem and DocSubItem in the SDK.
2. Bits of HTML renderer for Markdig, BSD 2-Clause. Used in MicrosoftDocs extension.

Both have MIT-compatible non-copyleft licenses, but this still needs to be taken care of:

1. Add proper attribution in this project's COPYING file
2. Strip Markdig code a bit more

I'm thinking my 3rd PR (RotS) will contain a lot of refactorings, except for the main one (merging tasks into one). I'll try to put it together tomorrow.

Some progress (not pushed to remote):

1. Cleaned up this branch
2. MicrosoftDocs tests compile and produce satisfactory results
3. Dropped Apache2-licensed ObservableHashSet<T>, by replacing it with ObservableCollection-derived class with HashSet to keep uniqueness. As a bonus — guaranteed to preserve insertion order.
4. Extended SharpGen.Runtime.PlatformDetection to provide OSVersion and IsInAppContainer (.NET Standard 1.1 was the tricky part)
5. Partially moved ComUtilities from SharpGen.Runtime.COM to SharpGen.Runtime, renamed to ComActivationHelpers, merged changes made by @amerkoleci (runtime detection instead of #ifs)
6. Well-documented ComContext enum, synchronized with latest Windows SDK IDL files and Microsoft Docs reference

To-do before I can call it a win:

1. Do some actual testing in MicrosoftDocs SDK test
2. Skip MicrosoftDocs SDK test on Unix platforms (Windows Animation Manager is obviously Windows-only)

ComActivationHelpers are more low-level than ComUtilities in the sense that they return Result, instead of bool or CheckError+void. They also provide means to invoke specific code path (AppContainer or not), if heuristic is incorrect/insufficient.

Sadly, I can't drop BSD-licensed code, I'm afraid it will have to be taken into account when merged into SharpGen v2 master branch.

I still haven't prepared the next PR. :(

• Brought back the ability to use SharpGen SDK as PackageReference, not as a MSBuild SDK. It blocks implicit SharpGen.Runtime PackageReference and SharpGenExtensionReference shortcut for PackageReference with PrivateAssets=all, but allows workaround for MSBuild SDKs version property is not expanded dotnet/msbuild#5349 (btw, my MSBuild PR still hasn't even been looked at).
• Added simple Windows Animation Manager test in MicrosoftDocs SDK test (tests binding, not the docs, since those would require more work)
• Windows Animation Manager test is skipped on non-Windows platforms

Done for now. I still haven't prepared the next PR, and I won't be able do that until the mid-July. :(

In my local branch I have a partially complete implementation of C# 9.0 function pointers codegen.

The updated Microsoft Docs doc provider was previously in this repo, but I've moved it back into its own repo, private for now until we get the extensibility working.

Published IMarshaller refactoring (moved many methods to ICallableMarshaller), merged SharpPatch into SDK (+removed useless CLI), implemented calli via function pointers (C# 9.0+) and a fallback method to enable disallowing assembly patching and function pointers (via Marshal.GetDelegateForFunctionPointer, slow and has a known issue). Also greatly refactored tests, now they test both x64 and x86 (previously - only x64), fixed multiple issues around x86 support (master branch is really broken with x86), one known issue remains (BoolArrayMember).

Per discussion in #173, dropped delegates & assembly patching impl. Only fnptrs impl remains. I'll investigate if major IMarshaller refactoring is still needed.

Okay, I've successfully reverted a lot of changes (including splitting IMarshaller and adding new method to it).