sentry-unity icon indicating copy to clipboard operation
sentry-unity copied to clipboard

New dev loop: Run Alias tool after .NET builds

Open bruno-garcia opened this issue 4 years ago • 2 comments
trafficstars

Goals

  1. dotnet build will create package-dev with alias'ed assemblies. So Unity Tests and players are built in dev mode using the assemblies as we'll package them.
  2. dotnet clean will remove the aliased assemblies so dev loop stays productive: dotnet clean -> dotnet build rebuilds .NET assmeblies
  3. dotnet clean will not remove native plugins. To clean those it'll require explicitly calling dotnet msbuild /t:CleanAndroid

Additional context and goals

Currently each csproj has its build output set to either package-dev/Runtime or package-dev/Editor. Dependant assemblies are copied over to output (as can be seeing in the UPM package: https://github.com/getsentry/unity/tree/main/Runtime ), resulting in shim dlls also being copied there after build. This causes conflicts which are being tackled through #300.

In order to accommodate the Assembly Alias process, we need to modify the projects to no longer output DLls straight into package-dev. Instead, they should build to a temp directory that can be added to .gitignore. A after.Sentry.Unity.sln.targets or similar approach can have a task that will run once the whole solution completes building, and trigger the Alias tool on this temp directory. The alias'ed DLLs can then be copied to package-dev.

Additionally, we need to make sure dotnet clean removes those DLLs from package-dev and the temp intermediate folder. So we can then rebuild the DLLs and re-alias them.

bruno-garcia avatar Nov 10 '21 19:11 bruno-garcia

Until this is resolved, a work around to avoid dupe DLL in the package: #429

Please revert that once this is resolved

bruno-garcia avatar Nov 23 '21 16:11 bruno-garcia

Marked as Impact: Small since we've had the aliasing now in CI and Integration Test validating the package is available (thought not in main yet). Before that it was higher because we had no way to validate the alias'ed DLLs actually worked. This is still impactful to run our Edit and Play tests using the aliased DLLs

bruno-garcia avatar Dec 21 '21 16:12 bruno-garcia