search

beamable / BeamableProduct

The beamable product suite including com.beamable, com.beamable.server, microservice base image, portal, the installer, and build scripts
Other
5 stars 0 forks source link

Conflicting DLL when using Beamable SDK and DevToDev in the same project #3558

Open allister-beamable opened 1 month ago

allister-beamable commented 1 month ago

Describe the bug

When Beamable 1.19.21 is in the same project with the DevToDev package from UPM, there is a conflict where both packages reference System.Runtime.CompilerServices.Unsafe.dll and Unity cannot resolve it. This prevents being able to run or build the game.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Install Beamable SDK 1.19.22 in a Unity project
  2. Install the DevToDev package in the same project
  3. Attempt to build the game

Expected behavior

Actual behavior

Metadata

Additional context

It is possible to work around the issue by manually copying one or both of the packages into the main source code under Assets/ and then deleting one of the instances of System.Runtime.CompilerServices.Unsafe.dll but leaving the other intact. However, this procedure is awkward and error prone, and is especially cumbersome to apply across many developer machines and CI/CD machines. Often build machines are treated as infrastructure-as-code and recreated from scratch every time a build is made, so it is quite problematic to have to do "manual" steps on those build machines.

cdhanna commented 1 month ago

listed package, https://docs.devtodev.com/integration/integration-of-sdk-v2/sdk-integration/unity

cdhanna commented 1 month ago

Proposed solution;

In our assets folder of the BeamableProduct/client/Assets, we should

  1. include a reference to mono.cecil https://github.com/jbevain/cecil (which is a tool that can re-write .dll files)
  2. write a script that will take a group of .dll files, rename their internal assemblies and patch their internal references to reference the renamed dll (if any).
  3. run the script, and patch any assembly definitions to use our new named .dll files (this will be a breaking change, because any existing customer stuff won't see our new thing)

Other solution,

  1. remove the dlls from our /Package
  2. add them to our own /Assets folder for testing purposes
  3. and then resolve them in the /Assets at Editor boot time when installed from UPM (this would be pre Beam static-type initializer)

OpenQuestion: would Unity use our new code if the new package introduced a compiler error? OpenQuestion: what happens if the provided dll has a version mismatch? We could check it as a pre-run step on the C#MS (assuming no catastrophic dll load issues)

Let us opt for the "other solution" and attempt a research project on it.