hey folks, i ran into this problem of fmodstudiol.dll being blocked on macOS Catalina and higher that’s been pinned. i’m actually a educational materials provider (The Game Audio Institute) who distributes game lessons, and up until now we’ve included the FMOD integration within the game project. well, we found that in Catalina and Big Sur the main FMOD Studio libs in the integration get quarantined by the OS, ostensibly because they’ve been ‘illegally’ imported.
after trying several solutions the end result was that i had to rip out the integration completely from the project, have the online students download the integration manually and then guide them through the setup. because that was the only way the native libraries could be copied so that the system didn’t flag them as a threat.
so, i’m curious - is it at all possible if you include the integration in the project that you can authorize the libraries through the setup? i know that currently if you have the integration installed, the Setup doesn’t run through the library copying/authorizing process which means that any macOS Catalina or Big Sur Mac will flag the libraries and block them.
this macOS system blockage seems like it would also affect any situations where you are collaborating with others via git on Bitbucket. i’m planning on updating a game lesson using FMOD Studio with the integration which means my Mac computer will run it since my libraries are authorized but a collaborator who gets the repo from me would not since their system would flag these as suspect and they would have to be whitelisted. so then if they get their libraries authorized and they push their changes and i sync, now my computer has the ‘foreign’ FMOD library and i would have to authorize. i was completely unable to manually whitelist FMOD libraries and i would hate to have to do it every time i pulled changes.
however, if Setup could run from the beginning and authorize libraries that might help. i suppose the other solution in a shared source scenario is to blacklist the relevant FMOD Studio libraries in the .gitignore file. have you or anyone else tested using FMOD integration 2.2 (2.02.xx) with git-based source control on Macs?
well, it’s the newest integration for 2.2 at this point. at the moment i’m distributing the integration inside the project, already installed. so there is a zip file but it’s the Unity project folder with the integration installed. this method is fine for macOS Mojave and earlier but Catalina and Big Sur regard the fmod libraries as suspect and quarantine them which breaks FMOD functionality in Unity. i realize this is all well known and the solution is to have no integration and install it individually separately. but i was wondering if setup could be modified to authorize the FMOD libraries without installing it from scratch. it seems to do this on a fresh install when the integration is not previously installed but when it is installed it skips over those steps.
Hm, the thing is, most of this stuff is out of our control - it’s an OS-level system that decides if something is safe or not, not us. So, we play by the rules and sign/notarize everything we produce so that it works when people download it. If you unpack what we ship and then try to repackage it and distribute it again… well, that’s way out of our hands.
hi Andrew - thanks for the clarification but i don’t think the signing or notarizing is the issue - we’re not unpacking the binaries other than the unitypackage file. the one question i would ask is, is it possible to make the integration reinstall completely from scratch without removing it first and reinstalling from the Unity Package? when Setup is run from the FMOD menu in Unity for the first time it does go through this process of copying and authorizing the DLLs. but if run a second time it doesn’t. is it possible to make the reinstall happen from scratch and re-authorize the DLLs?
on a separate front and knowing the issue with distribution of FMOD integration and how it’s authorized to each macOS computer individually, how is that handled when posting FMOD integration installed in a Unity project via Git or other source control? at this point if you had two Mac users working on a Unity/FMOD project the result would be that one or the other’s FMOD integration would be flagged as illegal and blocked. how do you handle that situation?
I think it would be helpful if I could see what you’re distributing and how it’s failing. If you could upload it to your fmod.com account (look in Profile, Uploads) and/or contact me at support@fmod.com I’ll be able to dig into it more.
hi there - i’m sorry i didn’t get back to you on this. here’s an update - i had an assistant make a bash script that would authorize the bundle files and it worked for his computer and a few others, but unfortunately in class it worked correctly about half the time. so for the other half i had to give them explicit directions to install the integration from scratch which was extremely frustrating. so at this point we’ve given up including the integration in our FMOD based Unity projects which means they get shipped in a non-compilable state until the integration is installed, and we’re providing a guide on how to do that.
i’m currently running through the installation of the 2.02.04 integration for this documentation and i noticed a new section on source control and tips on editing the .gitignore file which explicitly says to track the libraries.
this does bring me back to my earlier point from months back. if you had a development team where two members of that team had macOS Catalina or higher, and they were tracking the fmodstudiol.dll then when one macOS computer (Person A) sent the project to the other one (Person B) the receiving macOS computer’s OS would flag fmodstudiol.dll as a suspect library and quarantine it. this would then mean that Person B would have to install the integration on their computer and then NOT track it, otherwise i would assume if Person B pushed their changes then Person A’s OS would flag that updated(reinstalled or reauthorized) DLL and then Person A would have to reinstall their integration to authorize the DLL.
obviously since Windows machines aren’t affected by this issue none of this would matter if only one computer was a macOS machine and the rest were Windows PCs but as far as i’ve been able to determine the requirement to track the fmodstudiol.dll would create havoc every time two or more macOS machines were involved. to me it seems the only solution would be to make sure everyone has all the files and then deliberately STOP tracking the DLLs so that they wouldn’t be updated.
have you tested a Git based source control with two or more macOS machines running Catalina or later and tracking all of the plugin DLLs and had no issues of any kind after pushing/pulling changes? because if you have that’s pretty close to what we were doing distributing Unity projects with the integration installed to multiple macOS machines.
i can send a project to test if desired. i can’t test things on my computer since it’s macOS High Sierra, but i may be able to get another computer to test on once i hear back from our tech assistant. but please let me know if my reasoning is faulty. thanks!
Thanks for the detailed explanation Scott. I’ve added an issue to our tracker and we’ll investigate the full end-to-end macOS > github > macOS workflow to see if we can reproduce your problem.
If you download a zip file from the internet or even a LAN (possibly containing a Unity project with the FMOD integration already installed) and open it using a program that uses the macOS system zip functions (e.g. by simply double-clicking the zip), macOS will apply the quarantine flag to any executables and shared libraries it finds as it extracts them. This means that if you transfer a Unity project that has the FMOD integration already installed, the FMOD shared libraries within it will be quarantined on extraction and the Unity project will fail to run.
Notes :
If you use a zip program that does not use the macOS system zip functions, the extracted files will not be quarantined. This has been confirmed with 7-Zip, for example.
If you transfer your Unity project via github with “git clone ” instead of “Download ZIP” then the cloned files will not be quarantined.
So, my advice would be to use “git clone” if possible or, if you must use zip files, open them with a third party tool like 7-Zip.