Firstly, I don’t think the issues I experienced are the same as you, since these issues gave macOS error messages on double click of the app, where what you describe was a crash when displaying the splash screen.
Some googling revealed a plausible explanation for the access denied issue I encountered, simply due to zipping the .app as seen on Stackoverflow.
The developer unknown issue will be due to you building your app locally without the proper app signing / notarization for distribution, for reference I ignored this by going into macOS Settings → Security and Privacy and allowing execution of the untrusted application.
Can you confirm unzipping the app you sent me still causes the crash on your end?
If so, what version of macOS are you running?
Thank you so much for providing your .app, I was able to reproduce the issue here on my Mac. So the problem is actually due to a codesign validity check triggered because the FMOD bundle has been tampered with. The tampering is the line endings for the Info.plist file contained within fmodstudio.bundle and fmodstudioL.bundle. I was able to quickly fix it here by installing dos2unix via homebrew and running it on the file.
We ship the Info.plist files with Unix style line endings as is the norm on macOS, so I suspect the endings got flipped by your source control, possibly due to wrong settings, or possibly checking the file out on Windows, copying it to a Mac, then checking it in on the Mac.
Reinstalling is one method, in practice you just need to update the Info.plist files, but unpacking the Unity package to get the correct ones is not always straight forward, so reapplying the whole thing can be easier. If you have homebrew set up, then install dos2unix and run it on each of the Info.plist files to fix them is another option, there are other ways to swap line endings but that was the quickest I found to test here.
I deleted the whole FMOD folder and reinstalled it, now I’m getting ArgumentException: An item with the same key has already been added. Key: StandaloneWindows when saving the unity project…
Editor log:
ArgumentException: An item with the same key has already been added. Key: StandaloneWindows
at System.Collections.Generic.Dictionary`2[TKey,TValue].TryInsert (TKey key, TValue value, System.Collections.Generic.InsertionBehavior behavior) [0x000c1] in <fb001e01371b4adca20013e0ac763896>:0
at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (TKey key, TValue value) [0x00000] in <fb001e01371b4adca20013e0ac763896>:0
at FMODUnity.Settings.DeclareBuildTarget (UnityEditor.BuildTarget buildTarget, FMODUnity.Platform platform) [0x00001] in D:\Github\TOEM\Assets\Plugins\FMOD\src\Runtime\Settings.cs:390
at FMODUnity.PlatformWindows.DeclareUnityMappings (FMODUnity.Settings settings) [0x00028] in D:\Github\TOEM\Assets\Plugins\FMOD\platforms\win\src\PlatformWindows.cs:52
at FMODUnity.Settings.LinkPlatform (FMODUnity.Platform platform) [0x00009] in D:\Github\TOEM\Assets\Plugins\FMOD\src\Runtime\Settings.cs:384
at FMODUnity.Settings.ForEachPlatform (System.Action`1[T] action) [0x00019] in D:\Github\TOEM\Assets\Plugins\FMOD\src\Runtime\Settings.cs:320
at FMODUnity.Settings.OnEnable () [0x0013c] in D:\Github\TOEM\Assets\Plugins\FMOD\src\Runtime\Settings.cs:883
UPDATE:
I reimported everything once again and this error didn’t appear again.
So reinstalling the unity integration did not fix anything. I quit unity, deleted FMOD, reimported everything, added the FMOD plugin, reimported again, and restarted to make sure all .dlls were updated and everything.
It did not solve the issue. Our team members are using macOS Catalin 10. and big Sur.
Here’s the new Editor.log after my reinstallation, seems like the same issue persists. message.txt (30.1 KB)
Completely removing FMOD and installing again should work, I’ve just tested again locally importing 2.01.08 into an empty Unity project. Just to confirm it is indeed the line ending issue, can you open a terminal and type the following:
The -N in the above will ensure no file endings are swapped on open, if you have incorrect line endings you will see ^M on the end of every line. If you do see this I’m super curious how that’s happening, I’m assuming you are simply running the asset package on your Mac and importing it into your project?
After digging further it only seems to be a problem when I’m building the macOS using our build server which is very strange as it’s the exact same files.
When I build from my personal PC there are no problems at all but when I build using the build server (which uses Windows, same Unity version etc.) The info.plist seem to be empty?..
Okay so I replaced all my build servers FMOD Integration files with the ones from my personal PC and that made the builds run so something was not updated correctly through git??
Don’t really know what the issue was but now it’s working which is fantastic
@mathew
Nevermind my post above, it didn’t actually solve the problem as it seems to persist when I’m using the build server, everything works if I manually build the game for macOS.
The build server calls a method called JenkingsBuild.BuildAll that first builds to Windows64 then switches to macOS and builds that. Then it uploads those builds to the development branch on Steam. The thing that is strange here is that I can build and getting it to work IF I open up the editor and call the very same method manually…
Could there be something that goes wrong when building using these unity launch arguments maybe? -nographics -batchmode -quit -executeMethod JenkingsBuild.BuildAll
You mention that the build server first builds to Win64, then switches to macOS… this feels like a potential point of failure depending on how that process is managed. If all the files are checked out of Git on Windows and Git is set up to switch line endings on files to match the native OS then the Info.plist will have its line endings changed to Windows format. If when Jenkins switches to macOS to do that part of the build it uses the same files from Windows, then the line endings of the Info.plist will still be in Windows format (not Mac format).
If this is the case you’ll need to tell Git not to change the line endings for those files or have Jenkins check out the Mac files on the Mac (rather than on Windows).
So I’m still concerned about this Info.plist on the server.
Can you check that file on the server and verify the line endings after the server fetches from Git.
I still suspect that when Git pulls down the Info.plist it is switching the line endings to match the native Windows style (not knowing that file is intended for running on a Mac).
The simplest way to check the line endings with Notepad++ is go to View → Show Symbol → Show End of Line. The Info.plist must end each line with LF (as in line feed) not CRLF (carriage return line feed) for it to work.
The text you pasted will be converted on post to the forum, so I cannot use that as a reference. The DropBox link however shows correct Info.plist files. Can you confirm whether these are from the .bundles inside the Unity Assets FMOD directory or the produced .app? If they are from the Unity Assets directory we know Git is correctly checking the files out and it’s something to do with the building process converting them. If they are from the final .app then it should be working.
I can confirm that the .plist files were from the Unity Assets directory but just in case I rebuild everything using Jenkins and uploaded both the Unity Assets FMOD mac lib and the build PlugIns folder from the game so you can check them out.
The Info.plist from the app looks correct to me, I would expect the app that they came from would not exhibit the same issue you described. If you are unable to test, if you share the full .app with me I can test here.
