You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
<!-- Importing MTGOSDK.Ref in a consuming project -->
<PackageReferenceInclude="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.-->
<ImportProject="..\MTGOSDK.MSBuild\build\MTGOSDK.MSBuild.props" />
<PropertyGroup>
<MTGOSDK_Refs>$(_MTGOSDK_Refs)\3.4.*.*</MTGOSDK_Refs>
</PropertyGroup>
<ItemGroup>
<ProjectReferenceInclude="..\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.-->
<ReferenceInclude="$(MTGOSDK_Refs)\Core.dll" />
<ReferenceInclude="$(MTGOSDK_Refs)\FlsClient.dll" />
<ReferenceInclude="$(MTGOSDK_Refs)\MTGOEnumStruct.dll" />
<ReferenceInclude="$(MTGOSDK_Refs)\WotC.MtGO.Client.Common.dll" />
<ReferenceInclude="$(MTGOSDK_Refs)\WotC.MtGO.Client.Model.Chat.dll" />
<ReferenceInclude="$(MTGOSDK_Refs)\WotC.MtGO.Client.Model.Core.dll" />
<ReferenceInclude="$(MTGOSDK_Refs)\WotC.MtGO.Client.Model.Reference.dll" />
</ItemGroup>
The text was updated successfully, but these errors were encountered:
Should look into packaging properties/targets under a buildTransitive folder in the NuGet package (reference).
Bootstrapping MTGO reference assembly generation at project reference and including the directory paths dynamically would avoid needing to publish the reference assemblies in the package. Instead, they can be generated at restore/build-time.
Below is an example of how this can be used in the MTGOSDK library (as well as in consumer applications):
<ItemGroup>
<!-- Import the MTGOSDK.Ref project to generate reference assemblies for the current MTGO version. Consumers of MTGOSDK should not need to reference this project directly as it is imported transitively.-->
<ProjectReferenceInclude="..\MTGOSDK.Ref\MTGOSDK.Ref.csproj"ReferenceOutputAssembly="false" />
<!-- Include reference assemblies to compile against the current MTGO version.-->
<ReferenceInclude="Core" />
<ReferenceInclude="FlsClient" />
<ReferenceInclude="MTGOEnumStruct" />
<ReferenceInclude="WotC.MtGO.Client.Common" />
<ReferenceInclude="WotC.MtGO.Client.Model.Chat" />
<ReferenceInclude="WotC.MtGO.Client.Model.Core" />
<ReferenceInclude="WotC.MtGO.Client.Model.Reference" />
</ItemGroup>
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):
Versus the current setup, which requires bootstrapping the MTGOSDK.Ref project with MTGOSDK.MSBuild (internal project):
The text was updated successfully, but these errors were encountered: