Editor freezes more than usual when hitting play.

[axelbau24]

Please fill in the following fields:

Unity editor version: 2019.3.7f1 Firebase Unity SDK version: 6.13.0 Source you installed the SDK (.unitypackage or Unity Package Manager): .unitypackage Firebase plugins in use (Auth, Database, etc.): FirebaseMessaging.unitypackage Additional SDKs you are using (Facebook, AdMob, etc.): None Platform you are using the Unity editor on (Mac, Windows, or Linux): Windows 10 Platform you are targeting (iOS, Android, and/or desktop): Android Scripting Runtime (Mono, and/or IL2CPP): Tried both

Please describe the issue here:

(Please list the full steps to reproduce the issue. Include device logs, Unity logs, and stack traces if available.)

Everytime i hit play (even on a empty project), Unity takes too long to build, compared to the usual time, this is not practical for me. Also, when the game starts (the play button becomes blue), the editor completely freezes for a few seconds as if it was compiling the game once again. Am i doing something wrong ?

To easily reproduce this issue:

• Create a empty 3D project
• Switch to Android Platform in the build settings
• Import FirebaseMessaging.unitypackage from Assets -> Import Package
• After import, a popup shows up to enable Android Auto-Resolution, click "Enable"
• The Unity Packager Manager Resolver window opens, click "Add selected registries"
• Wait until all dependencies update.
• Don't add anything else, and hit "Play"
• You will notice the editor freezing and taking way too long to build.

This problem happens even if you don't have any base code running. Also, tried adding the google-services.json, but it doesn't do anything in this case.

Please answer the following, if applicable:

Have you been able to reproduce this issue with just the Firebase Unity quickstarts (this GitHub project)? Yes, the exact same thing happens here, and it feels worse.

What's the issue repro rate? (eg 100%, 1/5 etc) 100%

[jasonlawless]

@igor84 I like your approach. I implemented it myself, but I wanted to confirm if I did the correct way. This is a first for me to even dive into this area, let alone dnSpy. Can you confirm or correct what I did to make sure it is correct?

1. Unity Package Manager. Installed Firebase 6.15.0. (which already implements @bhallionOhbibi solution. Great find btw.

2. Downloaded dnSpy v6.1.4. Removed all default assemblies. Opened Firebase.Editor.dll and all dependent references.

3. Edited the GenerateXmlFromGoogleServicesJson class in Firebase.Editor.dll: a) Removed the following from it's static constructor:

   if (!EditorApplication.isPlayingOrWillChangePlaymode)
   {
   RunOnMainThread.Run(delegate
   {
       GenerateXmlFromGoogleServicesJson.CheckConfiguration();
   }, false);
   }

   b) Made the CheckConfiguration static method public and added [MenuItem("Window/Firebase/Check Configuration")] c) Fixed all compiler errors (cache references) and saved module.

4. Copied the modified Firebase.Editor.dll to another folder in the [Project] directory.

5. Created an EditorStartup.cs script:

   
   using UnityEditor;

[InitializeOnLoad] public class EditorStartup { static EditorStartup() { string fromPath = "Support/Firebase.Editor.dll"; string toPath = "Library/PackageCache/com.google.firebase.app@6.15.0/Firebase/Editor/Firebase.Editor.dll"; FileUtil.ReplaceFile(fromPath, toPath); } }

This was because I noticed it would revert the Firebase.Editor.dll file on each Startup. So this way it overwrites it each time it loads.

6. Created a `CustomBuildProcessor.cs` script:

using UnityEditor.Build; using UnityEditor.Build.Reporting; using UnityEditor;

public class CustomBuildProcessor : IPreprocessBuildWithReport { public int callbackOrder { get { return 0; } }

public void OnPreprocessBuild(BuildReport report)
{
    EditorApplication.ExecuteMenuItem("Window/Firebase/Check Configuration");
}

}

This is where I realized why you made that `MenuItem` as I didn't find any other way to call `CheckConfiguration`. And that was pretty clever of you. Well done.

So would this setup run the Check Configuration on build properly? Or did I miss or misundertand something?

[igor84]

Hi @jasonlawless. Your solution should work but it is different from mine a bit and has some drawbacks:

I did't install Firebase through Unity package manager. I downloaded the unitypackage files of External Dependency Manager and Firebase and then installed them manually. That way their dll files are directly in the project and Unity doesn't overwrite the Firebase one once I change it. That makes a drawback in your solution. Since you had to write that script to constantly overwrite the DLL that might also affect your compile time since Unity might need to again recompile the project when it detects that dll has changed. Although Unity might not do that since it is outside its Assets folder, I am not sure.

Also in step 6 since you made the CheckConfiguration method public you should be able to call it like this:

GenerateXmlFromGoogleServicesJson.CheckConfiguration();

That is what I did.

At first I didn't even implement step 6 I only made a MenuItem because my understanding was that this CheckConfiguration thing is something that needs to be executed only after changing google services json or plist file that is downloaded from Firebase console and maybe when the Firebase plugin is updated and in both of those cases I can now just run it manually from the MenuItem. But since I don't have a complete understanding of what it does I decided, just in case, to also call it just before the build.

[jasonlawless]

@igor84 Thanks for your quick and detailed reply. Considering your advice regarding Firebase installation via EDM or PM and the possibility of longer compilation times: I have found out that [InitializeOnLoad] indeed is ran on Editor load and each script change, as well as domain reload. It seems I misunderstood this and assumed this only ran on Unity Editor load and that's it. Nonetheless, I decided to test out to see if Firebase.Editor.dll gets "refreshed" on each compilation and if that does increase my compile time before I decided to switch away from PM and go to EDM solution.

I modified the EditorStartup.cs script like so:

using System;
using System.IO;
using UnityEngine;
using UnityEditor;

[InitializeOnLoad]
public class EditorStartup
{
    private static DateTime matchDate;

    static EditorStartup()
    {
        string fromPath = "Support/Firebase.Editor.dll";
        string toPath = "Library/PackageCache/com.google.firebase.app@6.15.0/Firebase/Editor/Firebase.Editor.dll";
        if (matchDate == DateTime.MinValue)
            matchDate = File.GetLastWriteTime(fromPath);
        DateTime modifiedAt = File.GetLastWriteTime(toPath);
        Debug.Log($"Custom file mod date: {matchDate} => Firebase.Editor.dll mod date => {modifiedAt}");
        if (modifiedAt != matchDate)
        {
            FileUtil.ReplaceFile(fromPath, toPath);
            Debug.Log("Firebase.Editor.dll was patched.");
        }
    }
}

And tested it by first opening Unity Editor. Then making a random script change. [See Console log screenshot below]. Turns out Firebase.Editor.dll ONLY get's "refreshed" on Editor startup ONLY. It does not go through that process on each compilation. And seeing as how my compilation time has already dropped back to its initial state prior to Firebase installation, I think I'll just stick with this solution for now. Again, @igor84 thank you for pointing this out because I was re-writing the Firebase dll on each script compile. Now that is not the case.

Now. As for GenerateXmlFromGoogleServicesJson.CheckConfiguration() I too though that I would be able to call it like you suggested at first. But for some reason I couldn't figure out which namespace to using and Firebase.Editor either doesn't exist in my project or is not accessable. Anyways, I feel I am in deep waters with only one floaty right now. That is why I decided to call it via the Menu. Can you help me figure out what I need to reference so that I can call it directly via the class?

Thanks

[igor84]

You need to using Firebase.Editor; and the script from which you call it must be under Editor folder anywhere under Assets or if you are using asmdefs then it needs to be a part of Editor asmdef.

[jasonlawless]

Boom! It worked. Thanks @igor84 you're the man!

Also regarding my workaround. If you close your project whilst you have some script (compile) errors, and then next time you load Unity, because of the compiler errors, the EditorStartup script will not execute, therefore the Firebase.Editor.dll file will be restored by Google's SDK.

Minor hiccup, but it's there. Anyways, that's my two cents. I'm happy about getting this resolved.

[jasonlawless]

@igor84 Hey there. I had a couple more follow up questions regarding compiling optimizations, and I don't think it's appropriate to continue it on this thread as it might veer away from the topic. I was wondering if there is someway I can get in touch with you, if of course you have sometime to help a fellow developer. I tried asking other sources, and apparently it's a bit over their league lol. So I thought I'd try with you. If not, no worries, I understand, I can then delete this comment. Either way, thanks for the help you already gave me.

[andruDigital]

Hi guys, can you please do a resume with the solution?, i'm a little confuse and is very frustating do a game with this problem every time i change code or just hit play. Tanks

[igor84]

Hey @jasonlawless. Sorry for the late reply. If you still need some help we can try chatting on https://tlk.io/unityfirebase.

@andruDigital jason made a step by step guide here: https://github.com/firebase/firebase-unity-sdk/issues/378, and my comment was just not to use unity package manager but download and manually install unitypackages of EDP and Firebase, to avoid some hurdles. I don't see how could we explain it more clearer.

[jasonlawless]

FYI, for anyone wishing to use my guide. This is to add to the "hurdle" that @igor84 mentioned in the previous comment (don't know how to ref link the comments here yet). Anyways, IF you close Unity (or it crashes) whilst there are ANY compilation errors outstanding, next time loading Unity will NOT run the Firebase.Editor.dll script override. You will need to copy the file manually. I been too busy with other things to look for a way to circumvent this while holding on to PM Firebase installation. If I get around to it, I will post an update.

Otherwise, if you would like to avoid this all together, consider using @igor84 advice on installing Firebase using External Dependency Manager instead.

[andruDigital]

hi @jasonlawless, i don't know how to fix the compile errors in dnSpy, the ones with the cache references... can you pleas guide me on how to fix it. Tanks.

[jasonlawless]

The compiler doesn't like the <>f__mg$cache0 syntax. They are just references or pointers. It's like declaring a variable that also conforms to a certain syntax. So in this case you can change it to something like f__mg0 or iHateFixingCompilerErrors it doesn't matter. Just make sure you follow through with the indexing. Try to keep it simple. So if it is <>f__mg$cache4 change it to f__mg4 or iForgotToDoMyLaundry as long as you rename the the same references with the same name as <>f__mg$cache0 is referenced more than once, if you rename it to iLoveWonderWoman, make sure you rename the next <>f__mg$cache0 to the same variable name. Does that make sense?

[jasonlawless]

Heads up, not quite sure if this has something to do with this patch that we implemented or not, but I thought I'd bring it up here and see if anyone else is or has experienced something like this: I used Auth and Firestore SDK, no issues. Works good. But it seems that there is an "invisible" exception that gets thrown while in Editor mode. It remained undetected to me until I built the app. When I load app, it throws a funky exception on load:

And this exception keeps coming up with every action you take in the app, which prevents the app from running correctly. So I attached VS debugger to it and did some digging. Wasn't simple to detect, but found out that it all starts from this:

FirebaseAuth auth = FirebaseAuth.DefaultInstance;

Which leads to this exception:

System.IO.FileNotFoundException: Could not load file or assembly 'Firebase.Crashlytics' or one of its dependencies
File name: 'Firebase.Crashlytics'
  at System.AppDomain.Load (System.String assemblyString, System.Security.Policy.Evidence assemblySecurity, System.Boolean refonly) [0x00031] in <437ba245d8404784b9fbab9b439ac908>:0 
  at System.AppDomain.Load (System.String assemblyString) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0 
  at (wrapper remoting-invoke-with-check) System.AppDomain.Load(string)
  at System.Reflection.Assembly.Load (System.String assemblyString) [0x00005] in <437ba245d8404784b9fbab9b439ac908>:0 
  at Firebase.FirebaseApp.InitializeCrashlyticsIfPresent () [0x00000] in Z:\tmp\tmp.txs8ldQ514\firebase\app\client\unity\proxy\FirebaseApp.cs:487 

Now, I thought that this would be a simple fix. I never setup Crashlytics in my app, so I installed the SDK and referenced the Firebase.Crashlytics.dll assembly and built again. But to my disappointment, same error.

So I started to see if there were any "invisible" exceptions during build, and sure enough I found that my CustomBuildProcessor.cs script mentioned earlier in this thread where I had this line:

GenerateXmlFromGoogleServicesJson.CheckConfiguration();

was throwing this error:

"System.IO.FileNotFoundException: 
File name: \'D:\\Projects\\Construct\\Library\\PackageCache\\com.google.firebase.app@6.15.0\\Firebase\\Editor\\en-US\\Firebase.Editor.resources.dll\'
  at (wrapper managed-to-native) System.Reflection.Assembly.LoadFrom(string,bool)
  at System.Reflection.Assembly.LoadFrom (System.String assemblyFile) [0x00000] in <437ba245d8404784b9fbab9b439ac908>:0 
  at System.Reflection.Assembly.InternalGetSatelliteAssembly (System.String name, System.Globalization.CultureInfo culture, System.Version version, System.Boolean throwOnFileNotFound, System.Threading.StackCrawlMark& stackMark) [0x000ad] in <437ba245d8404784b9fbab9b439ac908>:0 "

And when I looked at the referenced path, the folder en-US does not even exist, and neither does that file. So I commented out that entire script, and built again.

But the DefaultInstance STILL fires that same exception. If someone is experiencing or has experienced this issue, please reach out to me if you have a solution. @igor84 maybe you have some insight? Or we can put our heads together to figure this out? I scoured the internet and found nothing about this anywhere.

UPDATE: After a crap ton of trial and error and even Firebase source code modifications, I have found a fix, but it still doesn't address the "invisible" exceptions. However the app now runs fine. I reverted the Firebase SDK back to its native code to try and see if maybe my patch was causing issues, and no it gave me the same result as before. Upon investigating Firebase's source code, their Exception that is thrown by searching for the Crashlytics module is in a try/catch, so this is why it remains "invisible" on my end. And although I suspected it was the issue, I now think it's something even more hidden. My scripts use something called ExpandoObject which is a fairly new feature in .NET, that requires you to declare it's instances using the dynamic keyword. Now I researched Unity's support for dynamic vars, and they do indeed support it provided you on the latest version of everything. But it wasn't playing well with ExpandoObject, which ended up throwing a chain reaction of exceptions, all of which were indirect and hard to find for some reason. Probably just crappy coding on my part.

Anyways, to make the long story short, I ended up changing the player build scripting backend from IL2CPP to the good ol' Mono. With Firebase reverted and Mono set, (I also had to disable code stripping as well), the app launched and worked as expected! However, that exception is still thrown if you search for it, but it is absorbed by Firebase's internal catch, and doesn't interfere with my code.

In conclusion, I do believe that this has something more to do with the combination ExpandoObject and IL2CPP scripting backend compiler. Can't say for sure, just a gut feeling. I thought I'd share this anyway in case anyone runs into this issue and can't figure out what the heck is going on. Either way, if you end up doing something unconventional (like altering source code library(ies), etc). Be sure to build and test in standalone right away before coding away and then finding yourself sifting through a haystack to find the needle.

Cheers.

[igor84]

I just rechecked our build logs but I couldn't find that FileNotFoundException with en_US folder. Maybe again it has something to do with us not using the Package Manager.

On the other hand I think we did encounter that Could not load file or assembly 'Firebase.Crashlytics' issue and I think we solved it by putting a link.xml file in the Assets folder with this content:

<linker>
    <assembly fullname="Firebase.Crashlytics" ignoreIfMissing="1">
        <namespace fullname="Firebase.Crashlytics" preserve="all"/>
    </assembly>
    <assembly fullname="Firebase.App" ignoreIfMissing="1">
        <namespace fullname="Firebase.App" preserve="all"/>
    </assembly>
</linker>

[igor84]

I made a video on installing and modifying Firebase: https://youtu.be/LVsTVU8cqpk

[andruDigital]

The compiler doesn't like the <>f__mg$cache0 syntax. They are just references or pointers. It's like declaring a variable that also conforms to a certain syntax. So in this case you can change it to something like f__mg0 or iHateFixingCompilerErrors it doesn't matter. Just make sure you follow through with the indexing. Try to keep it simple. So if it is <>f__mg$cache4 change it to f__mg4 or iForgotToDoMyLaundry as long as you rename the the same references with the same name as <>f__mg$cache0 is referenced more than once, if you rename it to iLoveWonderWoman, make sure you rename the next <>f__mg$cache0 to the same variable name. Does that make sense?

That made the trick, thank you... btw my Firebase.editor.dll is not in Library/PackageCache folder but in Assets/Firebase folder, and the edited dll dont get replaced every run of Unity even if i didn't made the EditorStart.cs

[jasonlawless]

@igor84 I went ahead and created that link.xml, although I'm not sure as to why it is "ignoring" Firebase.App? How did you guys come up with that approach btw? Also can you get on that chatroom one more time?

@andruDigital If you installed your Firebase SDK via External Dependency Manager, then yes it will be inside the Assets/ directory and WILL NOT be overwritten by each load. This is what @igor84 was mentioning earlier. My fix was for those who installed Firebase SDK via Unity's Package Manager. At this point, I will need to enhance my workaround, or also switch to EDM version.

[Whyser]

..or Firebase team can prioritize this? It's impossible to work on project which has Firebase in it without doing any of the hax-fixing above. I couldn't care less about added time during build, but when everything freezes for 20sec+ with a small script change...it's unbearable.

Any update on this @chkuang-g ?

[G-r-i-n-c-h]

Any news ? it should be N1 priority to fix this kind of bug !

[jasonlawless]

Hey Alex,

Wow, thank you for following up on this. I didn’t expect any support to be this thorough, bravo. Unfortunately, not only has so much time passed since then, and due to other issues/limitations that I had to deal with when composing our project, I concluded the head ache that it caused out-weighted the time it would take me to write and deploy my own webserver. And I ended up doing just that, I setup a webserver and now each client connects to it via socket, and it’s working great.

That being said, I am still impressed with what you guys are doing and have done. I have used Firebase before on another platform, and that is precisely why I tried to implement it on the Unity platform, but it seems as though it could use a little more work. You guys are doing a great job with it, keep it up, I’m sure you’ll hit the bulls eye. As for this project, I will end up staying with my new solution as tacking on more layers is now going to be easier than restructuring it back to Firebase solution.

As far as what the issue was that broke the camel’s back. I believe it had to do with the fact that I couldn’t run the same client concurrently and simultaneously on the same machine. When I ran the first session, Firebase would create a temp file and ‘lock’ it, and when the second session loads, it attempts to access that locked file, but it can’t, and so the Unity client (whether it’s editor or runtime, doesn’t matter), just hard crashes. At least that was with the version I used, which if my memory serves me right was 6.15.0? If knowing the version is extremely important to you guys, let me know, I can review my git logs, as I have logged that somewhere in there.

Good luck with everything else,

Jason Lawless™

From: Alex Sent: Sunday, July 26, 2020 7:55 AM To: firebase/quickstart-unity Cc: Jason Lawless™; Mention Subject: Re: [firebase/quickstart-unity] Editor freezes more than usual whenhitting play. (#639)

Any news ? it should be N1 priority to fix this kind of bug ! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[HSK57]

Why is this bug still there? It creates an extra 20 second delay on every run that makes it unusable. The profiler shows that most of this time is spent in XcodeProjectPatcher..cctor() > iOSResolver..cctor() > Mono.JIT which is particularly weird considering that I'm building for Android on a Windows computer.

I knew I was going to regret it when I finally decided to add Firebase to Unity. For now, my workaround is to not use Firebase. I'll check again next year if things have changed (the average delay for a critical bug fix in most Google libraries).

[chkuang-g]

Hey folks,

Sorry for the late response. The team is currently investigating into the issue. iOSResolver seems to contribute to this freeze the most as well as other factors.

It does looks like iOSResolver is trying to run regardless platform and build target. https://github.com/googlesamples/unity-jar-resolver/blob/master/source/IOSResolver/src/IOSResolver.cs#L653

Just curious, does the situation improve if you just remove Google.IOSResolver_v[version-number].dll? Or does installing iOS build tool on WIndows reduce the freeze?

We will compose a patch for this ASAP.

Shawn

[G-r-i-n-c-h]

I had to switch to OSX to work on project :D

[chkuang-g]

Hi folks,

We just updated EDM4U to 1.2.157.

The most relevant changes to this thread is that now it will only initialize iOSResolver/AndroidResolver only if the current active build target is iOS/Android and not in play mode. That is, if your current build target is not iOS, iOSResolver initialization will never happen when you click on the Play button. If your current build target is iOS, iOSResolver initialization will happen after you exit the play mode.

At least, it will not try to do the slow searching for UnityEditor.iOS.Extensions.Xcode.dll unless you switch to iOS build target. While the searching is a workaround for a bug in some versions of Unity, this should not bother you now unless you are in that unfortunate version of Unity.

You should be able to get the latest .unitypackage here. UPM version should be available in 20ish min.

However, I can still see a couple of performance improvement for both EDM4U and Firebase SDK.

1. [Firebase] Search for google-services.json and/or GoogleServices.plist
2. [EDM4U] Search for Dependencies.xml

These searches use standard AssetDatabase.FindAsset(). Since we do not require the user to label them or put them in a fixed folder, the code basically need to use a generic search across the whole Asset Database. And our editor plugins require at least load them once to handle any upcoming events, such as post process event and build request.

The tricky thing is AppDomain reloads whenever play mode starts (there is a flag introduced in later version of Unity which prevent this. I feel very skeptical about it.)

Still looking into some solutions. And feel free to make some suggestoins.

I'll keep this thread open until we have a better solution for the searching.

Shawn

[jimanjr]

Did anyone profile AssetDatabase.FindAsset()? I don't think it's an issue performance-wise, but if it is you can probably cache its path in EditorPrefs after the first FindAsset?

[chkuang-g]

I think it will be slower when the Unity project grows.

Caching is tricky since those files can be added anytime with or without Unity is opened.

Well, only if there is something that can be called only ONCE after the Unity is launched.

The closest thing I get so far is using [InitializeOnLoad], static constructor and EditorApplication.isPlayingOrWillChangePlaymode, which might be good enough. :/

[chkuang-g]

BTW, some improvement from the Firebase SDK will be included in the next release.

[JoNax97]

Hello! Thank you for working on improving the performance of the plugin! In the meantime, I think you can allow disabling the automatic checking (but have it enabled by default as to not alter the current behaviour) for those users who don’t need it all the time. Additionally, you can expose the method through the menu to allow manual checking. Here's a working sample that creates a menu entry that can be toggled on/off and saves its state to the EditorPrefs:

    [InitializeOnLoad]
    public static class AutomaticCheckingSetting
    {
        private const string MENU_NAME = "Window/Firebase/Check Configuration Automatically";
        private const string PREF_NAME = "firebase_check_config_automatically";

        public static bool Enabled
        {
            get { return EditorPrefs.GetBool(PREF_NAME, true); } // Return true if the pref is not set
            set
            {
                EditorPrefs.SetBool(PREF_NAME, value);  // Saving editor state
            }
        }

        // Called on load thanks to the InitializeOnLoad attribute
        static AutomaticCheckingSetting() {

            // Delaying until first editor tick so that the menu
            // will be populated before setting check state, and
            // re-apply correct action
            EditorApplication.delayCall += () => Menu.SetChecked(MENU_NAME, Enabled); // Set checkmark on menu item
        }

        [MenuItem(MENU_NAME)]
        private static void ToggleSetting()
        {
            Enabled = !Enabled;
            Menu.SetChecked(MENU_NAME, Enabled);
        }
    }

And here’s how the current code would use it:

[InitializeOnLoad]
public class GenerateXmlFromGoogleServicesJson
{
    static GenerateXmlFromGoogleServicesJson()
    {
        if (!EditorApplication.isPlayingOrWillChangePlaymode && AutomaticCheckingSetting.Enabled)
        {
            RunOnMainThread.Run(delegate
            { 
                GenerateXmlFromGoogleServicesJson.CheckConfiguration();
            }, false);
        }
    }

    [MenuItem("Window/Firebase/Check Configuration Now")]
    public static void CheckConfiguration()
    {
       // Check configuration logic
    }
}

[sanuzzi]

☝️ Good proposal @JoNax97 ☝️ That would be very useful! So we stop wasting so much time!

[josefalanga]

Indeed, checking the configuration is very useful, but It's not necessary on every recompile. Having a toogle to opt-out and a manual check option sounds awesome. @JoNax97's proposal looks great!

[guidoPaglie]

@JoNax97 excellent proposal, we are having the same problem.

[JoNax97]

@chkuang-g Have you had time to check the code I posted? :)

[chkuang-g]

@JoNax97

This is great proposal. Thanks for sharing. The team is working on other issues at the moment. Will keep you posted.

[InfinitiesLoop]

This issue manifested in another way for me. It completely killed my ability to build the game. Due to a separate issue, our build generates a bunch of assets, and it does so by writing them to a folder that is inside the Assets directory. This was causing there to be a refresh in Unity after every file. Thousands of files were being written, so we were incurring this added delay thousands of times. Builds would go for 5 hours before being killed off, and probably would take days if left running. We sort of fixed the original problem by pausing refreshes with StartAssetEditing() and StopAssetEditing() calls before/after the asset generation, and that has alleviated the problem, but there are other aspects of our build that are outside of that, so still incurring overhead from the Firebase issue.

[ZLTM]

after adding a real-time database script I cant use the play button anymore, I tracked the problem to this code

void Start()
    {
        DatabaseReference reference = FirebaseDatabase.DefaultInstance.RootReference;
    }

Of course, we need this to be able to push and pull values from the DB, anyone found any solution?

[ORibn-dev]

I have similar kind of issue on Unity 2019.4.16f1, Editor permanently freezes after 2nd/3rd Play or 2nd/3rd code compiling in Visual Studio, so I have to restart Unity every time. I have Firebase Database, Storage and Remote Config. I didn't have this issue before, even though I had freezes from time to time, but now I have this problem and don't quite understand where it came from.

[MBRSL]

@chkuang-g It's been years. Is there any news of this issue? GenerateXmlFromGoogleServicesJson not only slow down editor performance, it also produce lots spam in Unity editor logs. This causes so much troubles when debugging CI pipeline.

[mrKrenar]

Guys, come on! Is there any update yet on the issue? I am having serious troubles for some times now, can't work for more than 5 minutes in same project without needing to force kill unity!

[binouze]

Hi, Still no news about this issue ? Why don't you just run your GenerateXmlFromGoogleServicesJson code in a pre build process instead of at every compilation ? Is this xml useful in editor ?

[kakkou]

I was having the same problem but found out that the cause is the anti-virus protection. It slows down the initial launch of generate_xml_from_google_services_json.exe, which is created by Pyinstaller. When the protection status is enabled, it takes 10 seconds to get an error code when run directly at the command prompt. Registering the exe in the exclusion settings improved the situation.

[VanIseghemThomas]

Still a problem on Windows in 2023, any updates? Seems that it's caused by Firebase.Editor.XcodeProjectPatcher:CheckBuildEnvironment

[tomkail]

Stumbled on this thread while trying to improve editor performance. Adding our voice here - this is a serious issue that doubles the time it takes for Unity to recompile for us. We started using Firebase last month but we're going to have to abandon it due to this issue.

[VanIseghemThomas]

@tomkail we ditched the Firebase SDK and I just wrote our own implementation using the REST API endpoints. For us we just needed auth and the existing NuGet package for auth was giving us problems on certain versions of Unity.

[novi-ranoja]

Any fixes? still an issue as of now, unity version: 2021.3.2f1, iOS Target Build in Unity Windows Platform

after integrating the firebase messaging plugin, tried it with our current 10.6.0 firebase version with external dependency version of 1.2.175 & also updated it to 11.6.0 version with external dependency version of 1.2.177 still the same freezing on playmode.

[tomkail]

Can anyone suggest an alternative plugin for this? We really want fast compile times back.

On Fri, 17 Nov 2023 at 02:10, novi-ranoja @.***> wrote:

[image: image] https://user-images.githubusercontent.com/96708166/283647609-b75bc05c-c5c4-4079-8169-eea3c613a0c3.png

Any fixes? still an issue as of now, unity version: 2021.3.2f1, iOS Target Build in Unity Windows Platform

after integrating the firebase messaging plugin, tried the 10.6.0 firebase version with external dependency version of 1.2.175 & also updated to 11.6.0 version with external dependency version of 1.2.177 still the same freezing on playmode.

— Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-unity-sdk/issues/378#issuecomment-1815635084, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJR3UG6FEYBWNHDEDCUSHDYE3BPRAVCNFSM5ZYTSG4KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBRGU3DGNJQHA2A . You are receiving this because you were mentioned.Message ID: @.***>

[mrKrenar]

@novi-ranoja editor freezing is generally a problem related to unity 2021, in my experience. Maybe you can try to upgrade to 2022