I’m currently working on using Unity as a Library and embedding it in a WPF project, but have run into inconsistent behavior between versions. The goal is to embed it with the existing project, and not call it as a separate process. The initial testing performed with Unity 2023.3.3f1 works find, with both the DLL and running unity as a separate process. When I upgraded to Unity 6 (6000.024f1 and 6000.027f1) the separate process configuration still worked, but the DLL implementation is currently throwing an access violation after calling UnityMain(). I added in additional symbols and the last item on the call stack that’s now showing up is UnityPlayer.dll!FixupD3D12SDKPath().
- Other approach I’ve tried include:
- Building Unity with .Net Framework
- Building Unity with .Net Standard
- Building Il2cpp (this gives a different error so I’m focusing on the .Net builds)
- Forcing D3D11 (-force-d3d11) since the call stack gives the impression that there may be an issue with D3D12.
- Built unity with only D3D11 support
- Compiling WPF with VS2022 (Originally used VS2019)
- Various permutations of the DllImport
Did something change between 2023 and version 6 which would impact Unity as a Library being used as a DLL?