Enabling SourceLink allows VS debuggers to download source files based on commit information and symbols embedded in published binaries (reference). It essentially allows debuggers to further inspect calls within the MTGOSDK library.

For our purposes, it is preferred to distribute separate .snupkg PDBs so that debuggers can download symbols directly from NuGet, and avoid bundling additional resources into the ScubaDiver assembly (which consumes MTGOSDK.Core).

To avoid re-distributing MTGO assemblies, this project should make use of reference assemblies built against the latest ClickOnce deployment URLs for MTGO (or pulled from the client install path).

I'm unsure of whether to distribute these reference assemblies as a package, or just to leave it as an internal library used by the SDK. The latter case may be all that is needed to be done.

To maintain parity between the dotnet CLI and Visual Studio environment, any codegen tasks should be run with the below MSBuild targets:

<!--
  Runs before Restore and Compile targets for dotnet CLI and Visual Studio.
  Refer to https://github.com/NuGet/Home/issues/4781 for more info.
-->
<Target Name="PreBuild" BeforeTargets="_GenerateRestoreProjectSpec;CollectPackageReferences;Restore;Compile">
    ...
</Target>

Using gRPC should allow for better interop between languages and the host/client processes with support for bidirectional streaming, flow control, and comparatively better error handling. This will upgrade communication to HTTP/2 and require additional codegen for supporting protocol buffers.

Microsoft has a tutorial here explaining how to support this with existing C#/MSBuild projects, though this may be a better migration path for #2.

The WindowsProcessDataReader's dispose method attempts to kill the snapshot process without waiting for process exit. As a result, a Win32Exception is thrown (as we don't have the correct privileges to force an exit without yielding first) which will repeatedly spam any subscribed Trace listeners (as a Trace.Write is called internally).

This seems to be called when invoking either the DataTarget.Dispose() or ClrRuntime.Dispose() methods. You can observe this behavior in Loupe Desktop when injecting RemoteNET into the MTGO client, which will trace this error on Diver startup and when pinning objects, etc.

Unfortunately, we can't (and shouldn't) unsubscribe Trace listeners as this may negatively affect Gibraltar logging on the MTGO client, which makes extensive use of Trace.Write calls to inform state changes.

This is a regression from microsoft/clrmd#926 that we'll need to work around by reimplementing the dispose method w/ the use of reflection.

Postfix/finalizer patches must have a return type of void or the return signature must match the type of the first parameter (passthrough mode) return types.

Refer to pardeike/Harmony#130 (comment) for a simpler overview of the HarmonyLib's patching methods.

A consequence of the .csproj level approach used in ee5bc14 is breaking incremental builds when RemoteNET project dependencies are updated.

Additionally, MSBuild does not respect building these dependencies before running pre-build targets, which deviates from the behavior expected within Visual Studio.

It may be best to change RemoteNET's pre-build target to 'pre-compile instead, though resolving the former issue seems unclear.

The current SDK is only set up for users to build against a clone of the project. This is mostly due to unresolved questions on how/whether to distribute reference assemblies generated by the MTGOSDK.Ref project, which are required runtime dependencies by the main MTGOSDK library (for reflection).

Only the MTGOSDK and MTGOSDK.Win32 libraries would need to be published to NuGet, requiring an additional pipeline for packaging the built reference assemblies.

This also requires additional infrastructure for supporting publishing and building the SDK through .NET Core.

ClrMd calls PssCaptureSnapshot to create a 'copy-on-write' clone of the MTGO client's process memory, creating a new snapshot process. This creates a clone of the process's virtual address space, sharing the same physical memory pages until any page is modified. Essentially, if the client process attempts to modify one of these pages, it instead modifies a new page with a clone of the original page contents.

It's worth noting that the process is frozen for the duration of the call to PssCaptureSnapshot, so no page-ins can occur until the snapshot has been created. However, changes made while the snapshot is still active will incur overhead from these new page-ins. After the snapshot is disposed of, no further page-ins will be made, as there exist no more references from the snapshot process (as it is now exclusively owned by the MTGO process).

Therefore, the optimization path for reducing the window that these snapshots take is twofold:

1. Avoid performance penalties from new page-ins for the snapshot's lifecycle.
2. Avoid maintaining stale copies of the object heap that may reference changed or non-existent memory locations.

Memory fragmentation in the MTGO process (irrespective of any behaviors caused by this snapshot) may trigger GC cycles that touch and cause page-ins even if there was no actual modification of data. At the same time, any unused pages of memory left over from copy-on-write modifications also need to be garbage collected, consuming additional CPU cycles.

This leaves a third optimization path to investigate with GC, which is further exacerbated by the memory handling of the MTGO process. This may require a custom GC mechanism to control/hide shared regions of memory created by the snapshot to reduce redundant copying.

Use Sigstore to sign build artifacts generated in CI, providing provenance for release artifacts and runtime assets. This is essentially a tamper-proof way of verifying that an artifact was actually built in our CI to verify it's identity. This is now available in GitHub Actions through a public beta of artifact attestations.

This isn't compatible with the Windows trust store for Authenticode, so we'll have to look into purchasing an EV certificate or using an OV certificate from SignPath. We'll have to wait and see whether GitHub is planning on offering a signed timestamp for Authenticode compatibility. Until then, we'll need to submit samples to Microsoft in order to gain reputation for SmartScreen (reference).

Within the MTGOSDK.Ref project, a new target should include the built reference assemblies for consumption through the library (without needing explicit references for each DLL):

<!-- Packaging assemblies for NuGet publishing -->
<ItemGroup>
  <Content Include="$(_MTGOSDK_Refs)\*.dll">
    <Pack>true</Pack>
    <PackagePath>lib\$(TargetFramework)</PackagePath>
  </Content>
</ItemGroup>

<!-- Importing MTGOSDK.Ref in a consuming project -->
<PackageReference Include="VidereProject.MTGOSDK.Ref"
                  Version="1.0.0" />

Versus the current setup, which requires bootstrapping the MTGOSDK.Ref project with MTGOSDK.MSBuild (internal project):

<!--
  Bootstrap the MTGOSDK.Ref project to generate reference assemblies for
  the current MTGO version. Due to the way that MSBuild works, this must
  import the MTGOSDK.MSBuild.props file before referencing the project.
-->
<Import Project="..\MTGOSDK.MSBuild\build\MTGOSDK.MSBuild.props" />
<PropertyGroup>
  <MTGOSDK_Refs>$(_MTGOSDK_Refs)\3.4.*.*</MTGOSDK_Refs>
</PropertyGroup>
<ItemGroup>
  <ProjectReference Include="..\MTGOSDK.Ref\MTGOSDK.Ref.csproj"
                    ReferenceOutputAssembly="false" />
  <!--
    Include reference assemblies to compile against the current MTGO version.
    Note that the '_MTGOSDK_Refs' path does not reference the updated version
    subpath as it is only evaluated after building the MTGOSDK.Ref project.
  -->
  <Reference Include="$(MTGOSDK_Refs)\Core.dll" />
  <Reference Include="$(MTGOSDK_Refs)\FlsClient.dll" />
  <Reference Include="$(MTGOSDK_Refs)\MTGOEnumStruct.dll" />
  <Reference Include="$(MTGOSDK_Refs)\WotC.MtGO.Client.Common.dll" />
  <Reference Include="$(MTGOSDK_Refs)\WotC.MtGO.Client.Model.Chat.dll" />
  <Reference Include="$(MTGOSDK_Refs)\WotC.MtGO.Client.Model.Core.dll" />
  <Reference Include="$(MTGOSDK_Refs)\WotC.MtGO.Client.Model.Reference.dll" />
</ItemGroup>