Closed Qonfused closed 9 months ago
The most obvious option for generating these reference assemblies would be Refasmer from JetBrains.
For supporting #2, it can be vendored and configured as a toolchain similarly to Selenium's config for ILMerge.
The pipeline has been published with https://github.com/videre-project/mtgo-sdk/commit/66395968c6dc92f573e5add80dbd4cadb3ff20de. What's leftover is bundling the generated reference assemblies as part of the MTGOSDK.Ref package.
Currently (as of https://github.com/videre-project/mtgo-sdk/commit/752bafc33c94e078dd500b9a9ccad4d27eb8f3d8), builds must be triggered before compilation/after restore. This handles bundling for MTGOSDK.Ref but may require multiple builds due to how late tasks fire w/ msbuild (non-issue after nuget packaging/distribution).
The ideal solution is to stick to generating reference assemblies on the restore target(s), but it's unclear how to force a build of the msbuild task then.
This would be a workaround if simply copying assemblies after build allowed consuming projects to import them. This also has a side-effect of preventing MTGOSDK.Ref from referencing these assemblies at compile-time.
- <!-- Import all MTGO reference assemblies generated from MTGOSDK.MSBuild -->
- <ItemGroup>
- <Reference Include="$(_MTGOSDK_Refs)\3.4.*.*\*.*" />
- </ItemGroup>
+ <!-- Export all MTGO reference assemblies generated from MTGOSDK.MSBuild -->
+ <Target Name="CopyCustomContent"
+ AfterTargets="AfterBuild"
+ DependsOnTargets="GenerateReferenceAssemblies">
+ <ItemGroup>
+ <MTGOSDK_Refs Include="$(_MTGOSDK_Refs)\*.*" />
+ </ItemGroup>
+ <Copy SourceFiles="@(MTGOSDK_Refs)"
+ DestinationFolder="$(OutDir)"
+ SkipUnchangedFiles="true" />
+ <Message Text="MTGOSDK.Ref: Copied reference assemblies to $(OutDir)"
+ Importance="high" />
+ </Target>
This is unfortunately not addressable with MSBuild, and will only be fixed following a migration to Bazel (#2).
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: