Quickstart-unity: 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%

[patm1987]

Hi @axelbau24 ,

Thanks for your report!

You've done everything right so far, but I've been unable to replicate the issue on my end. Can you tell me if you see any windows, dialogs, &c pop up after the first time you hit play (screenshot them if you like/can)? Do you see anything interesting in your Console window/would you mind sharing your Editor log?

(note that if you don't feel comfortable sharing your Editor log publicly, you can file a bug here and link this issue/say you're trying to add information for this bug).

Is there anything else of interest that you can think of in your setup? Are you using meta files? A version control system other than Git? Is part of your unity project readonly or stored on a synced volume (ex: Dropbox, iCloud, &c)?

I'm checking in with the rest of the team to see if there's anything else we need to verify.

Thanks,
--Patrick

[almosr]

I have similar experiences with Firebase Core and Analytics. If I remove them from the project then everything goes back to normal. I doubt that this would make any difference, but I used External Dependency Manager for Unity (EDM4U) and Unity Package Manager to install the packages.

Nothing is synced in the background for my project, it is a fairly straightforward setup. Code generation is set to .NET 4.x and IL2CPP, but changing the setting to Mono makes no difference.

A similar delay also happens when I switch from my code IDE (JetBrains Rider) to Unity editor, if there was any change on the source code and it is recompiled in the background Unity editor stops responding for a good 15-20 seconds.

I have tried profiling the editor to figure out what is going on. I am no expert on Unity profiling, but as it seems to me when this delay happens then profiler stops capturing anything until the editor starts working again.

Please let me know if there was any other information I could provide.

[almosr]

I have attached the editor log from the moment I press the play button:
editor_log.txt

This line looks rather suspicious to me:

Unloading 534 unused Assets to reduce memory usage. Loaded Objects now: 5522.
Total: 15.606300 ms (FindLiveObjects: 0.836300 ms CreateObjectMapping: 0.170500 ms MarkObjects: 13.140400 ms  DeleteObjects: 1.457900 ms)

Edit: nevermind, I just realised it is msecs. :)

[MateusMP]

I might have the same issue. Looking at the editor profiler, there is at least one entry that seems suspicious to me:

Note that I'm running on Windows 10. I can't say for sure if that XCodeProjectPatcher is related to firebase, but looking through some results on google it seems to be the case. But this seems to be a specific thing for IOS, so why is it running on my windows environment? It seems to be responsible for at least 4s of startup time.

I'm using Firebase 6.13, auth, database and analytics. And google admob.
Running on SSD.

[daksheshpatel]

Exact same issue mentioned by MateusMP. It takes almost 4-5 seconds to enter play mode in the empty project with just Firebase core installed from package manager.

[almosr]

I am running Unity on Windows too, maybe this is an important piece of information.

[axelbau24]

Thank you for your answer @patm1987

Here's my Editor Log Editor.log

Also, noticed some iOS stuff happening, even though i'm just compiling for Android, just like @MateusMP did, In my case i don't see anything related to XCode, just the iOS resolver (which i don't think it should be there and also taking a long time to compile.

Is there any way to disable this iOS resolver?

EDIT: This was a completely empty project stored on my PC, no version control or cloud were used.

[GorillaOne]

I'm having a similar symptom (8 second slowdown right after entering playmode). Platform is set to Android. Same Unity and SDK version as original poster. I have also tried disabling all auto-resolve functions in the package, but this seems to get called no matter what. This is a critical issue.

Using Google Analytics for Firebase, Firebase Core, and Firebase Cloud Messaging.

[leni8ec]

I have the same issue.
Freezes at 10-15 seconds on press play button.

Unity 2019.2.21, Firebase 6.12.0 and 6.13.0

[GorillaOne]

The majority of this slowdown appears to be due to the Google Play Resolver / External Dependency Manager. When removed, the slowdown goes away. Of course, Firebase won't load so you'll need to add it in again before you build - and this option only works when using the manual install because if you're using Firebase unity packages it will not let you uninstall the EDM because the firebase libraries rely on them.

[diegoempi]

@GorillaOne How do I remove that? Thanks!

[Hauki]

I have the same issue.
Freezes at 10-15 seconds on press play button.

[kirilogan]

I’m having the same issue, but on top of this the editor freezing for 20seconds after each code save. It’s getting unbearable. What would normally take me 2 mins to do, takes 3-4x as long.

I also tried a vanilla build using a brand new project and only adding firebase - same issue.

Anyone else experiencing delays between code changes and then switching over to the editor (even with out play)?

[L4fter]

I believe this is the same issue as in #644

[kirilogan]

I believe this is the same issue as in #644

I think you are right - I was looking at #644 earlier and sounds very similar.

[ideka]

The issue is still present in 6.14.0, EDM version 1.2.153.

As a workaround for those using the Package Manager versions, you can simply delete the Editor folder and Editor.meta file within Library/PackageCache/[email protected]/ExternalDependencyManager. You may have to do it every time you start Unity.

You'll sometimes get an error message about failing to load Firebase.Editor.dll, but it seems you can safely ignore it.

[kirilogan]

The issue is still present in 6.14.0, EDM version 1.2.153.

As a workaround for those using the Package Manager versions, you can simply delete the Editor folder and Editor.meta file within Library/PackageCache/[email protected]/ExternalDependencyManager. You may have to do it every time you start Unity.

You'll sometimes get an error message about failing to load Firebase.Editor.dll, but it seems you can safely ignore it.

The issue is still present in 6.14.0, EDM version 1.2.153.

As a workaround for those using the Package Manager versions, you can simply delete the Editor folder and Editor.meta file within Library/PackageCache/[email protected]/ExternalDependencyManager. You may have to do it every time you start Unity.

You'll sometimes get an error message about failing to load Firebase.Editor.dll, but it seems you can safely ignore it

What would be the downside of this? Would it be that you can’t add any new firebase packages or does the dependency manager get re-added (and that’s why we need to remove each time?)

[ideka]

What would be the downside of this? Would it be that you can’t add any new firebase packages or does the dependency manager get re-added (and that’s why we need to remove each time?)

You lose all firebase editor-specific functionality, but you can restore the folder when you actually need the functionality, and keep it removed when you don't. I assume you need it for building, resolving dependencies, probably for installing or removing packages too.

Obviously not ideal but I think it's a serviceable workaround for now, until this issue is fixed.

[brunoschalch]

Same issue here!
When I play a scene, music starts to play but all graphics and the unity editor are frozen for a couple of seconds.
I can confirm this happened only after adding Firebase Analytics (Android + iOS) to my project.

Unity 2019.3.10f1, Firebase 6.14.0

[almosr]

Deleting this folder: Library/PackageCache/[email protected]/ExternalDependencyManager does NOT solve the issue. It is a problem with Firebase and not EDM.

The only workaround I was able to figure out is to remove Firebase from the project while I edit it and put it back when I create a new build.

[ideka]

@almosr The workaround I posted definitely solves it for me. Maybe it's two different issues, or our environments are different somehow.

A reminder just in case, Unity restores the folder when you open the project, so you have to delete it when the project is already open.

[almosr]

@ideka When I deleted that aforementioned folder while Unity is open then the issue disappears, because Firebase fails to initialize. Unity keeps throwing various errors, I would rather recommend to remove Firebase from the dependencies, that is a cleaner way to workaround the issue.

[kirilogan]

@ideka Thanks! I can confirm that this works for me (and yes, it shows the Editor error), but everything else seems to work fine (fireauth, firestore, cloud functions). I can live with this hack for now :D

@almosr I could, but I'm already fairly far along with firebase

[GorillaOne]

@almosr Removing EDM while working in the project works for me as well. As mentioned above, Unity regenerates the EDM when you open the project and when you open the Package Manager.

If you don't need firebase, then removing firebase is an excellent option. However, I'm assuming that the folks here, like myself, who have this problem need firebase. Removing the EDM when you open the application prevents the slowdown because it prevents the Firebase editor scripts from running, which is where I believe the issue is located. It's not great, but its just a workaround until they fix it.

[ewjordan]

Not sure if it's already been made explicit or not, but I've been working on the same project in the Windows 10, OS X, and Linux versions of Unity, several different versions, and this only seems to happen on Windows (all 2019 versions I've tried), so you'll have trouble reproing on GLinux or Mac.

My workaround is to locally delete Firebase.Editor.dll and its meta file, and the issue goes away (but I don't commit or it breaks our game in CI builds), but if that dll is anywhere in even an otherwise empty project, things get slow. This has been happening since at least January, and in particular before the migration to the Unity package manager install, so it's not a particularly new change that's caused it.

[MWFIAE]

For me it's also crippling slow with Unity 2019 and Windows10.
However it seems like deleting the editor.dll doesn't bring any noteworthy improvement.
Startup times are around 20 seconds and also freezes if I change anything in vs code and come back to unity.

Basically impossible to work like this.

[igor84]

Seems #667 is duplicate of this one. The problem seems very straight forward:

1. GenerateXmlFromGoogleServicesJson class has a [InitializeOnLoad] attribute so Unity will load it and execute its static constructor after each recompile and when entering play mode.
2. Static constructor will schedule CheckConfiguration() to be called on first next Update,
3. which will then call UpdateConfigFileDirectory()
4. which will for every "google-services.json" and "GoogleService-Info.plist" file in project call ReadBundleIds(file)
5. which will run "generate_xml_from_google_services_json.exe" on Windows and "python generate_xml_from_google_services_json.py" on other platforms and each invocation of that takes more than 5 seconds, keeping the Editor frozen.

Surely Firebase doesn't need to do all this on each load so please just cache it somehow or something so we can continue making games :)

[aleksandrdolbilov]

You can speedup recompile time by removing 'generate_xml_from_google_services_json.py'.
After that you will see error message on each recompile. But that's ok.
Also you have to restore this file before 'platform build'.

[miv]

You can speedup recompile time by removing 'generate_xml_from_google_services_json.py'.

I've tried that but Unity will restore it pretty quickly in my case.

[aleksandrdolbilov]

I think it restores 'generate_xml_from_google_services_json.py' on Unity restart.
Can be solved with simple Unity script which only responsibility is to delete it.

[L4fter]

I'll copypaste my comment from another closed thread on this topic. I strongly believe that optimizing the performance/caching/removing files when not building are just half measures. The real question is should this code run all the time at all?
I think the best solution is to make an option of not running this code at all. In the end, when no plugins have been changed, it does _nothing_ and takes 10-20 seconds. So my suggestion is to make two options, like:

• Run resolvers/version handlers only at build time
• Run resolvers/version handlers only manually

I don't mean that there should be no optimization, only that providing these options imo is faster and more reliable way to deal with the issue.

[aleksandrdolbilov]

That's 100% true, we need solution from Google, but also we have to make games now)
That's a dirty hack to save some time and continue to use Firebase.

[igor84]

Note in the stack trace that I described that this is done from a method called CheckConfiguration. Its purpose seems to be checking how your project is configured and if it finds something off it presents a dialog to the user telling him about it and offering him a way to fix it. That is probably a reason it can't just run on build since if build is running within some auto build system, there is no user that can be asked to fix the issue.

Still there must be a way to optimize it or have it run only in some special circumstances and not always.

[NoobsArePeople2]

I'm experiencing this issue in Unity 2019 on Windows 10 as well. Unity is effectively impossible to use with Firebase in this state.

I've not been able to find any of the files in the posted workarounds so this issue is a hard blocker for me. Getting a fix for this issue prioritized would be great as Firebase is otherwise quite nice and I'd like to continue using it.

[jimanjr]

Happening here as well. Workarounds posted above did nothing here. Have an Android project on Windows 10, yet the callstack shows me an Xcode project check.

1. Should probably not run Xcode project checks on windows/android.
2. Probably should not automatically run these checks on every build. Maybe a Debug.LogError for issues with the project.
3. Maybe make this a build step instead of a "play" step? Maybe some defines or options to disable this when we're testing gameplay stuff that has nothing to do with Firebase.

Running the game takes 13 seconds on the python script alone (on a fast SSD and a 3950X).

[ewjordan]

Not sure if it's already been made explicit or not, but I've been working on the same project in the Windows 10, OS X, and Linux versions of Unity, several different versions, and this _only_ seems to happen on Windows (all 2019 versions I've tried), so you'll have trouble reproing on GLinux or Mac.

My workaround is to locally delete Firebase.Editor.dll and its meta file, and the issue goes away (but I don't commit or it breaks our game in CI builds), but if that dll is anywhere in even an otherwise empty project, things get slow. This has been happening since at least January, and in particular before the migration to the Unity package manager install, so it's not a particularly new change that's caused it.

It's worth noting that after we updated to the newer package manager install, this doesn't work anymore.

[wwalton86]

The issue is still present in 6.14.0, EDM version 1.2.153.

As a workaround for those using the Package Manager versions, you can simply delete the Editor folder and Editor.meta file within Library/PackageCache/[email protected]/ExternalDependencyManager. You may have to do it every time you start Unity.

You'll sometimes get an error message about failing to load Firebase.Editor.dll, but it seems you can safely ignore it.

This has been working for me. Quick and easy until it's fixed.

[Whyser]

This has actually been an issue for a long time (freeze upon hitting Play caused by some part of Firebase), but this latest version (not sure which I had before) is about 2x as slow as it was before which is unbearable.
Please fix this asap with a manual toggle for now. :/

[mikeypdev]

Same freeze issue on macOS, Unity 2019.3.5f1, SDK 6.14 installed from UPM (migrated from earlier .unitypackage installs). In my case, the issue is caused by EDM, not directly by the python generator script (though see @igor84 note in issue #667). The workaround with deleting the EDM Editor folder works, along with the noted side-effects.

I found a more reliable workaround using the new "Enter Play Mode Settings" option introduced in Unity 2019.3. https://blogs.unity3d.com/2019/11/05/enter-play-mode-faster-in-unity-2019-3/

In the Edit menu, Player Settings, Editor section, I enabled "Enter Play Mode Options (Experimental)". For my project, I disabled the "Reload Domain" option, and enabled the "Reload Scene" option.

Play mode starts within a second or so for me now. Note that this feature could introduce other bugs, depending on your project. I seem to have good luck so far.

[Whyser]

Thanks for the other workaround Mike!
I actually tried that about a month ago and it is indeed quick! But because of some static refs throughout the project it's very troublesome to manage on our end. So a caution for people trying it out, read Unitys warning about it before you start relying on it. :)

[summitsteven]

We are also having a really hard time with this behavior.
We've tried going over to a manual install to avoid the Dependency Manager entirely, but that has caused difficulties in the build process.

This is extremely frustrating to work with as it will freeze for 30 seconds every time

• You launch unity
• Recompile from a code change
• Press play in the editor

This crushes developer productivity.

I've written a small script that will execute @ideka 's workaround automatically - deleting the Dependency Manager editor scripts. The initial load of Unity is still slow, but after that the script runs and recompiles/playing should be back to "normal".

Looking forward to a proper resolution!

#if UNITY_EDITOR
using System.Collections;
using System.Collections.Generic;
using System.IO;
using UnityEditor;
using UnityEngine;

[InitializeOnLoad]
public class SuppressDependencyManager 
{
    static SuppressDependencyManager()
    {
        Debug.Log("Deleting dependency manager files in attempt to work around https://github.com/firebase/quickstart-unity/issues/639");

        var editorFolderPath = Path.Combine(System.IO.Directory.GetCurrentDirectory(), "Library", "PackageCache", "[email protected]", "ExternalDependencyManager", "Editor");
        var editorMetaPath = Path.Combine(System.IO.Directory.GetCurrentDirectory(), "Library", "PackageCache", "[email protected]", "ExternalDependencyManager", "Editor.meta");
        if (Directory.Exists(editorFolderPath))
        {
            Directory.Delete(editorFolderPath, true);
        }
        if (File.Exists(editorMetaPath))
        {
            File.Delete(editorMetaPath);
        }
    }
}
#endif

[bhallionOhbibi]

I was able to patch the Firebase.Editor.dll using dnSpy to avoid the freeze each time you press play.
Everything seems to works and the freeze is gone !

I did the following:

• download dnSpy
• open Firebase.Editor.dll with dnSpy
• make sure dnSpy reference only one version of mscorlib
• open dlls referenced by Firebase.Editor.dll (Unity's dll and Google.JarResolver, Google.IOSResolver, Google.VersionHandlerImpl)
• navigate to the method GenerateXmlFromGoogleServicesJson.cctor()
• in the code inspector, right-click, Edit Method (C#)
• replace the following:

RunOnMainThread.Run(delegate
{
    GenerateXmlFromGoogleServicesJson.CheckConfiguration();
}, false);

with:

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

• Press "Compile" in the edit method window
• Fix compilation issues (there is synthax problems with CompilerGenerated fields. (I renamed those fields like this: <>f__mg$cache0 => f__m0 )
• After the compilation success: File -> SaveModule

You should now have a patched version of Firebase.Editor.dll which doesn't call the python script each time you press Play.

This is only a workaround and it fix only the issue when pressing PLAY.
The freeze still occurs after each compilation.
But once you start modifiying code, you can do pretty much anything. So I guess you could add an EditorPrefs per exemple to enable/disable the problematic method.

You can find a patched version I made for firebase 6.13.0 here: https://github.com/bhallionOhbibi/FirebaseEditorDll

[Whyser]

I'm gonna ping @DellaBitta (sorry, if you're the wrong person!) but maybe you can move/merge/assign this issue so we dont have to download a potentially malicious DLL to fix this issue (no offense bhallionOhbibi, really appreciate your effort!)?

[DellaBitta]

Hi @Whyser,

I'll send it to the team for review. Thanks!

[RadekMikulkaAG]

are there any news about this issue? It is there for soo long :(

[igor84]

The best workaround I came up with is to use dnSpy to change and recompile Firebase.Editor.dll as @bhallionOhbibi described but I changed it a bit differently. I removed the call to GenerateXmlFromGoogleServicesJson.CheckConfiguration() from static constructor but I made that method public and added [MenuItem("Windows/Firebase/Check Configuration")] above it. Then in my project I call it from my implementation of IPreprocessBuildWithReport.OnPreprocessBuild described here: https://docs.unity3d.com/ScriptReference/Build.IPreprocessBuildWithReport.html

That way it is automatically called before the build and I can also manually call it anytime from the menu, but it is not invoked on each recompile and when entering play mode.

[DellaBitta]

Hi all, a status update: the proposed change from @bhallionOhbibi will be part of our official 6.15.0 release -- currently in progress.

[Whyser]

Della please don't let it do this process during compilation of scripts. I would say Igor's solution is better to only do during build (or manually).

[chkuang-g]

@Whyser
Your suggestion make sense. That process creates two files out of google-services.json/GoogleServices.plist

1. google-services.xml for Android build
2. google-services-desktop.json for the editor

We might be able to postpone 1 until build time. It will take some time to refactor and we need to investigate the right timing to generate it for different Android build configuration.

There are more improvement can be done for the freeze. As for next release, we only integrated @bhallionOhbibi suggestion for temporary relief. More improvement will be coming from either Firebase or EDM4U.

Thanks for the update!

[mikeypdev]

Still seeing the play mode delay in 6.15.0 on macOS. Anyone else, or am I possibly seeing another issue?

[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.

1. Copied the modified Firebase.Editor.dll to another folder in the [Project] directory.
2. Created an EditorStartup.cs script:

using UnityEditor;

[InitializeOnLoad]
public class EditorStartup
{
    static EditorStartup()
    {
        string fromPath = "Support/Firebase.Editor.dll";
        string toPath = "Library/PackageCache/[email protected]/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.

1. 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/[email protected]/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/quickstart-unity/issues/639#issuecomment-640161250, 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\\[email protected]\\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 ?

[Grinch-Geo]

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

[Grinch-Geo]

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](https://github.com/googlesamples/unity-jar-resolver/blob/825901fa297065d651709fdc34cc5433410c8869/source/AndroidResolver/src/XmlDependencies.cs#L65)

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:

```C#
[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:

```C#
[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.